Ask a language model to project 40 years of compound interest and it will hand back a table that looks plausible and is quietly wrong. Give the same task to a model with a Python interpreter attached and you get real numbers from real execution. The distance between those two outcomes is where E2B AI does its work.
E2B is an open-source platform for running AI-generated code inside disposable cloud sandboxes. Rather than trusting a model to write correct SQL against your production database, or hoping it doesn’t delete a directory while it “tests” its own script, you give it an isolated machine that boots in roughly 150 milliseconds and vanishes when the task is finished.
What E2B AI actually is
The project started on a narrow problem: agents that write code need somewhere to run it. That somewhere has to be fast, because an agent that waits 20 seconds for a container to spin up is an agent nobody ships. It has to be isolated, because the code comes from a probabilistic system that occasionally does things nobody asked for. And it has to be disposable, because a useful product might need thousands of them running at once.
E2B’s answer is Firecracker microVMs, the same lightweight virtualisation technology AWS built for Lambda, wrapped in Python, JavaScript and TypeScript SDKs. The core repository is Apache-2.0 licensed, so you can self-host the whole thing if you’d rather not use the managed version. Sandboxes can live for up to 24 hours, can be paused and resumed with their memory state intact, and can be customised with your own dependencies using templates built from a Dockerfile.
Why agents need a sandbox at all
Isolation is the whole point
A code interpreter that shares a filesystem with your API keys is an incident waiting to happen. Each sandbox gets its own kernel, its own filesystem and its own network namespace. Outbound traffic is controlled with domain allowlists, so an agent running scrapers can reach the sites you approved and nothing else. Ports can be exposed deliberately when you need to serve something back out.
State that survives more than one turn
Multi-step tasks fall apart if every step starts from zero. An analysis agent that loads a 200MB CSV in step one shouldn’t re-download it in step four. Sandboxes keep files, installed packages and running processes alive between calls, which is what makes the write-fail-fix-rerun loop feel like a real machine instead of stateless RPC.
Startup time shapes the product
Latency budgets in agent systems are unforgiving, and the sandbox is usually the slowest link in the chain. Cold-starting a container per tool call adds seconds the user feels. This is the same pressure pushing model providers to cut response times, as covered in OpenAI’s push for faster frontier inference. Pausing a sandbox instead of rebuilding it is one of the more practical ways to keep a long-running agent responsive.
What people actually build with it
- Code interpreters — the “upload a file, get a chart” feature that shows up in chat assistants and analytics tools.
- Data analysis agents — pandas, DuckDB and matplotlib working on real datasets rather than guessed ones.
- Computer-use agents — desktop sandboxes expose a virtual display that agents can drive with mouse and keyboard events.
- Coding agents — clone a repository, install dependencies, run the test suite, report exactly which assertion failed.
- Evaluation harnesses — execute thousands of generated solutions in parallel and measure how many actually pass.
A sandbox in a few lines of Python
The SDK deliberately keeps its surface small. Creating a sandbox, running code and reading the result looks like this:
from e2b_code_interpreter import Sandbox
with Sandbox() as sbx:
execution = sbx.run_code("sum(range(1_000_001))")
print(execution.text)From there, files.write() pushes data in, commands.run() executes shell commands, and the returned execution object carries stdout, stderr and any rich results such as generated images. The same primitives exist in the TypeScript SDK, which matters if your agent orchestration lives in Node.
What it costs to run
Pricing is consumption-based, metered per second of vCPU and memory, with a free tier that hands you starting credits. There’s a ceiling on how long a single sandbox can run by default, and higher plans raise it. The arithmetic gets interesting at scale: thirty seconds of compute per user query across a hundred thousand daily queries is a genuine line item, and the same usage-based logic shows up everywhere in this market, as the comparison of AI chatbot pricing tiers makes clear.
Two levers keep the bill down. Shorter timeouts force you to be honest about what each agent step needs, and reusing a warm sandbox across several steps usually beats creating a fresh one per tool call. Self-hosting is the third option once volume justifies the operational work.
How it compares with the alternatives
Running Docker on your own VM is cheap and puts you in charge, but you end up building scheduling, isolation, cleanup and per-tenant limits yourself. Serverless functions are excellent for one-shot transformations and awkward for anything iterative, since the filesystem doesn’t persist and cold starts bite. Executing model-generated code in a subprocess on your application server is the fastest thing to prototype and the worst thing to ship.
There’s also a neighbouring category of products built for agents that control a full desktop rather than a terminal. If your work leans toward browser automation and clicking through UIs, it’s worth understanding what Scrapybara offers with cloud computers for agents, because the trade-offs differ from a code-execution sandbox.
Where it fits in the wider agent stack
Sandboxes solve execution, not orchestration. You still need something to decide which tool to call, manage retries and hand state between steps. Frameworks have been consolidating fast on that front, and the changes described in the evolution of the Agents SDK reflect how much of the plumbing is now handled for you.
The clearest signal of where this is heading comes from research workflows. Deep research features run dozens of searches, parse the results and synthesise an answer, all of which requires isolated compute that can be thrown away afterwards. That pattern is expanding quickly, as the growth of agent-powered research shows, and it pushes sandbox infrastructure from a nice-to-have toward a default component.
Getting the setup right the first time
Start on the hosted platform with a template that already contains the libraries your agents need. Building the template once, rather than pip-installing on every sandbox boot, removes the biggest chunk of startup latency you control.
Set timeouts on purpose. The default is short for a reason, and agents that need longer should extend deliberately rather than silently. Keep credentials out of the sandbox entirely and inject short-lived tokens through the network layer instead. Log what agents execute for the first month, because the gap between what you expect them to run and what they actually run is usually wider than anyone anticipates.
Then watch the metrics that matter: median sandbox lifetime, percentage of executions that error, and cost per completed task. If those numbers hold steady as volume grows, you’ve chosen the right layer. If they drift, the fix is almost always in the agent’s logic rather than the sandbox underneath it.