Skip to content
Markdown

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 manager

Four 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 timeoutSeconds when 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: Bearer to https://api.withruntime.com/mcp, the way a vault static_bearer credential does. It listed 76 tools, created a sandbox, ran uname and python3 --version in it, and stopped it, all in 1.4 seconds.
  • The vault, agent and session calls above match anthropic 1.8.0 for Python on the same day: vaults.create(display_name=...), a static_bearer credential with token and mcp_server_url, and mcp_servers with mcp_toolset on 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.

Start free, no card

Was this page right?