OpenRouter’s hosted shell tool makes runtime billing part of multi-model routing

OpenRouter has added a beta hosted shell execution tool and Files API, giving developers a way to let tool-calling models run commands in isolated Linux containers through OpenRouter’s routing layer. The release is more than another agent feature. It changes the accounting model for multi-model AI infrastructure: a request can now include model tokens, tool execution time, file handling and compatibility behavior across more than one API style.

The new server tool, named openrouter:shell, lets supported models execute commands in hosted containers and return standard execution results, including stdout, stderr and exit codes. OpenRouter says the tool works through its Responses API path and its Anthropic Messages API compatibility path, which matters because developers are increasingly trying to keep agent implementations portable across model providers rather than binding every workflow to one vendor’s native tool interface.

OpenRouter prices the sandbox at $0.0001 per second, billed as part of the request. Files API usage is included during the beta. That creates a separate cost dimension from ordinary input and output tokens, and it gives gateway operators a concrete example of why unified AI API billing is becoming harder than summing model token charges.

What changed

Until recently, hosted code execution was usually tied to a provider-specific agent stack or required developers to operate their own sandbox fleet. OpenRouter’s beta inserts that capability into a routing platform already used to access many models. In practical terms, an agent can ask a model to inspect data, run scripts, manipulate files or test small pieces of code without the application team provisioning containers directly for each run.

The compatibility detail is important. OpenRouter is positioning the shell tool not as a capability of one model family, but as a platform-level tool surface available through familiar API patterns. For teams that have built against OpenAI-style Responses semantics, or Anthropic-style Messages semantics, the hosted tool can sit closer to the gateway layer than to the model layer.

That does not make tool behavior magically uniform. Different models vary in how they call tools, recover from failures, reason about command output and manage files. But the infrastructure decision is shifting. Instead of asking only which model can write a shell command, developers now have to ask which gateway can safely execute it, meter it and return the results in the API shape their client already understands.

Why runtime metering matters

Token pricing is no longer enough to describe the cost of an agent request. A single user action may involve a prompt, several model turns, file uploads, shell execution, retries and final summarization. The expensive part may be the model output, or it may be a long-running command that produces little text. OpenRouter’s per-second sandbox price makes that distinction explicit.

For developers, the immediate consequence is budget design. Agent loops need limits on command duration, retry behavior and file retention assumptions. A harmless-looking request that expands into repeated shell calls can accumulate runtime charges even if token usage remains modest. Logging needs to show not only model, provider and token counts, but tool name, execution duration, exit status and whether the model retried after an error.

For businesses building on top of model gateways, the change touches margins and customer reporting. A partner product that resells AI automation cannot treat every request as a text completion with a markup. It needs a usage ledger that can attribute model cost and hosted tool cost to the right workspace, end customer or API key. That is directly relevant to partner API automation, where the downstream customer may never see OpenRouter’s raw invoice but still expects a coherent bill.

Who is affected

The first affected group is agent developers who want code execution without committing to one model provider’s full agent platform. OpenRouter’s approach may appeal to teams that already route traffic across models and want to add shell access while preserving some flexibility in model choice.

The second group is platform and gateway teams. They now have to decide whether hosted tools are first-class catalog items, whether they can be enabled per workspace, and how their costs appear in dashboards. A model catalog row may need to be paired with tool availability, runtime limits and compatibility notes. Access control may need to distinguish between allowing a model call and allowing that call to start a container.

The third group is finance and operations teams managing AI spend. Usage analytics that stop at tokens will miss a growing class of agent infrastructure costs. A useful AI API usage analytics dashboard should show whether a spike came from model choice, token volume, sandbox runtime or a workflow design change that caused extra tool calls.

What remains uncertain

The beta leaves several practical questions open. OpenRouter says Files API usage is included with the shell tool during the beta, but long-term file pricing, retention rules and operational limits may still matter for production workloads. Developers will also need to test which models perform reliably with the shell tool across the supported API compatibility paths.

Security is another unresolved implementation question for buyers. OpenRouter describes the commands as running in isolated hosted Linux containers, but enterprises will still ask about network access, package installation, file persistence, audit logs and data handling before sending sensitive workloads through a hosted execution environment.

The broader direction is clear, though: gateways are absorbing more of the agent runtime. Model routing used to mean choosing where a prompt was sent. Now it increasingly includes tool semantics, file state, execution policy and non-token metering. OpenRouter’s shell beta is a useful marker because it attaches a clear price to a capability that many agent builders have treated as background infrastructure. Once execution time appears on the bill, it becomes part of the product architecture.