Runtime for Claude Managed Agents
Give a Claude Managed Agent access to Runtime's sandboxes through Runtime's remote MCP server. The agent can create, run, share and keep machines, beside its own session container.
Claude Managed Agents runs the agent loop and a container for each session on Anthropic's side. Add Runtime's MCP server to the agent and it can also create Runtime sandboxes: Firecracker microVMs with their own kernel. They can run for days, pause with their memory, share a port at an HTTPS address, fork, run Docker, and start from your own images. Runtime bills them for the CPU they use. The Runtime key stays in an Anthropic vault and never enters the session's container.
Updated
On this page
Set it up#
You need an Anthropic API key with Managed Agents access and a Runtime key. Create the Runtime key on the API keys page and give it a daily spending limit (read-only keys and daily limits), so the agent's sandboxes can never spend past it.
Terminalpip install anthropicexport RUNTIME_API_KEY=... # from your secret managerFour calls, made once in a setup script. Store the ids they return:
Pythonimport osimport anthropicclient = anthropic.Anthropic()RUNTIME_MCP = "https://api.withruntime.com/mcp"# 1. A vault holds the Runtime key. Anthropic adds it to requests to the MCP server.vault = client.beta.vaults.create(display_name="Runtime")client.beta.vaults.credentials.create( vault.id, display_name="Runtime key", auth={"type": "static_bearer", "mcp_server_url": RUNTIME_MCP, "token": os.environ["RUNTIME_API_KEY"]},)# 2. The agent declares Runtime's server and may use its tools.agent = client.beta.agents.create( name="Builder", model="claude-opus-5", system="Build and run software in Runtime sandboxes. Stop every sandbox you start unless asked to keep it.", mcp_servers=[{"type": "url", "name": "runtime", "url": RUNTIME_MCP}], tools=[ {"type": "agent_toolset_20260401", "default_config": {"enabled": True}}, {"type": "mcp_toolset", "mcp_server_name": "runtime"}, ],)# 3. An environment for the session's own container.environment = client.beta.environments.create( name="builder", config={"type": "cloud", "networking": {"type": "unrestricted"}})print(vault.id, agent.id, environment.id)Then every run starts a session with the vault attached and sends the task:
Pythonimport anthropicclient = anthropic.Anthropic()def run(agent_id: str, environment_id: str, vault_id: str, task: str) -> str: session = client.beta.sessions.create(agent=agent_id, environment_id=environment_id, vault_ids=[vault_id]) text = [] with client.beta.sessions.events.stream(session_id=session.id) as stream: client.beta.sessions.events.send( session_id=session.id, events=[{"type": "user.message", "content": [{"type": "text", "text": task}]}], ) for event in stream: if event.type == "agent.message": text += [block.text for block in event.content if block.type == "text"] elif event.type in ("session.status_idle", "session.status_terminated"): break return "".join(text)A production client also handles a dropped stream and tool confirmations; Anthropic's Managed Agents documentation covers both.
What the agent can do with Runtime#
The agent sees every tool of Runtime's MCP server, named
runtime_<product>_<verb>. The ones a builder uses most:
| Tool | What the agent does with it |
|---|---|
runtime_sandboxes_create |
Start a sandbox of the size it needs, from Runtime's base image or yours |
runtime_sandboxes_exec |
Run a command and read its exit code and output, or start it in the background |
runtime_sandboxes_files_write |
Write the files it generated |
runtime_sandboxes_previews |
Share a port at a private HTTPS address under runtimehost.com |
runtime_sandboxes_manage |
Pause, wake, extend or stop |
runtime_sandboxes_fork |
Copy a running sandbox, memory included, to try two approaches at the same time |
runtime_images_build |
Build an image from a Dockerfile once, so later sandboxes start ready |
A pattern that uses both kinds of machine: the agent writes and tests code in its session container, then deploys the result to a named Runtime sandbox with a preview. That sandbox outlives the session. The next session finds it by name, wakes it, and continues.
Keep the agent inside its budget#
- The daily spending limit on the Runtime key bounds every sandbox the
agent starts. A create or wake past it fails with
spending_limit_reached, and nothing is charged. - Idle sandboxes pause. A sandbox pauses itself when nothing happens in
it, so a forgotten one stops costing compute. Tell the agent in its system
prompt to stop what it starts, as the example does, and to set
timeoutSecondswhen a task should end at a fixed time. - A read-only key lets a reviewing agent see the sandboxes, their files and their cost. It cannot change anything.
- A session budget on the Managed Agents side caps the model spend of one session, independently of Runtime.
What it costs#
CPU is billed as used, $0.025 per vCPU-hour with a floor of 50 millicores, and reserved memory at $0.0075 per GiB-hour. A 2 vCPU, 4 GiB sandbox costs $0.08 an hour with both CPUs busy and $0.03125 an hour while it waits. A paused sandbox pays only storage (pricing). Every account gets 100 free hours of a 1 GB machine every month, no card.
What was verified#
- On 25 September 2026 an MCP client sent a Runtime key as
Authorization: Bearertohttps://api.withruntime.com/mcp, the way a vaultstatic_bearercredential does. It listed 76 tools, created a sandbox, ranunameandpython3 --versionin it, and stopped it, all in 1.4 seconds. - The vault, agent and session calls above match
anthropic1.8.0 for Python on the same day:vaults.create(display_name=...), astatic_bearercredential withtokenandmcp_server_url, andmcp_serverswithmcp_toolseton the agent.
Official reference checked 25 September 2026: Claude Managed Agents.
Try it on your own work. Sign up, then paste the setup prompt into your coding agent.