A sandbox is just a throwaway computer

The "managed" part means you run nothing

It can't reach anything it shouldn't

It can pause mid-thought

"Isn't this just a Docker container?"

What managed sandboxes for AI agents cost

Handing it to your agent

When to actually reach for a sandbox

The short version Ask an AI agent to "figure out why this script is slow" and it will. It writes code, installs three packages you've never heard of, runs them, maybe shells out to git to check something. The question is where all that runs. If the answer is "your laptop," you've handed a language model write access to your filesystem. A managed sandbox for AI agents is the fix. It's a throwaway computer your agent gets, does whatever it wants inside, and hands back. "Managed" means you don't run it - one API call and it exists, one call and it's gone. That's the whole idea. The rest of this post is what that actually means, with real code. Strip away the jargon and a sandbox is a small, isolated computer that exists for a few seconds or a few minutes and then disappears. Your agent gets to be reckless inside it. It can rm -rf the wrong directory, install a broken package, run an infinite loop - and the worst case is "that sandbox crashed," not "my git history is gone." Here's the entire lifecycle with the orkestr Python SDK: Create it, write a file, run a command, read the output. The with block terminates the sandbox when you leave it - even if your code throws halfway through. No leftover process, no lingering bill. That's it. If your agent can call a function, it can use a sandbox. Plenty of teams build their own version of this. They spin up a VM, install Docker, write a queue, handle cleanup, patch the host, watch it 24/7. That's a real project, and it's not the project you actually wanted to ship. "Managed" means that whole layer is gone. You call POST /v1/sandboxes, you get back a sandbox ID, you use it. No host to patch, no capacity to plan, no cleanup cron. The sandbox boots from a warm pool in under 30ms, and a cold boot is around 150ms - fast enough that your agent doesn't wait on it. There are four templates to start from: Pick one at create time. The sandbox comes up with that runtime already installed. Here's the part that matters once an LLM is generating the commands. A sandbox isn't useful if it can quietly POST your data to an address the model invented. So network access is a setting you choose, not a default you inherit. Three modes. off means no egress - nothing leaves the box. restricted routes traffic through an allowlisting proxy: the sandbox can reach package registries, GitHub, and the major LLM APIs, and that's the list. Your agent can pip install pandas; it can't connect to a host it made up. open is full egress, and it's gated behind a verified payment method on purpose. Each sandbox is also isolated from every other sandbox. Two agents running on the same physical machine can't see each other, can't reach each other, can't even tell the other one exists. The boundary is the hardware, not a setting the kernel decides to honor. Agent sessions aren't always a tidy ten seconds. Sometimes an agent does some work, waits on a human to approve a step, then continues an hour later. You don't want to pay for an idle VM during that hour, and you don't want to lose the agent's working state either. So a sandbox can be frozen and thawed: pause() snapshots the entire machine - memory, filesystem, running processes - and stops the clock. resume() brings it back exactly where it was. The agent doesn't know any time passed. Fair question, and the honest answer is: no, and the difference is the whole point. A container shares the host's kernel. That's fine when you trust the code - it's how most of the internet runs. But the moment the code is something an LLM wrote thirty seconds ago and nobody reviewed, sharing a kernel with the host and with every other tenant becomes an uncomfortable bet. Each orkestr sandbox is a real virtual machine. It boots its own kernel, mounts its own filesystem, and runs in its own slice of hardware. A bad command inside the sandbox stays inside the sandbox - there's no shared kernel for it to climb through. You get the disposability of a container with an isolation boundary that holds up when the code is genuinely untrusted. Pay-as-you-go on active vCPU and RAM, billed per second. No per-invocation tax, no minimum, no monthly seat. A quick one-shot call costs a fraction of a cent, and a paused sandbox stops the compute clock until you resume it. How many sandboxes you can run at once depends on your plan - 1 at a time on the free Starter tier, 5 on Pro, 15 on Team. Sandboxes are in private beta, so the full per-second rates aren't public yet - they land when the beta opens. You don't have to wire any of this up by hand. There's an MCP server - point Claude Code, Cursor, or any MCP client at /api/sandboxes/mcp and the agent gets tools directly: create_sandbox, run_shell, run_code, write_file, read_file, pause_sandbox, terminate_sandbox. The agent calls them like any other tool. No glue code. The plain REST API also works as a configured sandbox provider for Claude Managed Agents, so you can keep the orchestration on Anthropic's side and run the actual tool execution on EU hardware. Sandboxes aren't a replacement for a normal dev environment. They're for a specific shape of problem - mostly "I'm about to run something I don't want on my machine." Six places they earn their keep. Running model-generated code. The obvious one. Your agent writes a script and you want to actually run it to see if it works, not just stare at the diff. A sandbox is what turns "the agent suggested a fix" into "the agent shipped a fix." Worst case is the VM is gone. Touching files you don't trust. A user uploads a CSV. A scraper dumps JSON. A teammate shares a notebook from somewhere. You want pandas on it, but you don't want a Zip-slip surprise on your filesystem. Open it in a sandbox, do the analysis there, return summaries. A real Linux box from macOS or Windows. You're on a Mac. The thing you're testing is Linux-only - a Dockerfile, a glibc bug, a systemd unit. One API call gets you a Linux userland with the right architecture and none of the Docker Desktop dance. Parallel experiments. Try three fixes at once. Benchmark four configs. Build against five Python versions. Agents that fan out across sandboxes don't fight over ports, lockfiles, or PATH. Each one starts clean. Context-window discipline. This one is the subtle agent-design win. If your agent reads a 50,000-row CSV into the conversation, it just burned thousands of tokens on data the model doesn't need to see. If the agent works on it inside a sandbox and returns df.describe() or a chart, the model sees the conclusion, not the corpus. The sandbox holds the data; the conversation holds the answer. Sensitive intermediate state. Generating credentials, decrypting a file, processing PII for a one-shot calculation. A terminated sandbox is gone - no swap file, no shell history, no /tmp for the next process to read. The other half of the rule: sandboxes are the wrong tool when the working directory is the point. Editing your repo, running your own test suite, iterating on a feature branch - that all belongs on your machine. The sandbox is for code whose provenance you're not sure of, or an environment that needs to be disposable. If neither applies, you're paying latency for no reason. A managed sandbox for AI agents is a disposable, isolated computer your agent can break without consequences - and "managed" means you get it from an API instead of building and babysitting the infrastructure yourself. Network access is something you choose. State can be paused and resumed. The isolation boundary is a real VM, not a shared kernel. If your agent runs code - and most useful agents do - it should run that code somewhere that isn't your laptop or your production box. That's the whole job a sandbox does. What's the difference between a sandbox and a container?

A container shares the host's kernel; a sandbox VM brings its own. For trusted code that distinction rarely matters. For code an LLM just generated and nobody reviewed, the VM boundary is what keeps a bad command from reaching the host or another tenant. Where does my agent's code actually run?On dedicated hardware in the EU - Germany and Finland. Sandbox snapshots, environment variables, and runtime memory stay in the EU. For an EU company sending agent-generated code somewhere, that removes a data-transfer conversation. There's more on the EU angle here. What happens if my agent forgets to clean up?Every sandbox has a timeout_seconds (default 600) and auto-terminates when it's hit, so a crashed or forgetful caller can't leave a VM running forever. The SDK's with block also terminates the sandbox the moment you leave it. Can I run a server inside a sandbox?Not in the current beta - sandboxes are for running commands and code, not for hosting inbound services. If you want a long-lived app with a public URL, that's a regular orkestr deployment, not a sandbox. How do I get access?

Managed sandboxes are in private beta. The waitlist is at orkestr.eu/sandboxes - it asks what you're building so we can triage who gets in each week. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse