What Is E2B? Code Sandboxes for AI Agents
Photo: Daniil Komov / Pexels
When an AI agent writes Python that scrapes a website, runs SQL against a production database, or generates a chart from an uploaded spreadsheet, that code has to execute somewhere. Running it on the user's laptop is dangerous. Running it inside your own backend is a security incident waiting to happen. E2B is the infrastructure layer that was built specifically to solve this: instant, isolated cloud sandboxes purpose-built for AI-generated code, now processing well over 15 million sandbox runs a month for companies like Perplexity, Hugging Face, and Manus.
What Is E2B?
E2B (short for Evolution to Babel, a nod to the tower of programming languages it can run) is an open-source platform launched in 2023 by Czech founders Vasek Mlejnsky and Tomas Hromada. It provides secure cloud sandboxes where AI agents can execute code, install packages, browse the file system, control a virtual desktop, and access the internet, all without touching the developer's machine or production servers.
Under the hood, each sandbox is a Firecracker microVM, the same lightweight virtualization technology Amazon built for AWS Lambda. That gives E2B hardware-level isolation with a median cold-start time of around 78 milliseconds as of early 2026, down from roughly 150 milliseconds in 2024 as the company has optimized its VM boot pipeline. For context, spinning up a comparable general-purpose Docker container with a full OS-like environment typically takes 10 to 20 seconds, according to the team behind the AI agent Manus, which switched from Docker to E2B for exactly this reason.
The company has grown quickly alongside the agent boom it serves. E2B says it went from roughly 40,000 sandbox runs per month in March 2024 to about 15 million per month by March 2025, a 375-fold increase in a single year, and has now processed more than 500 million sandboxes total. In July 2025 it raised a $21 million Series A led by Insight Partners, bringing total funding to roughly $32 million.
Why AI agents need a sandbox at all
Large language models are increasingly given the ability to execute code as a tool, not just describe what code would do. That single capability unlocks arithmetic that doesn't hallucinate, real data analysis instead of guessed statistics, file manipulation, and genuine automation. But letting a language model run arbitrary code creates a security problem that most application developers have never had to think about before.
Think of it the way a hospital thinks about a new surgical resident. You do not hand them a scalpel and point them at a real patient on day one. You give them a cadaver lab, or a simulator, where mistakes cost nothing and the resident can be observed, reset, and tried again. A code sandbox plays the same role for an AI agent: a consequence-free space where the model can act, fail, and act again, while the "real patient" (your production systems and user data) stays completely out of reach.
Four failure modes show up repeatedly when teams skip this step:
| Approach | Failure mode | Why it happens |
|---|---|---|
| Local execution on the developer's machine | Data loss or exfiltration | A generated rm -rf or an unintended curl sending files to an external server has no barrier to stop it |
| Execution inside the production backend | Outages, data corruption, compliance violations | The agent has the same trust level as your own application code, which it should never have |
| A fresh container per request | Latency (5 to 30 seconds per cold start) | General-purpose container images were not built for sub-second agent loops |
| One shared long-lived environment for many users | State leakage between sessions | One user's files, environment variables, or credentials become visible to the next |
Sandboxes-as-a-service exist to remove all four failure modes at once. E2B specifically targets the agent use case, which is why it ships language-native SDKs, persistent and resumable sessions, and pre-built templates that match how agent loops actually behave: fast, frequent, short bursts of execution interleaved with LLM reasoning calls. Related reading: AI agents explained covers the broader architecture these sandboxes plug into, and function calling vs. tool use in LLMs explains the mechanism a model uses to decide when to reach for a sandbox in the first place.
How the sandbox actually works, step by step
It helps to walk through what happens between the moment a user asks an agent a question and the moment code executes safely.
Step 1: The orchestrator decides code is needed
An LLM orchestration layer (LangGraph, CrewAI, the OpenAI Agents SDK, or a hand-rolled loop using the Anthropic or OpenAI API) determines, based on the model's output, that the next step requires running code rather than just generating text. This is the tool-use decision described in function calling vs. tool use in LLMs.
Step 2: A sandbox spins up
The orchestrator calls the E2B SDK, which requests a Firecracker microVM from E2B's infrastructure. Firecracker was purpose-built by AWS for exactly this kind of workload: it strips a virtual machine down to only the device emulation a guest OS needs, which is why it can boot in tens of milliseconds instead of the tens of seconds a full VM (like a VMware or VirtualBox instance) typically needs.
Step 3: The model's code runs inside, not outside, the trust boundary
The generated code executes inside the microVM's own kernel, memory space, and file system. If that code tries something destructive, malicious, or simply buggy, the blast radius stops at the sandbox boundary. This is a meaningfully stronger guarantee than a Docker container gives you, because standard containers share the host machine's kernel; a sandbox escape in a container can, in the worst case, reach the host. A microVM has its own virtualized kernel, so an escape has to break out of hardware-level isolation, not just a namespace boundary.
Step 4: Results flow back as structured data
from e2b_code_interpreter import Sandbox
with Sandbox() as sandbox:
execution = sandbox.run_code(
"import pandas as pd; pd.DataFrame({'x':[1,2,3]}).sum().to_dict()"
)
print(execution.results[0].text)
# {'x': 6}
The agent gets a structured result back, not a wall of raw terminal output, which makes it far easier for the next LLM reasoning step to interpret what happened and decide what to do next.
Step 5: The sandbox pauses, persists, or dies
Depending on the workload, the sandbox can be torn down immediately (typical for a one-shot calculation), kept alive for a longer multi-step agent session, or paused and resumed later. E2B's paid tiers let sessions run for up to 24 hours and retain sandbox state for up to 14 days, which matters for agents that come back to the same working environment across multiple user turns rather than starting from scratch every time.
How is a microVM different from a regular container?
A microVM like Firecracker runs its own guest kernel on top of hardware virtualization, giving VM-grade isolation. A regular Docker container shares the host machine's kernel through Linux namespaces and cgroups, which is fast but means a sufficiently severe container escape can reach the host operating system. For code you trust, that trade-off is fine. For code an AI model just wrote based on a prompt from an anonymous user, it is not one most security teams are willing to make.
Key features at a glance
Table 1. E2B core platform capabilities.
| Feature | Description |
|---|---|
| Cold start | ~78 ms median (p50) as of January 2026, down from ~150 ms in 2024 |
| SDKs | Python and TypeScript first-class, REST API for everything else |
| Persistence | Pause and resume sandboxes; state retained up to 14 days on paid tiers |
| Custom images | Bring any Dockerfile as a template with your preinstalled dependencies |
| File system | Full read/write access, file upload and download via SDK |
| Processes | Run arbitrary shell commands and stream stdout/stderr in real time |
| Internet | Configurable outbound network access |
| Desktop sandbox | A full Ubuntu 22.04 + XFCE virtual desktop for computer-use agents, streamed over VNC |
| Code Interpreter template | Drop-in replacement for OpenAI's deprecated hosted Code Interpreter API |
| Framework integrations | Native support in the OpenAI Agents SDK, LangChain, and CrewAI |
The desktop sandbox: beyond just running code
E2B's original product was purely a code execution sandbox, but by 2025 the company had extended the same Firecracker-based isolation to full graphical desktops. The open-source project Surf, built on E2B's desktop sandbox, lets an AI agent control a real Ubuntu desktop environment the way a human would: taking screenshots, moving the mouse, clicking buttons, and typing into applications, all streamed back over VNC.
This matters because a large share of real-world tasks still live outside of anything an API or a script can touch. Filling out a form on a legacy internal tool, navigating a website with no public API, or testing how a web app actually renders in a browser all require a agent that can see a screen and act on it, not just call functions. Desktop sandboxes are the infrastructure layer underneath the wave of "computer use" agents that OpenAI, Anthropic, and startups like Manus have all shipped since 2024.
Who actually uses E2B?
By 2025 and into 2026, E2B says it is running sandboxes behind Perplexity, Hugging Face, Cohere, GroqCloud, IBM, Notion AI, Manus, and hundreds of smaller agent startups, and the company claims roughly 88% of Fortune 100 companies have used the platform in some capacity. Whenever a product shows "wrote and ran code to answer this" or a Hugging Face Space executes user-submitted Python live, E2B or infrastructure like it is very likely the engine underneath.
The Manus case is the most detailed public example of why a company chooses E2B over building in-house. Manus runs a planner agent that decomposes a user's request into subtasks, then hands those subtasks to executor agents that pull from a toolkit of 27 different tools, spanning code execution, file manipulation, and browser automation through Chromium. According to the company, the team tried Docker first and found it inadequate because full OS functionality, like installing arbitrary applications and system packages mid-session, was something a standard container image could not comfortably provide at the speed an interactive agent needs.
E2B vs. the alternatives
No single sandbox provider is right for every use case, and the differences are less about raw capability than about what kind of workload each one was designed around.
Table 2. E2B compared with adjacent platforms.
| Service | Best for | Isolation model | Typical pricing |
|---|---|---|---|
| E2B | Headless AI agent code and desktop execution | Firecracker microVM | Free tier with $100 credit, then $150/mo Pro plus usage ($0.000014–$0.000112/vCPU-sec) |
| Daytona | Open-source dev environments for humans and AI | Container or microVM, self-hostable | Self-host free, or managed cloud |
| Modal | General-purpose serverless Python, sandboxes as one feature among many | gVisor / microVM depending on workload | Function-based, pay per compute-second |
| Replit Agent | Hosted agent plus a full IDE for end users | Managed container environment | Bundled into Replit subscription tiers |
| GitHub Codespaces | Human developers working in a full VS Code instance | Managed container | Per-hour compute billing |
| Local Docker | Prototyping only, trusted code only | Shared host kernel | Free, but no real isolation guarantee |
The clearest way to think about the landscape: Replit Agent wraps a sandbox in a polished, human-facing IDE, which makes it excellent for building an app from a prompt but not something you would embed headlessly inside your own product. E2B is the opposite end of that spectrum, headless infrastructure meant to sit invisibly behind a Replit-style product or any other agent application. For developers who want an agent working directly on their own local machine instead of a remote sandbox at all, Claude Code takes that different approach, trading isolation for direct access to your real project files and environment.
Pricing in 2026
E2B runs on a freemium, usage-based model. The Hobby tier is free and comes with a one-time $100 usage credit, sessions capped at one hour, up to 20 concurrent sandboxes, and 10 GiB of free storage. The Pro tier costs $150 per month, extends sessions to 24 hours, raises concurrency to 100 sandboxes (expandable to 1,100), adds 20 GiB of storage, and unlocks adjustable CPU and RAM per sandbox. An Enterprise-style "Ultimate" tier is available with custom pricing for large-scale deployments.
On top of the monthly plan, usage is billed per second of running sandbox time: roughly $0.000014 per vCPU-second on the low end scaling up to $0.000112 per vCPU-second for 8-vCPU sandboxes, plus about $0.0000045 per GiB-second of RAM. For most agent applications, a single sandboxed task, spinning up, running a script, and tearing down, costs a small fraction of a cent. That per-second granularity, paired with the sub-100-millisecond cold start, is what lets the pricing model scale gracefully from a solo developer's weekend prototype to a Fortune 100 deployment running millions of sandboxes a month.
Real-world use cases in 2026
- Data analysis agents — read a CSV a user uploaded, run pandas transformations, generate a chart, and return the image alongside a written summary
- Code review bots — check out a pull request and execute its test suite in full isolation before a human reviewer ever looks at it
- AI tutors and coding education platforms — let students run code an LLM wrote without trusting the student's own browser sandbox as the only line of defense
- Research and fact-checking agents — the Perplexity-style pattern of having the model do real arithmetic or data lookups and verify a claim by actually running the computation, rather than generating a plausible-sounding number
- Browser and desktop automation — pairing E2B's code sandbox or desktop sandbox with tools like Playwright for end-to-end web tasks a human would otherwise do by hand
- Multi-agent systems like Manus — a planner agent assigns subtasks to executor agents, each of which gets its own sandboxed "virtual computer" to work in, mirroring how a human team might divide labor
Limitations and honest trade-offs
E2B is not a GPU platform. It solves CPU-bound code execution and desktop control, not training or running large models, so teams that need GPU inference or fine-tuning infrastructure are looking at a different category of product entirely. It also does not manage the agent loop itself; you still have to bring your own orchestration layer, whether that is LangGraph, CrewAI, the OpenAI Agents SDK, or a framework you built yourself, as covered in CrewAI vs. LangGraph vs. AutoGen.
And while each sandbox is isolated from every other sandbox, isolation does not solve every security problem an agent faces. Prompt injection, where malicious instructions hidden in a webpage, document, or tool output trick the agent into taking an action it shouldn't, is still an application-layer problem you have to defend against yourself. A perfectly isolated sandbox will faithfully execute a malicious command just as well as a benign one; it simply guarantees that the damage stays contained to that sandbox rather than spreading to your production systems. Isolation limits blast radius. It does not replace judgment about what the agent should be allowed to attempt in the first place.
There is also a cost consideration for very high-frequency, very short-lived tasks. At sub-cent per execution, E2B is inexpensive at moderate scale, but teams running enormous volumes of trivial, low-risk executions (say, evaluating a simple math expression a thousand times a second) may find that a lighter-weight, less isolated execution path is more cost-effective for that narrow slice of workload, reserving full sandbox isolation for anything that touches the file system, network, or user data.
Common misconceptions
A recurring confusion is treating E2B as a competitor to LLM providers like OpenAI or Anthropic. It is not. E2B does not train or serve language models at all; it is purely the execution layer that sits downstream of whatever model your agent uses to decide what code to run. Comparing E2B to GPT or Claude is a category error, the same as comparing AWS Lambda to a search engine.
Another common misread is assuming "sandboxed" means "safe from all misuse." Sandboxing solves the blast radius problem: it stops bad code from reaching your production systems, user data outside the sandbox, or other users' sessions. It does not stop an agent from being tricked into doing something unhelpful or embarrassing within its own sandbox, and it does not vet whether the code the model wrote actually does what the user wanted. Those remain product and prompt-engineering problems.
Finally, people sometimes assume Firecracker microVMs are slow because "VM" traditionally implies a heavyweight, minutes-long boot process, like spinning up a full VMware image. Firecracker was specifically engineered to strip that overhead down to what is needed for short-lived, high-density workloads, which is exactly why AWS chose it for Lambda in the first place and why E2B's cold starts land in the tens of milliseconds rather than the tens of seconds range typical of legacy virtualization.
The bigger picture
The rise of E2B reflects a structural shift in what "AI inference" even means in production. Through 2023, most AI products were about generating text and stopping there. By 2026, a growing share of serious agent products are judged on whether they can execute actions in the world and verify the result, not just describe what they would theoretically do. Every credible agent framework, from CrewAI to LangGraph to AutoGen, assumes somewhere in its architecture that there is a safe place to run code, browse a desktop, or interact with the web.
E2B has positioned itself as, in effect, the AWS of agent execution: mostly invisible to the end user typing a prompt into Perplexity or Manus, but load-bearing infrastructure for the teams building those products. The 375-fold growth in monthly sandbox runs between March 2024 and March 2025 is as much a signal about the pace of agent adoption industry-wide as it is about E2B specifically. As more products move from "the model describes an answer" to "the model does the work and shows its receipts," the sandbox layer underneath it becomes as fundamental to AI infrastructure as the database or the load balancer already are to web infrastructure.
FAQ
Q: Is E2B open source? A: Yes. The core sandbox runtime is MIT licensed and available on GitHub. The hosted cloud service is paid, but self-hosting on your own infrastructure is possible if you want to run the Firecracker-based sandboxes yourself.
Q: How is E2B different from a regular Docker container? A: E2B uses Firecracker microVMs, which give VM-level isolation (a separate guest kernel) with container-level speed, around 78 milliseconds median cold start as of early 2026. Regular Docker containers share the host machine's kernel, which is fine for trusted code but riskier for AI-generated code from an untrusted or semi-trusted source.
Q: Can I use my own Docker image with E2B? A: Yes. E2B templates are built from Dockerfiles, so you can preinstall any language runtimes, system packages, or dependencies your agents need before the sandbox ever boots.
Q: Does E2B replace OpenAI's Code Interpreter? A: Largely, yes. E2B's Code Interpreter template is a near drop-in replacement, and many teams migrated to E2B after OpenAI restricted direct access to its own hosted Code Interpreter API.
Q: How does E2B compare to Modal for agent code execution? A: Modal is a broader serverless compute platform covering functions, GPU workloads, and scheduled jobs, with sandboxing as one feature among several. E2B is purpose-built specifically for sandboxed execution with agent-friendly primitives like persistent state, a full file system, and terminal access. For pure sandbox use E2B tends to be simpler to integrate; for mixed compute workloads that also need GPUs or scheduled functions, Modal covers more ground.
Q: Is E2B safe enough for production use? A: For executing untrusted, AI-generated code, yes. Firecracker is the same isolation technology AWS trusts for Lambda at massive scale. The larger production risk is prompt injection causing an agent to attempt something it shouldn't, which is an application-layer concern that sandboxing alone does not solve.
Q: What is E2B's desktop sandbox used for? A: It gives "computer use" agents a full Ubuntu desktop environment, complete with a graphical interface streamed over VNC, so an AI can click, type, and navigate applications the way a person would. E2B's open-source Surf project demonstrates this pattern using OpenAI's computer-use capabilities.
Q: How much does E2B cost for a small project? A: The Hobby tier is free and includes a one-time $100 usage credit, with sessions capped at one hour and up to 20 concurrent sandboxes, enough for most prototyping. Paid usage beyond that runs on a per-second basis for CPU and RAM, typically fractions of a cent per short task.
Q: Why did Manus choose E2B instead of building its own sandbox infrastructure? A: Manus initially tried Docker and found it too slow (10 to 20 second spin-up versus roughly 150 milliseconds for an E2B sandbox at the time) and too limited for full OS-level functionality across its 27 agent tools. Building equivalent infrastructure in-house was estimated to require three to five full-time engineers over several months, which made an existing managed platform the faster and cheaper path.
Q: Does sandboxing protect against prompt injection attacks? A: No, not directly. A sandbox limits the consequences of code execution by containing it to an isolated environment, but it does not stop an agent from being manipulated into attempting a malicious or unwanted action in the first place. Defending against prompt injection is a separate, application-layer responsibility.
Sources
- E2B official documentation and E2B pricing, e2b.dev (accessed 2026)
- Firecracker microVM project, AWS Open Source
- "How Manus Uses E2B to Provide Agents With Virtual Computers", E2B Blog
- "E2B is now supported in the OpenAI Agents SDK", E2B Blog
- E2B Surf: Computer Use Agent and E2B Desktop Sandbox, GitHub
- E2B Series A funding coverage, $21M led by Insight Partners (July 2025), company announcements
- Perplexity, Hugging Face, Cohere public engineering disclosures (2024–2025)
- LangChain, CrewAI, and OpenAI Agents SDK integration documentation referencing E2B sandboxes
Follow new articles
Add SciHub101 to your feed reader to see new science and technology stories.
About the Author
SciHub101 is an independent science and technology publication founded and edited by Buğra Sözeri, a software engineer and app developer based in Türkiye. AI tools assist with drafting and research. Source documentation in the existing archive is uneven, and articles are being reviewed and corrected. The Editorial Team byline identifies editorial responsibility; it does not certify specialist or independent human review. Where we compare products, anything built by our own team is labelled as such — see the editorial guidelines and About page for how corrections and disclosures work.
Related Articles
CrewAI vs LangGraph vs AutoGen Compared
CrewAI, LangGraph, and AutoGen compared across abstraction level, state management, production readiness, and multi-agent support for 2026.
What Is Cline? VS Code AI Coding Agent
Cline is a free, open-source VS Code extension that turns the editor into an autonomous AI coding agent. How it works, pricing, and when to use it.
AI Observability Explained: Monitoring Models and Agents in Production
AI observability combines telemetry, evaluation, drift detection and incident response so teams can understand what models and agents do after deployment.
Prompt Injection Explained: Why AI Systems Can Obey the Wrong Instructions
Prompt injection is a trust-boundary problem in AI applications. Learn how direct and indirect injections work conceptually, why tools and retrieval increase risk, and which defensive controls make systems safer.
