OpenRouter compares hosted code execution tools from four AI providers

OpenRouter has published a comparison of server-side code execution tools for AI agents, covering OpenAI, Anthropic, Google and its own beta tools, openrouter:shell and openrouter:bash. The company says a hosted sandbox spares developers from provisioning, patching and securing a container, but that some jobs still need a sandbox they run themselves.
- OpenAI, Anthropic and Google each run code in hosted sandboxes for their own models only.
- OpenRouter's openrouter:shell works on the Responses and Messages APIs, and openrouter:bash on the Messages API only. Both are in beta.
- OpenRouter bills sandbox time at $0.0001 per second, with a 30-second minimum for a new or sleeping container.
- Outbound network access is off by default in OpenRouter's sandbox, and a model loop is capped at 30 server-tool steps by default.
- Custom base images, GPU work and multi-hour sessions still call for a sandbox the developer operates.
What server-side code execution means
A model never runs anything itself. When it calls a tool, it emits a request naming the tool and its arguments, and something else has to carry it out. With a client-side tool, that is the developer's application or agent framework, which runs the call and sends the result back in a follow-up request.
With a server-side tool, the provider runs the call on its own infrastructure and returns the result to the model in the same request. According to OpenRouter, the developer adds the tool to the request, the model decides when it needs to run something, and the provider executes the commands in an isolated Linux container with its own filesystem, a time limit and no network access by default.
The model can run a command, read the output and decide whether to run another, repeating until it answers. OpenRouter caps that loop with the max_tool_calls field. Its server tools reference sets both the default and the maximum at 30.
How the four providers differ
OpenRouter says what separates the providers is which models each one runs code for.
- OpenAI: a shell tool on the Responses API, running in a container OpenAI manages. The documented runtime is Debian 12 with a default working directory of /mnt/data. Commands run without sudo, and interactive TTY sessions are not supported. Preinstalled languages include Python 3.11, Node.js 22.16, Java 17, PHP 8.2, Ruby 3.1 and Go 1.23. Outbound network access is off by default and can be enabled through an allowlist set by an organization admin.
- Anthropic: a code execution tool that runs Python and Bash on the Messages API. The documented environment is a Linux x86_64 container with Python 3.11, 5 GiB of RAM, 5 GiB of workspace storage and one CPU. Internet access is disabled, so Claude cannot install a package during a run. Containers expire 30 days after creation and are checkpointed after about 5 minutes of inactivity.
- Google: a code execution tool for Gemini models that can only generate and execute Python. The documentation states a maximum runtime of 30 seconds and that users cannot install their own libraries.
Anthropic offers three tool versions. According to the article, code_execution_20250825 supports Bash commands and file operations, while code_execution_20260120 adds Python interpreter state that persists between requests. That version is not available on Claude Haiku 4.5.
OpenRouter's own sandbox for any model
The three tools above each work with one company's models. OpenRouter says its tools work with any model on the Responses and Messages APIs, because the sandbox runs at the routing layer rather than inside one model provider.
The company ships two tools. The openrouter:shell tool mirrors the shape of OpenAI's hosted shell and works on both the Responses and Messages APIs. The openrouter:bash tool mirrors Anthropic's bash tool and works on the Messages API only. Both are in beta, so the API may change.
Sandboxed execution runs only on the global openrouter.ai endpoint. In-region endpoints do not offer the shell tool, and Chat Completions rejects both tools with a 400 error that names the APIs that support them.
Developers set the engine field to openrouter to run commands in OpenRouter's sandbox. The default is auto. For openrouter:shell, auto keeps a provider's native hosted shell where one exists and routes to OpenRouter's sandbox otherwise. For openrouter:bash, auto returns the tool call to the application to run client-side, and nothing executes on OpenRouter's servers.
Cost, limits and when to run your own sandbox
OpenRouter describes its sandbox as an isolated container scoped to the user's account and workspace, with outbound network access off by default and per-command limits on runtime and output size. Sandbox time is billed at $0.0001 per second, with a 30-second minimum for a new or sleeping container.
The company positions openrouter:shell for work that amounts to a handful of short commands per request. For a custom base image, GPU work or a session that runs for hours, it says a sandbox platform operated by the developer, such as E2B or Modal, or a self-managed Docker container, remains the right choice. Running one's own sandbox also means owning the security boundary, including keeping code away from databases and the internet.
For teams building agents, the comparison suggests the choice depends mainly on which models they use and how long the code needs to run. Provider-native tools suit a single model family, while OpenRouter's tools aim to cover several models with one interface.
OpenRouter: Server-Side Code Execution Tools for AI Agents, Compared

