Skip to content
AI Primer
release

OpenRouter adds openrouter:shell to Responses API for hosted Linux code execution

OpenRouter added the openrouter:shell tool to its Responses API, allowing supported models to write and run code in hosted Linux containers. Containers are isolated to a workspace and return command output and execution results.

3 min read
OpenRouter adds openrouter:shell to Responses API for hosted Linux code execution
OpenRouter adds openrouter:shell to Responses API for hosted Linux code execution

TL;DR

  • Hosted Linux execution is now a declared Responses API tool: OpenRouter's launch post supplies the openrouter:shell configuration.
  • Each command batch returns stdout, stderr, and an exit code to the model, letting it inspect a failed script before answering, as OpenRouter's run description explains.
  • Files written under /workspace/home survive container cleanup and can move into shared workspace storage, OpenRouter's storage update says.
  • Outbound networking defaults to off, while sandbox time costs $0.0001 per active second plus separate inference charges, according to OpenRouter's configuration note.

OpenRouter's Shell guide accepts both OpenAI and Anthropic tool shapes. The beta service runs only on the global endpoint, while the container documentation says eu.openrouter.ai and us.openrouter.ai reject requests. The current Files API docs list a 100 MiB maximum individual upload, alongside a 10 GiB figure in the launch thread.

Tool contract

Shell joins the server-tools catalog as a model-callable tool, rather than a separate code-execution service. The docs limit it to the Responses and Messages APIs, with Chat Completions requests returning 400.

Command feedback

OpenRouter describes a four-step execution loop:

  1. The model sends a batch of commands.
  2. OpenRouter starts an isolated Linux container scoped to the workspace.
  3. Each command returns stdout, stderr, and an exit code.
  4. The model uses those results to correct the script before its final response.

Files API

Container storage and workspace storage are separate paths. Files under /workspace/home are retained after cleanup, can be listed or downloaded through the containers API, and can be promoted into a workspace for use by multiple containers.

OpenRouter's Files API update says inputs are attached by environment.file_ids as writable copies and outputs return through the same mechanism. That post names a 10 GiB upload limit; the current Files API documentation names a 100 MiB maximum per individual file.

Container reuse, egress and price

A later request can resume a container by including the prior shell result or passing environment.container_reference with its container_id. Egress stays closed unless a request supplies a network_policy, including an allowlist.

The billing unit is active sandbox time, at $0.0001 per second. Model inference remains a separate charge.

Messages API

OpenRouter reported more than 18,000 sandboxes since its soft launch late last month. Its usage update identifies three entry points: the chatroom shell switch, openrouter:shell on Responses API calls, and openrouter:bash for the Anthropic Messages API.

Execution backends

mattlam_ argued in a reply that a future extension could pass application-defined tools into server-side scripts, keeping intermediate compute and data out of the model context. That capability is a proposal, not part of the announced shell tool.

A separate harness pattern from pauliusztin_ resolves an executor after a permission gate, then dispatches the same bash request to local execution, Docker, or Modal. It frames a hosted shell as one interchangeable execution backend.

Restart semantics

Durability ends at the filesystem. The container documentation says a container sleeps after five idle minutes; a later request with the same ID starts a fresh sandbox and reloads saved home-directory files. Open processes, environment variables, and installed system state are discarded.

Share on X