Where AI Agents Run Code: E2B vs Modal 2026

The infrastructure question nobody asks until an agent writes rm -rf / and means it.

In a single 48-hour weekend, the app builder Lovable spun up 1 million code sandboxes on Modal, with 20,000 running at once at peak - Modal. That is not a benchmark. That is a Tuesday for a modern AI product. Every one of those sandboxes existed because an AI model wrote code that a human never read, and something had to run it somewhere that could not touch anything important.

This is the part of the AI agent story that gets almost no attention and quietly decides whether a product works. The model gets the headlines. The framework gets the GitHub stars. But the moment an agent stops talking and starts doing, it needs a machine: a real Linux environment where it can install packages, execute the code it just generated, run a test suite, scrape a page, or crunch a spreadsheet, and then hand the result back. That machine has to boot in milliseconds, isolate untrusted code from everything else on the planet, cost close to nothing when idle, and disappear cleanly when the task is done.

Here is the problem: the obvious answer is wrong. The instinct is to reach for a Docker container, because containers are what we use to run code in the cloud. But a container shares the host kernel with everything else on the box, and a kernel is 40 million lines of C exposing more than 450 system calls. Untrusted, model-generated code plus a shared kernel is not a sandbox. It is an incident waiting for a CVE number. The entire category we are about to explore exists to solve that one structural mismatch.

This guide breaks down where AI agents actually run code in 2026: the two headline platforms (E2B and Modal), the deep technical substrate underneath them (Firecracker microVMs, gVisor, and V8 isolates), the full field of challengers, the managed shortcuts from Anthropic and OpenAI, what all of it really costs, and a decision framework you can use tomorrow. It is written for people who are building with agents, not just reading about them, and it starts from first principles rather than repeating the vendor pitch.

Contents

1. Why agents suddenly need somewhere to run code
2. First principles: a container is not a security boundary
3. The substrate: Firecracker, gVisor, and V8 isolates
4. E2B up close: the purpose-built agent sandbox
5. Modal up close: serverless compute that grew a sandbox
6. E2B vs Modal: the direct comparison
7. The challengers: Daytona, Vercel, Cloudflare, Fly, Northflank
8. The managed shortcut: Anthropic and OpenAI built-in execution
9. What it actually costs
10. How to choose: a decision framework
11. The 2026 to 2027 outlook

The 2026 Code-Execution Scorecard

Before the deep dives, here is the whole field in one view. This is a weighted scorecard of the platforms where AI agents run code, ranked by a single final score. It exists so you can compare a Fortune-100 sandbox provider and a two-person seed startup on the same axes, then re-weight for your own situation.

Four criteria, weighted by what actually matters when untrusted, model-written code needs a home:

• Isolation and security (30%): How thick is the wall between the agent's code and everything else? Hardware-enforced microVMs score highest, userspace kernels and isolates in the middle, plain containers lowest.
• Cold start and agent ergonomics (30%): How fast does a fresh environment appear, and how well does the platform fit the agent loop (SDKs, fork, pause, resume, snapshot)?
• Cost efficiency (25%): Effective price per unit of real work, including whether idle and I/O-wait time is billed.
• Scale and GPU (15%): Concurrency ceiling and whether a GPU can live inside the sandbox.

Each cell shows the score and the reason for it. The table is sorted by final score, highest first.

The first thing to notice is that the scores cluster. Nine of twelve platforms sit between 7.2 and 8.1. That is not a rounding artifact, it is the story of the market: by 2026 the field has largely converged on the same recipe of Firecracker microVMs, per-second billing, and snapshot-based fast starts, so differentiation now happens at the edges (ergonomics, region coverage, GPU access) rather than in the core. The second thing to notice is that Modal ranks ninth, which will look strange for a company valued at $4.65 billion. That is a deliberate consequence of the weights. This scorecard privileges isolation and agent-native ergonomics for untrusted code, where Modal is a strong generalist rather than a specialist. On the single axis of scale and GPU, Modal is a 10 and nobody else is close. If your agents need accelerators, mentally push that column's weight up and Modal jumps toward the top. The whole point of a transparent weighting is that you can do exactly that.

1. Why agents suddenly need somewhere to run code

For most of the short history of large language models, the model was the product and the output was text. You sent a prompt, you got words back, and whatever happened next was a human's job. That framing quietly broke in 2025 and shattered in 2026, because the most valuable thing an agent can do turned out to be writing and running code, not describing it. When an agent needs to analyze a CSV, it does not reason about the numbers in its head, it writes a few lines of pandas and executes them. When it needs to call ten tools, the efficient path is to write a script that orchestrates the calls rather than emitting ten separate tool-use blocks. Code is how an agent turns intention into a verifiable result.

This shift showed up first in coding agents, the tools that write software for you. Claude Code, OpenAI's Codex, Cursor's background agents, and Devin all share the same inner loop: propose a change, run it, read the error, try again. That loop only works if there is a real environment to run in, and it has to be an environment the agent can break without breaking anything else. We covered how these systems keep going for hours in our guide to long-running coding agents, and the mechanics of the write-run-observe cycle in our piece on how to write loops for AI coding agents. In both cases the sandbox is the unglamorous component that makes everything else possible.

The same pattern spread well beyond software. Anthropic formalized a technique where agents write code to call their tools rather than invoking tools one at a time, which turns a chatty back-and-forth into a single executable program and slashes token usage. That pattern is only safe if the code runs in isolation, which is why Anthropic's own code execution tool ships as a sandboxed container. The protocol plumbing behind this, and why it matters, is something we explored in MCP vs A2A. Meanwhile computer-use agents, which drive a full desktop, need an even heavier environment: a whole virtual machine with a screen. We went deep on that class in our agentic computer use guide.

The economics made the question urgent. An agent that runs for an hour and spawns a dozen sub-agents, as described in our parallel subagent fleet guide, might touch dozens of sandboxes in a single task. Multiply that by thousands of users and the execution layer becomes a line item that rivals the model bill. Understanding that cost structure is its own discipline, which is why we wrote the true cost of AI agents. The through-line is simple: as soon as agents became useful, compute became the bottleneck, and a new category of infrastructure grew up to serve it.

To see why this is a distinct product and not just "rent a server," it helps to look at the shape of the demand. Agent workloads are bursty, short-lived, and untrusted. A sandbox might live for 800 milliseconds or 8 hours, and you cannot predict which. It runs code no human vetted. It needs to appear the instant the agent decides to act, because a two-second cold start on every tool call destroys the interactivity that makes agents feel useful. And it needs to vanish and stop billing the moment the work is done. Traditional cloud primitives assume the opposite: long-lived servers, trusted code, and provisioning measured in minutes. The gap between those assumptions and the reality of agent workloads is the entire reason this market exists, and it is why the incumbents had to invent new primitives rather than reuse old ones.

2. First principles: a container is not a security boundary

Start with the question everyone skips: why can't an agent just run its code in a normal Docker container? Containers are cheap, fast, and everywhere. The answer is the single most important fact in this entire field, and it is worth stating plainly. A container is a resource-control mechanism, not a security boundary. As Marina Moore put it at KubeCon EU 2026, containers are a way to control resource usage, not a wall against a hostile tenant - Your Container Is Not a Sandbox. Every container on a host shares that host's single Linux kernel. If code inside the container can find one bug in that kernel, it owns the whole machine, and every other container on it.

This is not theoretical. The last two years produced a steady drip of real container escapes, each one a proof that untrusted code can break out of a shared-kernel box. Leaky Vessels (CVE-2024-21626) let malicious code reach the host filesystem through runc. NVIDIAscape (CVE-2025-23266) scored a 9.0 severity and let workloads escape through the GPU container toolkit. A separate runc masked-path race (CVE-2025-31133) and a kernel packet-socket use-after-free rounded out the list. The lesson from the pattern is not "patch faster." It is structural: when you put adversarial code and your production systems on the same kernel, you are one undisclosed bug away from catastrophe, and AI-generated code is adversarial by default because no human decided what it does.

The scale of the attack surface explains why. The Linux kernel is roughly 40 million lines of C and exposes more than 450 system calls, any of which might harbor an exploitable flaw - Your Container Is Not a Sandbox. A container does nothing to shrink that surface; it just namespaces it. The security researchers who price these things put a hypervisor escape (crossing a hardware virtualization boundary) at a $250,000 to $500,000 bug bounty, because it is genuinely rare, while container escapes keep getting CVE numbers. That price gap is the market's honest assessment of how much thicker a real virtualization wall is than a container's.

This is also why the security of the code-execution layer is inseparable from the security of the agent itself. An agent that can be tricked by a malicious web page into running attacker-chosen code is only as contained as its sandbox, a threat model we unpacked in our guide to prompt injection defense. If the sandbox is a shared-kernel container, a successful injection is not an annoyance, it is a host compromise. If the sandbox is a hardware-isolated microVM, the same injection is contained to a disposable box that gets thrown away seconds later. The strength of the boundary decides how bad a bad day gets.

The practical takeaway for anyone building with agents is that the isolation model is not a checkbox, it is the foundation. You can bolt observability, persistence, and pretty SDKs onto any substrate, but you cannot bolt on a security boundary after the fact. This is why the serious platforms all made the same expensive choice: they gave up the convenience of plain containers and built on virtualization technology that puts a hardware or kernel-level wall between the agent's code and the rest of the world. The next section is about exactly what those walls are made of.

3. The substrate: Firecracker, gVisor, and V8 isolates

Underneath almost every platform in the scorecard sit one of three isolation technologies, and understanding them turns vendor marketing into something you can reason about. They represent three different bets on the eternal tradeoff between security, speed, and compatibility. Once you can see which bet a platform made, its strengths and weaknesses stop being surprises.

The first and most important is Firecracker, an open-source virtual machine monitor that Amazon built to power AWS Lambda and Fargate, then released to the world. Firecracker runs each workload in a microVM: a stripped-down virtual machine with its own guest kernel, sitting behind the CPU's hardware virtualization boundary (Intel VT-x or AMD-V). The numbers are what make it special. A Firecracker microVM boots to the guest's /sbin/init in under 125 milliseconds, carries less than 5 MiB of memory overhead per VM, and a single host can create up to 150 microVMs per second - Firecracker specification. It achieves this by throwing away everything a normal VM does not need: the device model is minimal, the codebase is around 100,000 lines of Rust rather than the million-plus lines of QEMU. The result is a wall as strong as full virtualization at a fraction of the weight, which is exactly what you want for untrusted, disposable, per-agent environments. E2B, Vercel Sandbox, Fly.io, CodeSandbox SDK, and others all build on this class of technology.

The second is gVisor, Google's answer to the same problem from a different angle. Instead of booting a real guest kernel, gVisor runs a user-space kernel written in Go, called the Sentry, that intercepts every system call the workload makes and services it itself. As the gVisor docs put it, no system call is passed directly to the host; every supported call has an independent implementation in the Sentry - gVisor security model. This shrinks the host attack surface dramatically: the Sentry re-implements around 274 Linux syscalls while itself making only 53 to 68 calls to the real host kernel. The tradeoff is compatibility. Because gVisor only implements common functionality, some programs that need exotic kernel features break, and Google itself moved Cloud Run's second-generation environment to microVMs precisely because customers needed features gVisor had not implemented. Modal runs on gVisor (the runsc runtime), which is a defensible middle-ground choice: stronger than a plain container, lighter than a full microVM, with an occasional compatibility rough edge.

The third is the lightest and strangest: the V8 isolate, the technology Cloudflare uses for its Workers and its new agent runtime. An isolate is not a VM or a container at all; it is a sandboxed execution context inside a single process, the same mechanism that keeps browser tabs apart. Isolates start in a few milliseconds using a few megabytes, roughly 100x faster and 10x to 100x more memory-efficient than containers, with no cap on how many you can run - Cloudflare. The catch is that isolation is software-enforced rather than hardware-enforced, so Cloudflare layers defenses (tenant cordons, a second-layer sandbox, hardware memory protection keys, and V8 patches deployed within hours), and code is largely constrained to JavaScript and WebAssembly. It is a bet that software isolation plus defense-in-depth can be good enough at a scale hardware VMs cannot reach.

There is a fourth ingredient that ties the substrate to the experience, and it is the one that turns a slow platform into a fast one: snapshotting. Booting a kernel is fast, but installing PyTorch and importing it can take five seconds, which is an eternity on every cold start. The trick everyone now uses is to run that expensive initialization once, snapshot the entire memory and process state, and restore from the snapshot instead of re-running init. AWS Lambda's SnapStart does this with Firecracker snapshots. Modal's memory snapshots take an import-heavy program from a roughly 5-second cold start down to about 1.05 seconds at the median, and Modal extended the same trick to GPU and CUDA state in early 2025 - Modal. Firecracker's own resume-from-snapshot uses a Linux feature called userfaultfd to lazily fault guest memory pages back in on demand. The upshot is that the line between "cold" and "warm" has blurred: the best platforms make a fresh, fully-initialized environment appear in about a second, and the fastest make it appear in milliseconds. That engineering is why running agent code at scale is now practical rather than painful.

It is worth being precise about the two flavors of snapshot, because they are not the same thing and the difference quietly affects what you can rely on. A Firecracker snapshot freezes an entire microVM, guest kernel and device state included, behind the virtualization boundary, so restoring it brings back a complete machine exactly as it was. A CRIU snapshot (Checkpoint/Restore In Userspace, the mechanism behind gVisor-based memory snapshots) freezes a process tree on the host instead: its memory, open files, and sockets, but no guest kernel - debugg.ai. The practical consequence is that microVM snapshots restore a fuller, more faithful environment, while process-tree snapshots are lighter but more sensitive to what changed on the host underneath them. The best providers then layer working-set prediction on top, pre-faulting the memory pages a workload is likely to touch first so a restored sandbox is responsive from the first instruction rather than stuttering as pages fault in lazily. This is invisible engineering that decides whether "sub-second cold start" means a snappy environment or a sluggish one, and it is a genuine axis of differentiation hiding behind identical-looking latency numbers on a marketing page.

4. E2B up close: the purpose-built agent sandbox

E2B is the platform that defined this category, and it is worth understanding in detail because its design choices set the template everyone else responds to. Founded in 2023 by Vasek Mlejnsky and Tomas Valenta, E2B (the name is short for "environment to business") made one decisive bet: build a cloud whose only job is running AI-generated code, and build it on Firecracker microVMs so that isolation is never the thing you have to worry about. Every E2B sandbox is a microVM with its own kernel, the same class of hardware isolation that powers AWS Lambda, which means an agent can run whatever it wants inside without any path to the host or to other tenants.

The developer experience is where E2B earns its lead. It ships Python and JavaScript/TypeScript SDKs, including an open-source Code Interpreter SDK licensed Apache 2.0, so adding "run this code and give me the result" to an app is a few lines rather than an infrastructure project - E2B. Sandboxes start in under 200 milliseconds in-region, with E2B citing an 80-millisecond quick-start and marketing "no cold starts." Sessions can run up to 24 hours on the paid tier. Crucially for agents that branch and backtrack, E2B exposes fork and snapshot primitives: an agent can pause a sandbox, preserving not just the filesystem but the entire memory state (running processes, loaded variables, everything), keep it paused indefinitely with no time-to-live, and resume it in about a second - E2B docs. Pausing costs roughly 4 seconds per gigabyte of RAM, resuming takes about 1 second, and the underlying Firecracker snapshot machinery uses lazy page-faulting so the sandbox is responsive almost immediately.

The commercial signals say this bet worked. In July 2025, E2B raised a $21 million Series A led by Insight Partners, with participation from Decibel, Sunflower Capital, Kaya, and angels including former Docker CEO Scott Johnston, bringing total funding to about $32 million - Insight Partners. By 2026 the company reports the vast majority of the Fortune 100 as users, more than 1 billion sandboxes started, and millions of monthly SDK downloads, with named customers including Perplexity, Manus, Hugging Face, Groq, and Lindy. The pricing is transparent and per-second: a free Hobby tier with a one-time $100 credit, a Pro tier at $150 per month plus usage (up to 24-hour sessions and up to 100 concurrent sandboxes, expandable to 1,100), and custom Enterprise - E2B. Compute bills at $0.000014 per vCPU-second (about $0.0504 per vCPU-hour) with RAM at $0.0000045 per GiB-second. For teams that need control, E2B is self-hostable via Terraform on AWS and GCP.

What this looks like in code is deliberately unremarkable, which is exactly the point. An agent framework creates a sandbox, runs the snippet the model just wrote, and reads the result back in a handful of lines: instantiate a sandbox, call something like run_code with the generated Python, and receive stdout, stderr, and any files it produced. Because the Code Interpreter SDK is open source under Apache 2.0, teams can read precisely what happens to their code rather than trusting a black box, and if compliance demands it, run the whole stack inside their own account. That self-hosting path is not a footnote for regulated industries: a bank or a hospital running an agent over transaction or patient data frequently cannot send that data to a third-party sandbox at all, and E2B's bring-your-own-cloud deployment lets them keep the microVM isolation model while keeping the data inside their own perimeter. The combination of a trivial hosted SDK for the common case and a self-hostable substrate for the strict case is a large part of why E2B landed the enterprise logos it advertises, because the same product serves the startup prototyping on a laptop and the bank with a compliance team.

To hear the thinking behind it directly from the source, this recent conversation with E2B's founder covers why agents need isolated execution and how the Firecracker approach came to be.

E2B's ecosystem position is as important as its technology. In April 2026 it became a supported hosted-sandbox provider in the OpenAI Agents SDK, which means developers building on OpenAI's stack can point their agents at E2B for execution without wiring anything up themselves. That kind of integration is the real moat in this category: not the microVM, which everyone has, but being the default execution target inside the frameworks agents are actually built with.

Where E2B loses points is exactly where its focus narrows. It is CPU-first: you cannot run a heavy GPU workload inside an E2B sandbox the way you can on a general compute platform, so an agent that needs to fine-tune a model or run a large diffusion job has to look elsewhere. Its concurrency ceiling, while high, is bounded (up to 1,100 concurrent on Pro), which is plenty for most products but not the "infinite tabs" model of an isolate platform. E2B is the right answer when the shape of your problem is many short-lived, stateful, security-sensitive code-execution sessions, which describes most coding agents and most data-analysis agents. It is the wrong answer when your bottleneck is a GPU.

5. Modal up close: serverless compute that grew a sandbox

Modal comes at the same problem from the opposite direction, and the contrast is the heart of this guide. Where E2B started as a sandbox and stayed one, Modal started as a general-purpose serverless compute platform and grew a sandbox as one product among many. Founded in 2021 by Erik Bernhardsson (the creator of Spotify's music recommendation system and the Luigi workflow tool), Modal lets you define containers and functions in plain Python and have them provisioned on demand, scaling from zero to thousands of containers or hundreds of GPUs in seconds, billed per second. Its original audience was ML teams running inference, training, and batch jobs, and that heritage shapes everything about it.

The sandbox itself is the modal.Sandbox API, and Modal describes it bluntly: a Sandbox is a secure container for executing untrusted user or agent code - Modal docs. It runs on gVisor, so the isolation is the userspace-kernel model rather than a full microVM, and Modal is explicit that even a container escape only reaches the userspace kernel, not the host. You get exec() for arbitrary commands, custom images and Dockerfiles, mounted volumes, secrets, readiness probes, and lifetimes configurable up to 24 hours. The default sandbox lifetime is a short 5 minutes, and for anything that needs to outlive that, Modal recommends filesystem snapshots to restore state into a fresh sandbox rather than keeping one alive. The company says production users run millions of untrusted snippets daily and it supports more than 50,000 concurrent sessions - Modal.

The ergonomics reflect Modal's job-runner heritage in ways that help some agents and hinder others. Because a sandbox is defined by the same image machinery as the rest of Modal, an agent can hand it a custom Dockerfile, mount a persistent volume, inject secrets, and probe readiness over TCP or a command before sending work, which is exactly the tooling you want when the sandbox is really a short-lived build-and-test environment for a coding agent. Modal even ships a dedicated coding-agents solution built on this primitive, aimed at teams whose agents check out a repository, install dependencies, and run a test suite before proposing a change - Modal. That workflow is the natural home for the kind of repo-aware agent we described in our guide to text indexing for coding agents, where the agent needs a full checkout to be useful. The friction appears only when an agent wants a long-lived, always-warm session it can poke at intermittently, because Modal's model nudges you toward finishing the job and snapshotting rather than keeping a machine idling. For a discrete compute job that is the correct default; for a chatty, stateful agent it is one more thing to manage.

Modal's real superpower is the thing E2B deliberately skipped: GPUs inside the sandbox. Because Modal is a compute platform first, an agent's code can run on an H100, an A100, a B200, or a cheaper T4, priced per second. The current rates are $0.001097 per second for an H100 SXM5 (about $3.95 per hour), $0.000694 per second for an A100 80GB, and $0.001736 per second for a B200, down to $0.000164 per second for a T4 - Modal. CPU bills at $0.0000131 per core-second and memory at $0.00000222 per GiB-second, with plan tiers of a free Starter ($30 monthly credits) and a Team plan at $250 per month. Modal's cold-start engineering is genuinely best-in-class: its memory snapshots cut cold starts by more than 50%, and it shipped GPU memory snapshots that bring checkpoint/restore to CUDA workloads, so even a model-loading function can restore in sub-second time.

The customers and the capital both reflect that GPU-native positioning. Suno used Modal to bring a state-of-the-art music model to market roughly four months early; Substack moved nearly all its ML training and deployment off AWS SageMaker onto Modal; Ramp uses it for its most data-intensive projects; and, as mentioned at the top, Lovable generated 1 million sandboxes in 48 hours on it. The funding trajectory is one of the steepest in AI infrastructure: a $16 million Series A led by Redpoint in October 2023, an $87 million Series B at a $1.1 billion valuation in September 2025, and then a $355 million Series C at a $4.65 billion valuation announced May 21, 2026, led by General Catalyst and Redpoint with Accel and Menlo participating - Modal. Reported revenue went from about $60 million annualized in September 2025 to roughly $300 million by spring 2026, a fivefold jump in six months. This is a company riding the exact wave this guide is about.

Modal Sandboxes in production look like real agent workloads, not demos. When Quora's Poe runs untrusted, LLM-generated code, it does so inside a Modal Sandbox; when Codegen analyzes a repository's structure, the same primitive does the work. The screenshot below, from Modal's own launch materials, shows Poe executing code in a sandbox.

Modal's weakness, in the specific frame of this guide, is the mirror image of E2B's. Its isolation is gVisor rather than a hardware microVM, which is strong but a notch thinner for the most adversarial code. Its sandbox pricing tier runs several times higher than its standard function rate, so pure CPU-only code execution is not the cheapest way to use Modal. And the 5-minute default lifetime plus the "snapshot into a new sandbox" model for persistence is a slightly heavier ergonomic than E2B's pause-and-resume-in-place. None of that matters if you need a GPU, and all of it matters if you do not. That single distinction is what the next section is about.

6. E2B vs Modal: the direct comparison

Now the head-to-head. The temptation is to ask "which is better," but that question has no answer because the two platforms are optimized for different shapes of workload. The useful question is "which fits the code my agents actually run," and answering it requires holding four axes side by side: isolation, ergonomics, cost, and GPU. On each one the platforms make a clear, defensible, opposite choice.

On isolation, E2B wins on paper. Firecracker gives each sandbox its own guest kernel behind a hardware virtualization boundary, which is the thickest wall in commodity infrastructure. Modal's gVisor intercepts syscalls in userspace, which is meaningfully stronger than a container and weaker than a microVM. For most workloads the difference is academic, because both are far beyond "safe enough" for typical agent code. For the genuinely adversarial case, where you are running code from anonymous internet users at scale, the microVM boundary is the one security teams prefer, and the $250,000-plus bounty on hypervisor escapes is the reason. As the comparison writers at Northflank summarized it, E2B sandboxes use microVM isolation purpose-built for untrusted code while Modal sandboxes use gVisor-based isolation inside a wider platform - Northflank.

On ergonomics and persistence, E2B is tuned for the agent loop and Modal is tuned for the compute job. E2B's pause preserves filesystem and memory together and holds it indefinitely with a roughly 1-second resume, which maps perfectly onto an agent that starts a task, waits on a human or a slow API, and comes back. Modal's sandboxes default to a 5-minute lifetime and lean on filesystem snapshots for longer-lived state, which fits a job that runs, produces output, and exits. Both cap a single session at 24 hours. If your agent needs to keep a live, stateful session warm across long gaps, E2B's model is less friction; if your agent runs discrete compute jobs, Modal's model is perfectly natural. The persistence question connects directly to how agents remember and resume work, which we explored in our guide to AI agent memory architectures.

On cost, for CPU-only work, E2B is cheaper. Independent benchmarking put E2B near $0.083 per hour and Modal near $0.119 per hour for equivalent CPU-only sandboxes, with E2B's per-vCPU rate of about $0.0504 per hour undercutting Modal's sandbox tier, which runs roughly 3x its standard function CPU rate - Superagent. But this comparison inverts the instant a GPU enters the picture, because E2B cannot put one inside a sandbox at all and Modal can. For a workload that needs an H100, the question is not "which is cheaper per CPU-hour" but "which one can even run this," and the answer is only Modal.

That is the whole comparison in one sentence: E2B is a sandbox that is a platform, and Modal is a platform that has a sandbox. Choose E2B when the workload is many short-lived, stateful, security-sensitive, CPU-bound code sessions, which is most coding agents, most data-analysis agents, and most tool-execution loops. Choose Modal when the workload touches a GPU, needs very high concurrency of compute jobs, or when you also want the broader inference-and-training platform under the same roof. The market has voted with both wallets: E2B raised its Series A on the "sandbox for the Fortune 100" story, and Modal raised a $4.65 billion round on the "production cloud for AI" story. Both are correct, because they are answering different questions.

7. The challengers: Daytona, Vercel, Cloudflare, Fly, Northflank

If E2B and Modal were the whole story, this would be a simpler market. They are not. By mid-2026 the "where agents run code" space had exploded into three tiers, and the challengers are where a lot of the interesting engineering and aggressive pricing now lives. The first tier is dedicated agent-sandbox startups. The second is platform incumbents shipping first-party sandbox primitives. The third is managed model-provider tools, which get their own section next. Understanding the challengers matters because for many teams one of them, not E2B or Modal, is the right answer.

Daytona is the speed play. After pivoting to agent-sandbox infrastructure in early 2025, it advertises sub-90-millisecond cold starts from code to execution, the fastest real-environment start in the field, and it crossed $1 million in annual recurring revenue within two months of the pivot before raising a $24 million Series A led by FirstMark Capital in February 2026 - Unicorner. Its isolation is container-based rather than microVM, which is why it scores lower on that axis, but for teams that value raw start latency and an agent-native API above the thickest possible wall, Daytona is compelling. It bills per second at roughly $0.0504 per vCPU-hour, matching E2B.

The incumbents shipping first-party primitives are the bigger structural story, because they bring distribution. Vercel Sandbox went generally available on January 30, 2026, running untrusted agent code in ephemeral Firecracker microVMs with a dedicated kernel, private filesystem, and network isolation, and it makes persistence the default (auto-save on stop, resume where you left off) - Vercel. Its default image ships Node LTS, Python 3.14, and coding agents preinstalled, and it isolates multiple agents by giving each its own Linux user. The catch at GA was single-region availability (US East, iad1) and a higher headline rate ($0.128 per vCPU-hour), softened by active-CPU billing where I/O wait is free, which Vercel says cuts costs up to 95% for bursty agent workloads. For teams already deploying on Vercel, the sandbox being one primitive away is a real advantage.

Cloudflare made the most architecturally distinct bet. It shipped Containers and a Sandbox SDK to general availability on April 13, 2026, combining Workers, Durable Objects (which give a sandbox a persistent identity), and Containers, with active-CPU pricing around $0.072 per vCPU-hour and capacity for thousands of concurrent containers - Cloudflare. Then on August 3, 2026 it shipped @cloudflare/computer, an agent runtime that gives an agent one filesystem and lets it choose, per command, between a lightweight V8 isolate and a full Linux container. That isolate-or-container hybrid is a genuine departure from the microVM-per-sandbox consensus, and it is a bet that most agent commands are cheap enough to run in a millisecond-scale isolate while only the heavy ones need a container. The capital flooding this tier is not trivial either, and it rhymes with the broader buildout we documented in the debt-funded AI infrastructure revolution.

Rounding out the field are the mature-infrastructure and specialist players. Fly.io Machines are Firecracker microVMs that start and stop in milliseconds on a global private network, and Fly's agent-sandbox product (Sprites) is priced at $0.07 per CPU-hour - Fly.io. Northflank has operated sandboxing infrastructure since 2019, processing more than 2 million isolated workloads monthly, and offers the broadest isolation lineup (Kata Containers, Firecracker, or gVisor per workload) at the lowest price in the field, $0.01667 per vCPU-hour, with H100 GPUs at $2.74 per hour and bring-your-own-cloud support - Northflank. And a wave of seed-stage specialists is pushing the frontier: Runloop offers devboxes purpose-built for coding agents with suspend/resume that accrues no charge while suspended, Blaxel offers a "perpetual sandbox" with sub-25-millisecond resume from standby and claims 50,000-plus concurrent sandboxes, and CodeSandbox SDK (backed by Together AI) specializes in memory snapshotting and environment forking so agents can branch decisions cheaply. The takeaway from the sheer length of this list is that the category has real depth: whatever specific shape your agent's workload has (fastest start, cheapest CPU, GPU access, deepest forking, best framework integration), there is now a platform optimized for exactly that, and the competition is driving both prices and cold starts down every quarter.

Two further categories deserve a mention because they serve needs the mainstream sandbox startups do not. The first is the self-hosted, governed tier, exemplified by Coder, which raised a $90 million Series C led by KKR in April 2026 and defines cloud development environments and agent workspaces in Terraform, connected over a WireGuard tunnel and shut down automatically when idle - Coder. Its pitch is not raw speed but control and auditability: an enterprise that needs every agent execution logged, governed, and running inside its own network perimeter reaches for this rather than a public sandbox, and Coder cites more than 100,000 open-source users behind that positioning. The second is the scale-to-zero GPU tier, exemplified by Beam, which bills by the millisecond, scales sandboxes to zero by default, and does not charge during image pulls or queue waits, with an open-source core and bring-your-own-cloud - Beam. Between them, these two tiers cover the ends the mainstream providers underserve: maximum governance on one side and maximum cost-efficiency for spiky GPU work on the other. Any team whose real constraint is a compliance auditor or a finance spreadsheet, rather than a cold-start benchmark, should start here rather than with the fastest-booting option.

A word of caution on reading a chart like the one above: headline rates are not effective costs. A platform at $0.072 per vCPU-hour that only bills active CPU can be cheaper in practice than one at $0.05 that bills wall-clock, because agent workloads spend most of their time waiting on model calls and network I/O, not computing. This is the same lesson that recurs throughout agent economics, and it is why the cost section below treats metering model as seriously as the sticker price. The cheapest number on a pricing page is frequently not the cheapest bill.

8. The managed shortcut: Anthropic and OpenAI built-in execution

There is a category that sidesteps this entire decision, and for many teams it is the right one: let the model provider run the code for you. Both Anthropic and OpenAI ship a built-in code execution tool that hides the sandbox completely. You do not choose a runtime, provision a microVM, or think about isolation; you turn on a tool and the model can write and run code, with the provider operating the sandbox behind their own security team. For a large fraction of agent use cases (analyze this file, do this math, transform this data), that is not a compromise, it is the correct level of abstraction.

Anthropic's code execution tool runs Python and Bash in a secure, ephemeral sandboxed container, and it has an unusual pricing quirk: it is free when used together with web search or web fetch - Anthropic. It also powers the "agents write code to call tools" pattern that makes multi-tool workflows dramatically more token-efficient, and it pairs naturally with the broader capabilities of the Claude Agent SDK, which we covered in depth in our Claude Agent SDK deep dive. The tradeoffs are the ones you would expect from a managed service: files do not persist between calls unless you use the newer REPL-persistence version, you get Python and Bash rather than an arbitrary environment, and there is no GPU. In exchange you get zero operational burden and provider-grade hardening.

OpenAI's Code Interpreter runs Python in a sandboxed environment priced at $0.03 per session (active up to one hour per thread), isolated from your infrastructure though not from data you upload - OpenAI. The important operational detail in 2026 is that the Assistants API that historically hosted it is deprecated and shuts down on August 26, 2026, with the functionality moving to the newer Responses API. Any team relying on the old surface needs to migrate, which is a reminder that even the managed shortcut is not free of maintenance: the provider changes the ground under you on their schedule, not yours.

The honest way to frame these managed tools is as one rung up an abstraction ladder, and it is worth naming all the rungs because choosing the right one is most of the battle. At the bottom you run raw microVMs yourself on Fly or Firecracker directly. Above that you rent a purpose-built sandbox layer like E2B, Modal, or Daytona, which handles isolation and lifecycle but leaves orchestration to you. Above that you use a provider's built-in execution tool and stop thinking about the sandbox at all. And above that, you stop assembling the agent stack entirely: platforms like o-mega.ai let you describe an autonomous company in a conversation and have one AI build and run the whole thing, execution substrate included, so the "where does the code run" question never reaches your desk. Each rung trades control for convenience. The mistake is not picking the wrong rung, it is picking a rung without realizing there was a ladder, and building your own microVM orchestration when a built-in tool would have done.

9. What it actually costs

Money is where abstract architecture becomes a monthly invoice, and the economics of running agent code have a few counterintuitive properties that catch teams off guard. The first is that the metering model matters more than the rate. Agent workloads are dominated by waiting: an agent spends most of a task blocked on a model response, a web request, or a database query, not burning CPU. A platform that bills wall-clock time charges you for all that waiting; a platform that bills only active CPU does not. This is why Vercel's $0.128 per vCPU-hour with active-CPU metering can produce a smaller bill than a $0.05 platform that meters wall-clock, and why the newer entrants have almost all moved to active-CPU or scale-to-zero pricing. When you model cost, model the workload's duty cycle, not just its hourly rate.

A worked example makes the duty-cycle point concrete. Imagine an agent that runs for ten minutes of wall-clock time per task but spends eight of those minutes waiting on model responses and API calls, using the CPU for only two. On a wall-clock-billed sandbox at $0.0504 per vCPU-hour with two vCPUs, you pay for the full ten minutes, roughly $0.0168 per task. On an active-CPU-billed platform you pay for only the two minutes of real compute, about a fifth as much, even when its headline rate looks higher. Across a million tasks a month that gap is the difference between a bill near $16,800 and one closer to $3,400, which is why the metering model, not the sticker price, is the first thing to check. The same arithmetic explains why pausing a sandbox between agent turns (rather than leaving it running while the model thinks) is one of the highest-leverage cost optimizations available, and why platforms compete so fiercely on how cheaply and quickly they can pause and resume. It is also why the swarm-of-agents pattern, where dozens of cheap workers run in parallel, only pencils out on infrastructure that meters honestly, a point we made in our guide to cost-efficient agent swarms.

The second property is that GPU changes the math by orders of magnitude. CPU sandbox time is measured in cents per hour; GPU time is measured in dollars per hour. An H100 runs about $3.95 per hour on Modal, $2.74 on Northflank, $2.89 as a Runpod pod, and $3.50 on Beam, while a B200 on an inference-focused platform like Baseten can reach nearly $10 per hour - Costbench. If your agents are CPU-bound, the sandbox is a rounding error next to your model bill; if they touch GPUs, the sandbox can become the dominant cost. This is the same dynamic that drives the broader inference economy we analyzed in the true cost of LLM inference, and it is why GPU-native platforms compete so hard on per-second billing and scale-to-zero: idle accelerators are ruinously expensive.

The third property is that the vendors themselves are expensive to run, which shapes their pricing and their durability. Modal's revenue trajectory tells the story of a market growing faster than almost anything in software: from roughly $60 million annualized in September 2025 to about $300 million by spring 2026, alongside a valuation that went from $1.1 billion to $4.65 billion in eight months. That is not a company that needs to squeeze margins out of small customers, which is why the free tiers and generous credits persist. But it is also a reminder that this infrastructure is being funded by an extraordinary flood of capital, and capital flows change. The same wave lifted GPU-cloud specialists like Nebius, which raised $700 million from Nvidia and Accel, as we covered in our Nebius infrastructure analysis.

The practical way to control these costs is the same discipline that applies to the rest of the agent stack: measure the real duty cycle, right-size the environment, and do not pay for idle. For CPU workloads, prefer active-CPU or scale-to-zero billing and pause aggressively between agent turns. For GPU workloads, use snapshotting to avoid re-paying model-load cold starts, and scale to zero the instant a job finishes. And route work to the cheapest environment that can do it: not every agent step needs a GPU, and not every step needs a fresh sandbox. The same routing logic that cuts model costs, which we detailed in our guide to AI model routing, applies to compute: send the heavy job to the heavy machine and the light job to the light one, and never the reverse.

10. How to choose: a decision framework

With the field mapped, the choice comes down to a short sequence of honest questions about your own workload, asked in the right order. The order matters because the first question that returns a hard constraint should dominate the decision; everything after it is optimization. Do not start with "which platform is best," start with "what does my code actually need," and let the answer eliminate options until few remain.

The first question is about the code's nature: does it need a GPU? If yes, most of the field disappears immediately, because CPU-first sandboxes like E2B, Daytona, and the managed provider tools cannot run one inside the sandbox. You are choosing among Modal, Northflank, Runpod, Beam, and the other GPU-capable platforms, and the sub-question becomes whether you also need the broader inference-and-training platform (Modal) or just cheap accelerators (Runpod, Northflank). If the answer is no GPU, the whole field stays open and the decision moves to isolation and ergonomics.

The second question is about trust: how adversarial is the code? If you are running code from anonymous internet users at scale, the hardware boundary of a Firecracker microVM (E2B, Vercel, Fly, CodeSandbox) is the boundary security teams prefer, and the gVisor and isolate options become a harder sell. If the code is your own agents acting on your own data, gVisor and even well-hardened isolates are perfectly reasonable, and you can optimize for speed and cost instead. This is not a question you can skip, because getting it wrong is the difference between a contained incident and a breach, and it connects directly to the prompt injection threat model where a compromised agent is only as dangerous as its sandbox is weak.

The third question is about shape: short bursts or long jobs? Many short-lived, stateful sessions that pause and resume across long gaps point toward E2B's persistence model or Blaxel's perpetual sandboxes. Discrete compute jobs that run and exit point toward Modal or a general microVM platform. Very high concurrency of tiny executions points toward Cloudflare's isolate model, which has no meaningful concurrency cap. And if your agents branch and backtrack (trying multiple approaches from a common state), a fork-and-snapshot specialist like CodeSandbox SDK or E2B's fork primitive saves real money by not re-running the setup for every branch.

The fourth question is about operational appetite: how much do you want to run yourself? The honest answer for most teams is "as little as possible," and that pushes toward the managed end of the abstraction ladder. If you never want to think about the sandbox, a provider's built-in code execution tool or a full managed agent platform is the right call, and you accept the constraints (Python-and-bash, no GPU, provider-controlled lifecycle) as the price of zero operations. If you have specific needs the managed tools cannot meet, you drop down a rung to a rented sandbox layer, and only if you have unusual scale or compliance requirements do you go all the way down to running microVMs yourself. Match the rung to the appetite, and revisit it as you grow, because the right rung at ten users is rarely the right rung at ten thousand.

The framework deliberately resists a single winner, because there is not one. The most common failure mode in this decision is treating it as a popularity contest (pick the highest-valued vendor, or the one a competitor uses) rather than a fit problem. The scorecard at the top of this guide is a starting point, not a verdict: it encodes one reasonable set of weights, and the entire value of showing the weights is that you can change them. A team running untrusted code from strangers should push isolation to 40% and watch the microVM providers rise. A team running GPU fine-tuning should push scale-and-GPU up and watch Modal take the top. A cost-obsessed team at scale should push cost up and watch Northflank and Cloudflare rise. The right answer is the one that falls out of your weights, not ours.

11. The 2026 to 2027 outlook

Where does this go next? First-principles reasoning about the direction requires asking what fundamental force is driving the category, and the answer is clear: the number of agents is growing far faster than the number of humans, and every capable agent needs a place to run code. That single dynamic implies several things about the next eighteen months, and they are worth reasoning through rather than guessing.

The first implication is continued convergence and commoditization of the core substrate. Firecracker microVMs plus per-second billing plus snapshot-based fast starts have become table stakes, which is exactly why the scorecard scores cluster so tightly. When the core commoditizes, competition moves to the edges: framework integrations (being the default sandbox in the OpenAI Agents SDK or Claude's managed agents), region coverage, developer experience, and specialized primitives like sub-25-millisecond resume or environment forking. Expect the winners to be decided less by isolation technology, which everyone now has, and more by distribution and ergonomics. This mirrors how model access itself commoditized, a theme we traced in how LLM inference is eating software.

The second implication is the isolate-versus-microVM debate intensifying. Cloudflare's bet that most agent commands are cheap enough for a millisecond-scale V8 isolate, with only heavy commands escalating to a container, is a genuine architectural fork in the road. If it holds, it points to a future where the default agent runtime is far lighter and more concurrent than a microVM-per-sandbox world allows, and where the microVM is reserved for the minority of commands that truly need it. If it does not (if the compatibility constraints of isolates prove too limiting, or the software-isolation model shows cracks) the microVM consensus wins by default. This is the one place in the category where the fundamental architecture is genuinely unsettled, and it is worth watching closely.

The third implication is the managed layer swallowing more of the decision. As provider-built execution tools improve and full agent platforms mature, the fraction of teams that ever consciously choose a sandbox provider will shrink. Most developers did not choose their serverless function's underlying VM, and most will not choose their agent's underlying sandbox either; it will be an implementation detail of the platform they build on. The teams that keep choosing directly will be those with unusual requirements: extreme scale, strict compliance, GPU-heavy workloads, or a need to self-host. This is the natural endpoint of any infrastructure category, and it is already visible in the way self-improving agent systems abstract away their own execution substrate, a direction Yuma Heymans has written about at length. Heymans (@yumahey), who builds the autonomous-company platform O-mega, has spent the last year on precisely this problem of giving agents a real place to do work rather than just describe it, and his guide to self-improving AI agents treats the execution environment as a first-class part of what makes an agent actually autonomous.

The counter-narrative worth taking seriously is that this could all be a capital-fueled bubble in provider count. A dozen well-funded platforms competing for the same workloads, with prices and cold starts racing toward zero, is not a stable equilibrium; consolidation is likely, and Cloudflare's acquisition of Replicate (closed December 1, 2025) may be the first of several. The infrastructure itself is durable (agents will keep needing sandboxes) but the specific logos may not be. The pragmatic response is to build on a clean abstraction (an SDK you could repoint, or a platform that owns the substrate for you) rather than hard-wiring your agent to one vendor's proprietary API, so that when the market consolidates you can move. The direction of travel is certain even if the survivors are not: agents will run more code, in more places, more cheaply, and the layer that lets them do it safely will remain one of the most important and least visible parts of the stack.

Conclusion: the layer that decides whether agents work

Strip away the funding rounds and the cold-start benchmarks and the choice is simple to state. Where an agent runs code determines whether it can be trusted to run at all. The model decides what to do, the framework decides how to orchestrate it, but the execution layer decides whether "write and run this code" is a superpower or a liability. Get it right and your agents can act on the world safely at scale; get it wrong and you are one generated os.system() call away from an incident.

The decision framework compresses to a handful of moves. If your code needs a GPU, you are choosing among Modal, Northflank, and the accelerator specialists, and Modal's platform breadth justifies its premium when you need the whole stack. If your code is CPU-bound and you want the strongest isolation with the best agent ergonomics, E2B is the category-definer and the safe default. If you want the lowest cost at scale, Northflank and Cloudflare's active-CPU models win. If you want zero operations, the built-in tools from Anthropic and OpenAI, or a full managed platform like o-mega.ai that runs the substrate for you, are the right rung of the ladder. And if you have unusual scale or compliance needs, dropping down to raw Firecracker on Fly or a self-hosted E2B keeps you in control.

The meta-lesson is the one that survives every price change and product launch: choose the abstraction level deliberately, weight the criteria to your own workload rather than borrowing someone else's ranking, and build on an interface you could repoint if the market consolidates, which it will. The specific platform you pick in 2026 matters less than understanding why you picked it, because the platforms will keep changing and the reasoning will not. Agents that run code are the ones that get real work done, and now you know exactly where they do it.

This guide reflects the AI agent code-execution landscape as of August 2026. Pricing, funding, product availability, and model versions in this rapidly changing space move fast (Modal alone changed valuation three times in eight months), so verify current details on each provider's own pricing and documentation pages before committing.