Every sandbox vendor leads with a cold-start number, and every one of those numbers describes creating one sandbox at a time — which is not a thing an agent fleet ever does. The only published measurements of concurrent creates spread the same class of platform across 0.67 s to 5.06 s, an order of magnitude away from the marketing figure, and two of the four platforms here have no public burst number at all. The second thing nobody prices: a coding agent's sandbox spends most of its wall-clock waiting for a model to answer, so whether the meter runs during that wait is worth more than any milliseconds argument. Pick on burst and idle. The isolation table is the easy part, and by June 2026 the exit door had narrowed to two of the four.
At a glance
Four platforms an agent can run untrusted code on, and they are not four versions of the same product — one is a sandbox company, one is a compute platform with a sandbox API, one is a general application platform, and one changed its licence this year.
| Platform | Isolation boundary | Meter while idle | Self-host or exit |
|---|---|---|---|
| E2B | Firecracker microVM, dedicated kernel per sandbox | Runs — alive means billable | Open source; self-host supported |
| Daytona | Containers by default; Kata or Sysbox on request | Runs — per second, no monthly floor | Production codebase closed since June 2026 |
| Modal | gVisor | Drops to zero when nothing executes | Managed only |
| Northflank | Kata Containers, Firecracker, gVisor | Runs; no forced session ceiling | Self-serve BYOC into your own cloud account |
One caveat that shapes everything below: a large share of the public comparison writing in this category is published by Northflank, on Northflank's blog, comparing Northflank to its competitors. The numbers are specific and checkable and I have used them, but a vendor's own comparison is a source with a direction, and the same applies to every "sub-90 ms" claim on every landing page here. Where a figure was measured by a third party I say so; where it is a vendor claim I say that too, because on the axis that matters most those two categories disagree by roughly 10×.
The cold-start number is measured on the wrong workload
Daytona's marketing quotes sub-90 ms cold starts and reports 27 ms for optimised configurations; E2B is generally cited around 150 ms for its default template. Both are real measurements of a real operation: create a sandbox, wait, create the next one. Now look at what happens when the creates arrive together, which is the only shape an agent platform produces — a queue drains, a batch of runs starts, fifty sandboxes are requested inside a second. The third-party burst figures published in August 2026 put Vercel at a 0.67 s median with a 1.12 s p99, Modal at 0.88 s, E2B at 1.61 s and Cloudflare at 5.06 s. That is a 7× spread between providers and roughly a 10× gap between E2B's own sequential figure and its measured burst figure.
Neither number is dishonest. They measure different things, and the sequential one is the easier thing to measure, which is why it is the one that gets published. The consequence for a buyer is concrete: a shortlist built by sorting the sequential column can invert entirely under load, and the two platforms in this comparison with the strongest cold-start marketing — Daytona — and the strongest isolation stack — Northflank — do not appear in any published burst measurement I could find. That is not evidence they are slow. It is evidence you will have to run the experiment yourself, on your own concurrency, before the number means anything.
Two further traps in the same column. Modal has no in-place resume, so a "resume" figure quoted for it is snapshot-boot time and not comparable to a platform that resumes a paused sandbox in place. And a cold-start median is close to useless for an interactive agent: the user experiences the p99, because a single agent turn may create several sandboxes and waits for the slowest. Measure at p99 under your real concurrency or do not measure at all — the same discipline the load-testing page argues for on the agent itself.
The meter runs while the model thinks
Time an agent turn. The sandbox is created, then it sits there while the model reads the previous tool result and generates the next call, then a command runs for a fraction of a second, then it sits there again. On a coding agent the executing fraction is routinely single-digit percent of the sandbox's lifetime; the rest is waiting on inference, and increasingly on a reasoning model that spends seconds thinking before it emits anything. E2B's own documentation is candid about what that means on its meter: the clock does not distinguish active execution from idle, so if the sandbox exists you are paying for it. Daytona and Northflank bill the same alive-time shape. Modal is the outlier — compute charges drop to zero when nothing is executing — which turns a long-lived sandbox waiting on a model from the dominant line item into approximately nothing.
This is not a verdict for Modal, because the rates differ and the floors differ. E2B's Pro tier is $150/month including 500 hours with per-second overage beyond it, which is a fixed cost you carry whether or not you use it and a reason low-volume users overpay. Daytona has no monthly floor and starts against free credit, which favours intermittent workloads. Northflank publishes $0.01667/vCPU-hour and $0.00833/GB-hour and is the only one of the four offering self-serve bring-your-own-cloud, where the sandboxes bill against your own cloud account instead — its own figures put 200 sandboxes at $2,060 on BYOC against $7,200 on its managed platform, which is a vendor's number about a vendor's product and still the right shape of the argument.
So the calculation to run before you shortlist anything: instrument one week of real agent runs and record two numbers — sandbox alive-seconds, and sandbox executing-seconds. If the ratio is above roughly 5:1, alive-time billing is charging you mostly for waiting and execution-time billing wins on price before any rate comparison starts. If it is close to 1:1 you are running batch compute rather than an interactive agent, and the rates decide it. Nobody can do this arithmetic for you from a pricing page, which is precisely why the pricing pages are laid out the way they are. The general version of this trap is in forecasting agent spend: the mean tells you nothing, and the shape of the bill is set by what happens between the interesting moments.
The isolation column is real, and it is not the hard decision
Agent-written code is untrusted code — not because the model is malicious, but because its inputs are attacker-influenced, which is the argument sandboxing and code execution makes at length. So the boundary matters. It is also the axis where the four are easiest to rank and where ranking them changes the least.
E2B runs Firecracker microVMs with a dedicated kernel per sandbox, which is the strongest boundary in the group and the one that survives a container-escape class of bug. Northflank offers microVMs through Kata Containers and Firecracker alongside gVisor, and reports processing over two million isolated workloads monthly across them. Modal uses gVisor, a syscall-interception boundary that is materially stronger than a plain container and materially weaker than a separate kernel. Daytona runs containers by default with Kata or Sysbox available as configuration — the weakest default here, and the one most likely to be deployed as-is by a team that read the cold-start number and stopped.
Why this ranks lower than it looks: the isolation boundary constrains the blast radius of a code-execution escape, and code-execution escapes are not the common failure. The common failure is that the sandbox does exactly what it was asked to do and reaches something it should not have — an internal metadata endpoint, an unfiltered outbound connection, a credential mounted into the environment for convenience. That is a network and capability question, not a kernel question, and every platform here leaves most of it to you. If you have not decided your egress policy, upgrading from gVisor to Firecracker buys you very little; see egress control for agents and the isolation patterns in sandbox and isolation patterns.
One capability genuinely does foreclose a choice, in the opposite direction from isolation: Modal is the only platform of the four where a sandbox can hold a GPU — H100, H200, A100, B200, L4, T4 — billed per second alongside CPU and memory. If your agent needs to run inference, fine-tune, or process images inside the same isolated process that runs its tool calls, that is a hard requirement and it selects Modal on its own. The workaround elsewhere is calling an external inference API from inside the sandbox, which adds a network hop and a second bill.
In June 2026 the exit narrowed
Daytona moved its production codebase to closed source in June 2026, citing the risk that AI-assisted vulnerability discovery makes an open sandbox repository a liability. The original repository stays public and usable but receives no further updates, fixes or releases, and fully self-hosting the platform is no longer possible. Whatever you make of the reasoning — and it is a more interesting argument than most licence changes get credit for — the practical effect is that the option of running it yourself if the vendor's pricing, availability or roadmap disappoints you has been removed.
That leaves two exits among these four. E2B is open source and self-hostable, which is now unusual in this category. Northflank's is different in kind: not open source, but self-serve BYOC across AWS, GCP, Azure, Oracle, Civo, CoreWeave, on-premises and bare metal, so the workloads run in infrastructure you already control and the bill lands on your own cloud account. Modal is managed only, and is upfront about it.
Sandboxes are worth treating as a switching-cost decision rather than a feature decision, because they sit underneath everything: the agent's filesystem contract, its process model, its network shape and its failure semantics are all expressed against one provider's SDK. Migrating is not a config change. If your organisation has a policy about vendor exit — and after the year the agent-infrastructure category has had, it should — the licence and deployment column is the first filter, not the last.
When to pick which
| Situation | Pick | Because |
|---|---|---|
| Agent needs a GPU inside the sandbox | Modal | The only one of the four where a sandbox can hold one; everything else here requires an external inference call and a second bill |
| Long-lived sandboxes, mostly waiting on a model | Modal | Compute charges drop to zero when nothing executes, which is most of the lifetime of a coding agent's sandbox |
| Untrusted third-party code, isolation is the requirement | E2B | Firecracker microVM with a dedicated kernel per sandbox, and open source so the boundary is inspectable rather than asserted |
| Compliance or data-residency constraint, or a real exit policy | Northflank | Self-serve BYOC into your own cloud account across eight targets, with microVM isolation available; the workloads never leave infrastructure you control |
| Intermittent, low-volume, cost-sensitive | Daytona | No monthly floor and per-second billing from free credit — accepting containers as the default boundary and no self-host path since June 2026 |
| High burst concurrency in the critical path of a turn | Measure first | Every published sequential figure is measuring a workload you do not run, and two of these four have no public burst number at all |
What should not decide it: the cold-start figure on the landing page, and which platform a comparison blog ranked first when that blog belongs to one of the platforms. What should: your own alive-to-executing ratio, your own p99 create latency at your own concurrency, and whether you could leave.
FAQ
Why does a burst cold start differ so much from a sequential one?
Creating one sandbox at a time lets a provider serve it from a warm pool and lets every shared component — the scheduler, the image cache, the network attachment — operate uncontended. Creating fifty at once exhausts the pool and queues on those shared components, so you are measuring the platform's capacity rather than its create path. Agent workloads produce the second shape almost exclusively, because runs are dispatched in batches and a single turn may need several sandboxes at once.
Is a microVM really necessary, or is gVisor enough?
For code that your own agent generated against your own repository, gVisor is a reasonable boundary and the practical risks are elsewhere — egress, mounted credentials, and what the sandbox is allowed to reach on your network. A dedicated kernel per sandbox earns its cost when the code originates outside your trust boundary: a customer's snippet, a package installed at runtime, anything an attacker can influence directly rather than through your prompt. Decide by where the code comes from, not by which sounds stronger.
Can I avoid the idle-billing problem by tearing sandboxes down between tool calls?
Partly, and it costs you the thing you were optimising. Destroying the sandbox after every command means paying a full create on every subsequent call, which puts the burst cold start back in the critical path of every turn and loses any filesystem state the agent built up. Pausing and resuming is the middle path where a platform supports it in place. The honest framing is that alive-time billing and create latency trade against each other, and picking a platform whose meter stops is a way of not having to make the trade.
Does open source matter here if I am going to use the hosted product anyway?
It matters for two things that are not "I will self-host". First, the isolation boundary is a security claim you can read rather than one you have to accept, which is a different quality of assurance from a compliance page. Second, it is the credible exit that disciplines the relationship — the reason a licence change is news even for customers who were never going to run the code themselves.
How do I actually measure my alive-to-executing ratio?
Stamp two timestamps per sandbox in whatever already records your runs: creation and destruction for alive-seconds, and the sum of command start-to-exit intervals for executing-seconds. Aggregate over a week of real traffic, not a benchmark. If your tracing already carries a span per tool call — which is what agent observability is for — you have the second number already and only need the sandbox lifetime attached to the same trace.
Further reading
On this wiki:
- Sandboxing & code execution — the five independent isolation decisions, of which the kernel boundary is only one.
- Sandboxing & safe execution — designing for blast radius when the code is attacker-influenced.
- Sandbox & isolation patterns — the pattern catalogue underneath these products.
- Egress control for agents — the failure that isolation strength does not address.
- Concurrency & scaling — why agent workloads arrive in bursts in the first place.
- Forecasting agent spend — the heavy tail these meters run into.
Project sources:
- E2B — open source, Firecracker microVMs.
- Daytona — and the June 2026 note on going closed source.
- Modal — sandboxes with GPU access and execution-time billing.
- Northflank — microVM sandboxes with self-serve BYOC.