Remote oversight that cannot surprise your invoice.
Virex Remote drives the Claude Code interactive CLI on your machine, the same binary you would run yourself. It never wraps your agent in a programmatic entry point that bills per token, so the only thing you pay us is a flat seat.
// Interactive CLI only. No Agent SDK, no stream-json, no non-interactive print mode.
Why does Virex Remote never produce unpredictable usage charges?
Because of how it connects. Virex drives the Claude Code interactive CLI already installed on your machine, so sessions run under the Claude subscription on that machine. Virex deliberately does not drive agents through the Agent SDK, a stream-json transport, or a non-interactive print mode, which are the paths that route work through metered API usage. The result is a flat per-seat monthly cost with no token component.
- Sessions run on your machine under your own Claude subscription.
- Virex bills a flat rate per seat, per month, per product, with no usage component.
- A six-hour unattended run costs the same as a two-minute one.
- Permission prompts and plan gates survive, which is what makes remote approval meaningful.
The cost model is a design decision, not a pricing page.
Most tooling in this category attaches to an agent through whichever interface is easiest to automate. That choice quietly decides what your bill looks like.
Programmatic entry points meter by token
Driving a coding agent through an SDK or a non-interactive print mode turns the work into API usage. Cost then scales with what the agent consumes, which is exactly the number nobody can predict before the run finishes.
Unattended work is the worst case for metered billing
The whole point of a long-running agent is that you are not watching. That is also the situation where a token-metered integration can spend a great deal on your behalf with nobody present to stop it.
Supervision needs the interactive session
Permission requests and plan gates exist in the interactive CLI. An integration that bypasses them to make automation easier removes the decision points that remote approval is built around.
Drive the same session a person would.
A local daemon works with the interactive CLI rather than around it, which keeps both the billing and the supervision intact.
The interactive CLI, unchanged
The daemon drives the Claude Code CLI on your machine as an interactive session, so the agent behaves exactly as it does when you start it yourself.
Your subscription, your machine
Model access comes from the Claude subscription installed on that machine. Virex never proxies, resells, or meters model usage.
Gates stay in place
Because the session is interactive, permission requests and plan decisions still happen. Those are the moments Virex relays to you rather than suppressing.
What is and is not on the bill.
Stated precisely, because this is the kind of claim that deserves specifics.
Billing and integration questions
Does Virex Remote cost me extra API tokens?
No. Virex drives the Claude Code interactive CLI on your machine, the same binary you run yourself, so the work happens under the Claude subscription already installed there. Virex adds no token metering and no per-call API billing of its own.
Why does the integration method matter for billing?
Because programmatic entry points bill differently from the interactive CLI. Driving an agent through an SDK or a non-interactive print mode routes work through metered API usage, where cost scales with tokens consumed. The interactive CLI runs under the subscription on that machine, so a long session does not turn into a variable invoice.
So what exactly does Virex Remote charge?
A flat seat price, per seat, per month, per product, the same rate as every Virex product. That is the whole bill. There is no usage component, no token surcharge, and no per-session fee.
Could a long unattended run produce a surprise bill?
Not from Virex. Your seat cost is the same whether a session runs for two minutes or six hours. What a long run consumes is your own Claude subscription capacity on your own machine, exactly as it would if you had started it at the keyboard.
Does this mean Virex is slower or more limited than an SDK integration?
It means Virex works with the session rather than replacing it. Interactive sessions keep permission prompts and plan gates, which is what makes remote approval meaningful. An SDK integration that bypasses those gates would remove the thing being supervised.
What if I want programmatic control anyway?
Virex Remote ships a first-party MCP server, so an orchestrating agent can follow session activity and act on the decision surface. That is agent-driven control without changing how the underlying session is billed.
A flat seat, and nothing else.
Subscribe to Virex Remote, assign a seat, and install the daemon on the machine your sessions already run on.