Comparing AI agent sandbox platforms: E2B, Modal, Daytona, and more

Five dimensions separate AI agent sandbox platforms from one another: cold start, isolation, session persistence, SDK ergonomics, and pricing. No platform wins all five. The platforms that claim to do everything well usually optimize for one or two dimensions and accept tradeoffs everywhere else.

For most agents, one dimension matters more than the rest. A coding assistant that spins up an environment on every edit depends on cold start. An agent that runs untrusted user code depends on isolation. A research agent that holds a dataset across 20 tool calls depends on persistence. The right way to choose is to identify the dimension where a wrong decision would break the agent, the security model, or the budget. That becomes your shortlist, and the other dimensions become filters.

The matrix below compares 15 sandbox platforms across those dimensions, plus GPU support and deployment model.

Platform	Cold start	Isolation	Persistence	SDK	Pricing model	GPU	Deployment
E2B	717ms create / 662ms resume (measured)	Firecracker microVM	Pause/resume, snapshot	Python-first, TS	Per-sec full duration, $150/mo floor	No	Managed, BYOC (enterprise)
Daytona	742ms create / 1254ms resume (measured)	Docker container by default; Kata/Sysbox opt-in	Fork, pause/resume, snapshot	Python-first, TS	Per-sec, same rate as E2B	Yes	Managed, self-host
Modal	2437ms create / 2347ms snapshot boot (measured)	gVisor	Filesystem/memory snapshot; no in-place resume	Python-first	Per-sec active, scale to zero	Yes	Managed
Blaxel	2824ms create / 1924ms resume (measured)	microVM	Perpetual hibernation, snapshot	Async Python, TS	Memory-tier per-sec, zero idle	No	Managed
Vercel	1852ms create / 3333ms resume (measured)	Firecracker microVM	Persistent by default, snapshot	TS-first, Python	Active CPU, memory full wall-clock	No	Managed (iad1)
Northflank	~sub-sec (vendor)	Kata microVM + gVisor, per workload	Configurable, snapshot	REST/SDK	Per-sec, lowest published PaaS rate; BYOC	Yes	Managed, BYOC, self-host
Fly Sprites	~300ms checkpoint (vendor)	Firecracker microVM	Persistent-first, checkpoint	TS/SDK	Per-sec, nothing when idle	Limited	Managed
Cloudflare	Isolate in ms (vendor) / container start	Sandbox SDK = container; Worker Loader = V8 isolate	Container persistence; isolate ephemeral	TS-first	Active CPU + Workers/DO + $5/mo	No	Managed (edge)
Runloop	~25ms resume (vendor)	Dual-layer microVM + container	Snapshot, suspend/resume, zero idle	Python/TS	$0.108/CPU-hr + $0.0252/GB-hr, $250/mo Pro	No	Managed, VPC
CodeSandbox SDK	1-3s VM clone (vendor)	Firecracker microVM	Memory snapshot, live VM cloning	TS-only	Usage tiers, $170/mo Scale	No	Managed
AWS Lambda MicroVMs	Near-instant snapshot resume (vendor)	Firecracker microVM	Snapshot, suspend/resume ≤8h	AWS API/SDK	Per-sec vCPU+RAM, ceases when suspended	No (ARM64)	Managed (AWS, 5 regions)
Google Agent Sandbox	Sub-second create (vendor)	gVisor (GKE-native)	Stateful TTL ≤14 days	GKE/SDK	GKE-based; billing from July 1, 2026	Via GKE	Managed (GKE), self-host
OpenSandbox	Backend-dependent	Pluggable: gVisor / Kata / Firecracker	Backend-dependent	Python/TS/Go/Java	Self-host, no platform fee	Backend-dependent	Self-host (Docker/K8s)
Microsandbox	Sub-200ms (vendor)	libkrun microVM	Persistent or ephemeral	Python/TS, MCP	Self-host, no platform fee	No	Self-host, local
AIO Sandbox	Container start	Docker, pluggable secure runtime	Container persistence	Multi-language, MCP	Self-host, no platform fee	No	Self-host (Docker)

The following sections look at each dimension in turn. This article focuses on code-execution sandboxes: the environments where an agent runs code, shell commands, and package installs behind an API.

Cold start

Cold start is really two measurements that vendors often blur together: create-from-scratch and resume-from-standby. Create-from-scratch provisions a fresh sandbox. Resume-from-standby brings back a paused one. Those numbers can diverge, sometimes in opposite directions across platforms.

The isolation primitive sets the floor. A microVM boots a real guest kernel, which usually costs more than a container that shares the host kernel. A container usually costs more than a V8 isolate inside an already running process. No amount of tuning can move a platform below what its primitive allows.

We measured directly rather than relying on published figures. The harness created a sandbox, ran a command, confirmed that the command executed inside the sandbox, paused the sandbox, then timed the resume to the first command. “Ready” means the command actually executed, not that the API acknowledged the request.

E2B was the fastest and most consistent in this benchmark, at 717ms to create and 662ms to resume. Daytona created almost as quickly, at 742ms, but resumed more slowly at 1254ms because its stop-then-start flow rebuilds more than a memory-preserving pause. Vercel created in 1852ms but resumed in 3333ms, making it the one platform where resume took longer than fresh create despite its persistence-by-default model. Modal and Blaxel had the slowest create times, at 2437ms and 2824ms respectively, though both recovered somewhat on resume.

There is an important caveat: resume does not mean the same operation everywhere. E2B and Daytona pause and resume in place. Vercel resumes its persistent sandbox. Blaxel performs a real standby-to-active wake, which we forced past its auto-standby window before timing. Modal has no in-place resume, so its 2347ms figure is snapshot-boot time, not pause/resume time.

Cold start should drive your decision when the agent creates or resumes environments frequently and a human is waiting on the result. Examples include a coding assistant that spins up an environment per interaction or an eval pipeline that runs thousands of short-lived sandboxes. In those workloads, E2B’s 717ms create time versus Blaxel’s 2824ms create time compounds across every invocation.

Isolation model

Isolation determines your security ceiling. These platforms occupy four tiers, based on where the boundary sits relative to the host kernel. Configuration can harden a platform, but it cannot fully move the platform out of its underlying tier.

• Hardware microVM: Each sandbox gets its own guest kernel behind a virtualization boundary, with Firecracker (E2B, Vercel) and libkrun (Microsandbox) as common implementations. A kernel exploit inside the sandbox should not reach the host, which makes this the strongest boundary in the category.
• gVisor: gVisor sits one tier down. Its user-space kernel, called the Sentry, intercepts syscalls and re-implements them in user space so the application does not call the host kernel directly. The attack surface shrinks to the Sentry itself. Modal uses gVisor, and Northflank offers it alongside microVM isolation.
• Shared-kernel container: Namespaces and cgroups separate workloads, but every sandbox shares the host kernel. A kernel exploit can break the boundary. Daytona runs Docker by default, with stronger options available through configuration. This is reasonable for trusted code but riskier for untrusted model output or user-submitted code. An agent that reaches a mounted Docker socket can often escape most container isolation.
• V8 isolate: Cloudflare’s Worker Loader runs code in an isolate inside a running process. It starts in milliseconds, but it isolates only at the process level, which leaves a larger attack surface than a hardware VM. Cloudflare’s container-based Sandbox SDK is a separate and stronger product.

The BeyondTrust research on AWS AgentCore shows why the tier label is not the whole story. AgentCore runs on Firecracker, and the compute isolation itself was not broken. The failure was one layer above that. AgentCore’s “Sandbox” mode promised no external access but still permitted outbound DNS A and AAAA queries. Researchers built a command-and-control channel over DNS and used the interpreter’s over-broad IAM role to read S3 buckets with PII and credentials. AWS first called this intended functionality, then remediated DNS tunneling on April 15, 2026.

Isolation is a stack, not a checkbox. The microVM-versus-container question sets the floor, but it is not the whole answer. Above the compute boundary, you still need to know what the sandbox permits by default on the network, whether it filters DNS, what its metadata service exposes, and how far its own credentials reach. When running untrusted model output, securing your full-stack projects from NPM attacks is one more layer that belongs in the same threat model.

Isolation should drive your decision when the code is untrusted, generated from user input, or submitted directly by users. Default to a microVM tier and treat anything weaker as deliberate risk acceptance.

Session persistence

Persistence determines whether a stateful agent can continue real work or has to rebuild its world on every invocation. There are four main persistence models:

• Ephemeral: The sandbox exists for one execution and is then discarded. This is a poor fit for an agent that clones a repo, installs dependencies, and then works across 20 tool calls.
• Pause/resume: The full state is preserved, including memory and filesystem, and the same instance comes back later. E2B does this through beta_pause() and reconnects to the same sandbox ID.
• Snapshot/fork: State is captured as a reusable artifact that can boot new sandboxes. Because one snapshot can seed many sandboxes, an agent can fork a prepared environment into parallel branches. Modal, Daytona, and Vercel expose this model.
• Perpetual hibernation: The sandbox stays alive indefinitely but bills nothing while it sleeps. Blaxel and Sprites build around this model, which means no teardown, no rebuild, and near-zero idle cost.

Persistence and idle billing are two sides of the same decision. If a sandbox holds state between invocations, it has to exist between invocations, and someone pays for that time. The persistence model is therefore also a cost model, which the pricing section covers later.

Our benchmark measured the resume side. E2B resumed in 662ms, Blaxel woke from standby in 1924ms, Vercel resumed in 3333ms, and Modal’s snapshot boot took 2347ms. These are the delays a stateful agent pays every time it comes back.

Here is pause/resume in practice using E2B. The sandbox preserves full state across a gap where the sandbox costs nothing:

from e2b import Sandbox

# First invocation: set up expensive state, then pause.
sbx = Sandbox.create()
sbx.commands.run("git clone https://github.com/example/repo /work")
sbx.commands.run("cd /work && pip install -r requirements.txt")
sbx.commands.run("echo 'analysis_step_1_complete' > /work/state.txt")

sandbox_id = sbx.sandbox_id
sbx.beta_pause()   # memory + filesystem frozen, billing stops

# ...minutes or hours later, a separate process, a later agent turn...

# Second invocation: reconnect to the same sandbox, state intact.
resumed = Sandbox.connect(sandbox_id)
result = resumed.commands.run("cat /work/state.txt")
print(result.stdout)          # -> analysis_step_1_complete
# repo is still cloned, deps are still installed, no rebuild
resumed.kill()

The clone and install do not run again because the agent picks up where it stopped. That is the value of persistence.

Snapshot/fork solves a different problem: capture state once, then spawn many copies. Modal’s snapshot_filesystem() returns an image, and every sandbox booted from it starts from the same prepared state:

import modal

app = modal.App.lookup("agent-work", create_if_missing=True)
base = modal.Image.from_registry("python:3.13-slim")

# Prepare an environment once.
sb = modal.Sandbox.create(app=app, image=base)
sb.exec("bash", "-c", "pip install pandas numpy scikit-learn")
prepared = sb.snapshot_filesystem()   # reusable image
sb.terminate()

# Fork three parallel sandboxes from the same prepared state.
branches = [
    modal.Sandbox.create(app=app, image=prepared)
    for _ in range(3)
]

for i, branch in enumerate(branches):
    branch.exec("bash", "-c", f"echo 'running trajectory {i}'")

# Each branch explores a different approach from the same starting point.
for branch in branches:
    branch.terminate()

Pause/resume answers “can my agent continue?” Snapshot/fork answers “can my agent branch?” A long-running session wants the first. An eval harness running many trajectories from a fixed baseline wants the second.

Persistence should drive your decision when work spans invocations and losing state means redoing expensive setup. It matters less for stateless, single-shot execution, where an ephemeral sandbox is simpler and cheaper.

SDK ergonomics

SDK ergonomics determine how much infrastructure thinking leaks into your application code. The five platforms we tested fall into three broad shapes.

The first shape is create-run-teardown with almost no ceremony. E2B and Daytona both give you a sandbox from a single call, let you run a command, and then let you tear it down:

# E2B
from e2b import Sandbox

sbx = Sandbox.create()
result = sbx.commands.run("echo hello")
print(result.stdout)
sbx.kill()

# Daytona
from daytona import Daytona, DaytonaConfig

daytona = Daytona(DaytonaConfig(api_key="..."))
sandbox = daytona.create()
result = sandbox.process.exec("echo hello")
print(result.result)
daytona.delete(sandbox)

They are nearly identical in shape, except for naming friction: E2B returns .stdout, while Daytona returns .result through a .process namespace.

The second shape requires more setup. Modal needs an App and Image first because sandboxes are one primitive inside a broader serverless platform:

# Modal
import modal

app = modal.App.lookup("my-app", create_if_missing=True)
image = modal.Image.from_registry("python:3.13-slim")

sb = modal.Sandbox.create(app=app, image=image)
p = sb.exec("bash", "-c", "echo hello")
print(p.stdout.read())
sb.terminate()

That preamble is what lets Modal attach GPUs, define images in code, and scale to thousands of jobs. It is worth it if you need those capabilities, but it is extra friction if you only need a sandbox.

The third shape is Cloudflare, which does not run as a standalone script. Its Sandbox SDK lives inside a Worker and requires a Dockerfile, a wrangler.jsonc binding, and local Docker for development:

// Cloudflare — inside a Worker, not a standalone script
import { getSandbox } from "@cloudflare/sandbox";
export { Sandbox } from "@cloudflare/sandbox";

export default {
  async fetch(request: Request, env: Env) {
    const sandbox = getSandbox(env.Sandbox, "my-sandbox");
    const result = await sandbox.exec("echo hello");
    return new Response(result.stdout);
  },
};

You are not calling a sandbox API here. You are deploying a Worker that contains one. That feels natural for a team already on Workers, but it is a platform commitment for everyone else.

Vercel sits between these models. You get a single Sandbox.create() call like E2B, but off-platform it requires three auth values: the team ID, the project ID, and a token. If you’re already building on Vercel’s ecosystem, understanding Vercel Eve for AI agents gives useful context on how the platform handles agentic workloads more broadly.

Language support also matters. E2B, Daytona, and Modal are Python-first with TypeScript support alongside. Cloudflare and Vercel are TypeScript-first. Blaxel ships both, but its Python SDK is async-only, so every call is an await. Match the SDK’s primary language to your stack or you may inherit the second-class surface.

There are also abstraction layers. ComputeSDK exposes one TypeScript API over nine providers, and VibeKit does the same for coding agents across E2B, Daytona, Modal, and Fly. Abstraction makes sense when avoiding lock-in matters. It is less useful when you need a platform’s distinctive features because the layer usually exposes the common denominator. Teams building with MCP-compatible sandboxes may also find value in reviewing the top MCP servers for AI projects when deciding how their agent’s tools connect to execution environments.

SDK ergonomics should drive your decision when the team is moving fast or may switch providers. It matters less once you have already committed to a platform for isolation, persistence, GPU, or pricing reasons.

Pricing model

Pricing determines whether a prototype survives production volume. The trap is comparing per-hour rates because the rate rarely determines the bill. The billing model does.

Four questions matter:

• Do you pay per second of wall-clock time or only for active CPU?
• Is idle time charged?
• Is there a subscription floor?
• How is memory billed relative to compute?

The active-CPU question separates these platforms most clearly. E2B and Daytona charge CPU and memory for the full duration a sandbox is alive, at $0.0504/vCPU-hr and $0.0162/GiB-hr, billed per second (rates from vendor pages and independent comparisons, April to June 2026). Vercel bills CPU at $0.128/vCPU-hr for active time only, with memory at $0.0212/GB-hr for the full wall-clock. Modal drops compute charges to zero when idle. Blaxel charges nothing for compute in standby and prices by memory tier, with its 4GB tier at $0.1656/hr. Fly Sprites also charges nothing while idle. Cloudflare bills active CPU at $0.072/vCPU-hr, on top of Workers requests, Durable Objects, and a $5/month base.

These differences invert the ranking by workload shape.

Consider a bursty interactive agent running 30,000 sessions a month. Each sandbox stays alive for about five minutes, uses CPU for only 30 seconds, and carries no state between sessions. At 2 vCPU and 4GB, Modal lands near $36 because it charges for almost no idle CPU. Vercel follows at around $276 because active-CPU billing skips the waiting. E2B, Daytona, and Blaxel all cluster near $414 because full-duration billing charges for every second of that wait. In this scenario, active-CPU platforms win by an order of magnitude.

A long-running stateful agent reorders the comparison. Picture 50 agents each holding one persistent sandbox, active for two hours a day and idle for the other 22, with state retained for instant resume. Modal looks cheapest at around $426, but only because the model counts active compute and not the cost of rebuilding state on every wake. E2B, Daytona, and Blaxel land near $533 for active compute plus near-zero idle storage while genuinely preserving state. Vercel becomes the most expensive at roughly $3,800 because keeping a sandbox resident for instant resume means its memory bills across all 24 hours. The platform that wins the first scenario loses the second on the same memory-billing rule.

Pricing should drive your decision when the agent runs at volume and you know the workload shape. It matters less for prototypes and low-volume internal tools where free tiers or small bills absorb the load. Product managers evaluating sandbox costs at scale may find it useful to apply a technical debt register to track the long-term cost implications of platform lock-in decisions.

Conclusion

There is no universal best sandbox platform. There is only the best sandbox for your binding constraint. Cold start decides interactive agents. Isolation decides untrusted code. Persistence decides stateful work. The billing model decides cost at scale, and it can flip the ranking by workload shape.

Start by finding the dimension where a wrong choice would break the agent or the budget. Let that dimension create the shortlist, then filter on the rest.

Trust your own numbers over marketing copy. Our measured cold starts ran above vendor claims because vendors often measure warm, in-region paths while real agents pay for setup, distance, and the round trip. Pricing inverted by workload. AgentCore showed that strong compute isolation is not enough if the network layer leaks. Model your workload against the billing structure, verify the isolation boundary that matters for your threat model, and your decision framework will outlast any one platform. For teams building agentic systems more broadly, context rot in AI agents is a related performance problem worth addressing alongside sandbox selection. If you’re evaluating how human-in-the-loop AI fits into your agentic architecture, the ownership and oversight model you choose will also shape which sandbox features matter most.