Tool Highlight: E2B — Where Your Agent Runs the Code It Just Wrote

What it is: E2B is open-source infrastructure that runs AI-generated code inside secure, isolated cloud sandboxes — one throwaway Linux VM per run — so your agent can execute what it writes without you handing untrusted code a seat on your server.

Here's the problem it solves, in one scene. You build an agent that answers questions about a CSV. The model writes a little pandas script to compute the answer. Now something has to run that script. If you run it in your own process with exec(), you've just let a language model — and by extension anyone who can influence its output — execute arbitrary code with your app's permissions: your environment variables, your database credentials, your filesystem. The whole "agent that runs code" pattern lives or dies on where that code runs. E2B's answer is: not on your box. In a disposable microVM you spin up for the occasion and delete when you're done.

Who it's for#

Founders and builders shipping anything where a model produces code that then needs to run:

• Code interpreters — the "let the AI write and run Python to answer this" feature, the way ChatGPT's analysis mode works.
• Data-analysis agents — upload a spreadsheet, ask a question, let the agent compute and chart the answer.
• Coding agents — that need to execute, test, or iterate on generated code, not just print it.
• Any tool-using agent whose tools include "run this shell command" or "execute this snippet."

If your agent's output is ever code that has to execute, this is the layer underneath it. E2B is used inside products at Hugging Face, Perplexity, Groq, and Manus, per its investors — the code-interpreter-shaped companies.

Getting started#

The core object is a Sandbox. You create one, run code in it, read the result, and let it close. The higher-level e2b-code-interpreter SDK is the fast path because it hands back rich results — stdout, errors, even charts — instead of raw process output.

pip install e2b-code-interpreter
export E2B_API_KEY=e2b_your_key

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:
    sandbox.run_code("x = 1")            # state persists...
    execution = sandbox.run_code("x += 1; x")
    print(execution.text)               # -> 2

The non-obvious detail worth internalizing: state persists across run_code calls within a sandbox's life. That's what makes it a genuine interpreter session rather than a stateless "run once" function — variables, imported libraries, and files survive from one call to the next, exactly like a Jupyter kernel. So the natural loop is: create one sandbox per agent conversation, run each generated snippet as a step, and tear it down when the task ends.

There's a base SDK too (e2b) if you'd rather run shell commands directly:

from e2b import Sandbox

with Sandbox.create() as sandbox:
    result = sandbox.commands.run('echo "hello from the VM"')
    print(result.stdout)

Both SDKs ship for JavaScript/TypeScript as well (@e2b/code-interpreter), so you're not forced into Python to drive the sandbox.

Pricing#

E2B follows the usual developer-tool shape — a free tier to build on, usage-based paid plans, and per-second billing on the compute you actually use (you pay for sandbox time, roughly by vCPU-second and memory). As of mid-2026 there's a free "Hobby" tier that gets you started without a card, and a paid tier that lifts the session-length and concurrency limits. Because the exact figures move, confirm the current tiers at e2b.dev/pricing before you build a budget around them — treat the numbers there as source of truth, not any blog's summary.

The bigger cost lever isn't the price sheet, it's a habit: short-lived sandboxes. Since you're billed for the time a sandbox is alive, the cheap pattern is create-run-dispose per task rather than leaving idle VMs warm. A leaked sandbox that never gets closed is the one line item that surprises people.

The catch / where it fits#

Two honest limits.

First, E2B is a runtime, not an agent. It runs code; it does not decide what code to run. You still bring the model, the loop, and the prompt engineering that turns "answer this question" into "here's the Python to execute." E2B slots in as the tool your agent calls — pair it with your own agent logic (or a framework like LangGraph or CrewAI) rather than expecting it to be the whole stack.

Second, isolation is the feature, so respect it. The sandbox is deliberately cut off from your host — that's the entire point — which means anything the generated code needs (a package, a file, an API key for a downstream call) you have to put into the sandbox explicitly. That's a small tax, and it's the right tax: the day a model writes rm -rf / or tries to exfiltrate a secret, you want it doing that inside a VM you're about to delete, not on the machine serving your customers.

Where it fits: you're building an agent or feature that generates code, and you need that code to run somewhere that isn't your production process. If you already run hardened container infrastructure and want total control, you can build this yourself (E2B is open-source, so you can even self-host their version) — but for most founders, "one SDK call gives me a disposable, isolated Linux box" is exactly the piece you don't want to build from scratch. That's the sweet spot.