bash, read, write, and similar tools execute) run in a Superserve sandbox.
How it works
- Anthropic runs the API, agent loop, and a per-environment work queue that signals when tools need to execute.
- You run an orchestrator that watches the queue, manages sandbox lifecycle, and starts the tool runner inside each sandbox. Separately, your application creates sessions and engages end users.
- Superserve provides per-session sandboxes - isolated microVMs with their own filesystem, network namespace, and process tree.
- Filesystem and shell tools (
bash,read,write,edit,glob,grep) execute inside your Superserve sandbox. The tool runner handles each call against the sandbox’s filesystem and shell, posting results back to the session. - Web tools (
web_search,web_fetch) and MCP server tools route through Anthropic’s servers. The sandbox is not involved.
Prerequisites
- A Superserve account and API key
- An Anthropic account with environments access
- Python 3.12+ or Node.js 22+ on the orchestrator host
Create a self-hosted environment
In the Claude Platform Console: Workspace > Environments > New > Self-hosted. Or create one via the API:Build the sandbox template
Build a Superserve template with Python and the Anthropic SDK pre-installed. Sandboxes created from this template boot in under 50ms - no image pull or package install at session time.Write the in-sandbox runner
The runner is a small Python script that the orchestrator starts inside each sandbox. It calls Anthropic’shandle_item(), which attaches to the session event stream, executes tool calls (bash, read, write, edit, glob, grep) against the sandbox, heartbeats the work-item lease, and stops cleanly on exit.
runner.py
handle_item() reads ANTHROPIC_SESSION_ID, ANTHROPIC_WORK_ID, and ANTHROPIC_ENVIRONMENT_ID from environment variables automatically. The orchestrator sets all four when it launches the runner.
Run the orchestrator
The orchestrator long-polls Anthropic’s work queue, ensures a Superserve sandbox is running for each session, and launches the runner inside it. For multi-turn sessions it reuses the same sandbox, resuming from a paused state if needed - preserving the agent’s filesystem and in-memory state across turns.- Finds or creates a sandbox for the session using a metadata tag. Existing paused sandboxes are resumed rather than recreated.
- Locks down egress — each sandbox can only reach
api.anthropic.com, preventing data exfiltration to arbitrary endpoints. - Uploads and launches the runner with per-session credentials passed as environment variables.
Webhook variant
Subscribe tosession.status_run_started webhooks, then drain the work queue on each delivery. The sandbox lifecycle logic is the same — only the trigger changes.
Start a session
Create a session, send a message, and stream the response.Pre-prepared sandboxes
For sessions that need custom data loaded before the agent starts - a cloned repo, a dataset, customer-specific files - create and seed a sandbox ahead of time, then pass its ID via session metadata. The orchestrator detects the metadata and attaches the existing sandbox instead of creating a new one.superserve.sandbox_id from work.data.metadata and connects to that sandbox instead of creating one from scratch.
Memory is not yet supported with self-hosted sandboxes.
What you get
- Firecracker microVM isolation. Each session runs in its own lightweight VM - not a shared container. Process tree, filesystem, and network namespace are fully isolated. A compromised sandbox cannot affect others.
- Fast startup (
<50ms). Sandboxes are ready instantly. No image pull, no package install, no boot sequence at session time. - Pause and resume. Checkpoint the full sandbox state between turns. Resume picks up exactly where it left off - running processes, open files, in-memory state. Pay for compute only when the agent is actively working.
- Per-sandbox network isolation. Each sandbox gets its own network namespace with CIDR and domain-based egress filtering. Lock the agent down to
api.anthropic.comonly, or open access to specific internal services. - The sandbox is yours. Beyond running the agent’s tools, you control the full VM. Pre-install packages in the template, mount data via the files API, stream command output for observability. The tool runner is one process in a VM you own.
- One line to switch. Point
environment_idat a cloud environment and the same application code works unchanged. The only Superserve-specific piece is the orchestrator.
Recipes
Ready-to-run examples that show specific use cases. Each recipe includes a working orchestrator, runner, and setup scripts in both Python and TypeScript.Research Agent
Agent researches topics across multi-turn sessions. Sandbox pauses between turns — you pay only for active compute. Notes, citations, and drafts persist in
/workspace.Persistent Dev Environment
Conversational coding assistant with durable state. Clone once, install once — packages, repos, and build artifacts survive across sessions.
Parallel Benchmark Agent
Agent fans out N sandboxes in parallel — one per variant — runs benchmarks concurrently, and synthesizes a comparison report. Total time equals the slowest variant.
See also
Claude Managed Agents
Anthropic’s full documentation for agents, sessions, tools, and events.
Self-hosted sandboxes
Anthropic’s self-hosted reference — worker config, monitoring, and operations.
Create a template
Customize your sandbox template with build steps, start commands, and resource limits.
Network rules
Lock down sandbox egress with allow and deny lists.
Reference implementation
Working orchestrator, runner, and setup scripts you can clone and run.