Sandbox providers

Nobody buys a sandbox. They buy the two seconds between an agent deciding to run code and the code running, and they buy the confidence that a hostile rm -rf or a crypto miner stays inside the box. Everything else on this page is a proxy for those two things.

On speed, the honest ranking is: V8 isolates and WASM (Val Town, Riza) start in milliseconds because they barely start anything; microVM providers with memory snapshots (E2B, Blaxel, CodeSandbox SDK, Runloop) land somewhere between 150 ms and two seconds depending on how warm their pool is when you call; container platforms scheduled on Kubernetes (Northflank) and full VMs (GitHub Codespaces) are seconds to tens of seconds. Daytona sits outside that grouping and it matters: its sandboxes are Docker/OCI containers on a shared host kernel, which is precisely why it can claim a create in under 90 ms — there is no guest kernel to boot. Blaxel's 25 ms and Daytona's sub-90 ms are real numbers for real operations, restoring a snapshot or starting a container on a machine that is already yours. They are not the number you get from your laptop, over TLS, into a pool that has just scaled to zero. That gap is what the killer column on this page exists to expose.

For agent harnesses specifically, E2B remains the default and deserves it: Apache-licensed, Firecracker underneath, a template system that is just a Dockerfile, and the only ecosystem where you can rip the vendor out and self-host without rewriting your integration. Daytona is the sharpest competitor on ergonomics and boot time, and the weakest on the one axis this page treats as non-negotiable — a shared kernel is a different security posture from a hypervisor, whatever the marketing says about a "dedicated kernel". It closed its source in June 2026, too, which removes the exit hatch that makes E2B's licence worth paying attention to. Runloop is the one to look at if you are running evals rather than a product — devbox snapshots plus a benchmark harness is a genuinely different shape of product. Blaxel and Freestyle are betting the whole company on boot time, which is a fine bet and a thin moat.

If you already have infrastructure, the calculus inverts. Fly.io Machines is not marketed at agent builders and has no SDK worth the name, but it gives you a real Firecracker VM with a durable volume, a public IPv4, a Sydney region, per-second billing and nothing charged while stopped — for roughly a tenth of what the agent-native vendors charge for equivalent compute. A weekend of glue code buys a lot. Vercel Sandbox and Cloudflare Sandbox are the same argument at the platform level: they exist so the sandbox is a line in the app you already deployed, not a second vendor, a second bill and a second on-call rotation. Neither is fastest or cheapest, and neither is trying to be.

Where this goes next is consolidation on two axes. Snapshot-and-fork is becoming table stakes, which kills the cold-start pitch as a standalone product — if everyone restores a paused VM in 200 ms, the differentiator moves to what the VM can reach on the network. Expect egress control, per-sandbox audit logs and outbound proxies to become the thing vendors argue about by 2027, because that is the feature enterprise buyers block deals on. The providers with a real answer there today — Fly, Northflank, Cloudflare, and anyone self-hosting Firecracker — are better positioned than their boot times suggest.

There are at least five distinct events a vendor might be timing, and the marketing word for all of them is "cold start".

The first is snapshot restore: a memory image of a booted VM mapped back in on a host that already has the pages. This is where the sub-100 ms numbers come from, and it is genuinely fast — but it presumes hardware allocated, image cached and pool warm. The second is guest boot: Firecracker to userspace, historically about 125 ms, which is where the whole microVM category gets its reputation. The third is scheduling: finding a host with capacity, which is zero when the pool is warm and seconds when it is not. The fourth is image pull, zero for a cached base image and thirty seconds for your 4 GB CUDA layer. The fifth is the API round trip and TLS handshake, 20 ms from the same region and 300 ms from Sydney.

Vendors quote the smallest of these. Agents pay all five. That is why the measured column here starts from a client, on an account with nothing running, and stops when a trivial command has returned output — and why it reads slower than every homepage. Any provider whose measured p50 lands within 3× of its claim is doing well, and most of this roster clears that bar: E2B at 2.0×, Modal at 1.5×, CodeSandbox at 1.2×, Fly at 3.0×, Daytona at 3.9×. Exactly one provider is an order of magnitude out — Blaxel, whose 25 ms is a snapshot restore and whose estimated create-to-output is 20× that. The size of a vendor's gap is a better guide to how it defines the word than to how fast its infrastructure is.

Hourly compute is the number everyone compares and rarely the number that dominates the bill.

Watch the meter's units first. Per-second billing across 400 sandboxes that each live 12 seconds is a completely different bill from per-minute billing on the same workload, because per-minute rounds every one of them up. Cloudflare's 10 ms granularity and Vercel's active-CPU model are the friendliest shapes for bursty agent traffic; anything billing in minute blocks punishes exactly the pattern agents produce.

Then watch idle. An agent session is mostly the sandbox waiting for a model to finish generating. If the provider bills wall-clock, you are renting a CPU to wait on someone else's inference queue. Providers that bill only active CPU, or let you pause to storage-only rates, can be several times cheaper on identical work despite a higher headline rate — check the pause API's latency before relying on it, because pausing something you resume 400 ms later is a false economy.

Finally, the line items nobody puts on the pricing page: snapshot storage charged per GB-month and never garbage-collected, egress at cloud rates when your agent downloads a model, volumes that outlive the sandbox that created them, and platform minimums such as a paid Workers plan or a monthly SDK tier that make a "$0.05/hr" provider cost $150 before the first sandbox boots.

Start with the isolation requirement, because it is the only one that cannot be retrofitted. Untrusted third-party code means a kernel boundary — microVM or gVisor — and it means outbound network control, which immediately shortlists Fly, Northflank, Cloudflare, E2B and self-hosted Firecracker. Your own agent's code on your own data is a much lower bar and every provider here clears it.

Then decide whether you are buying infrastructure or buying a product. If the sandbox is your product's core loop, take the agent-native SDK and the snapshot semantics — E2B, Daytona, Runloop — and treat the per-hour premium as the price of not maintaining an orchestrator. If the sandbox is one feature inside something bigger, use whatever your platform already gives you and revisit when the bill or the boot time starts to hurt.

Then run one benchmark before you sign anything: your real image, from your real region, 50 cold creates, recording p95 rather than p50. p50 tells you how the vendor's pool behaves on a good day. p95 tells you what your users see when the pool is cold, and that is the number deciding whether your agent feels instant or broken. If a vendor will not let you run that test on a trial account, that is itself the answer.

Field values come from vendor documentation, pricing pages and public changelogs, each cell carrying its own provenance. Prices are the list rate for roughly 2 vCPU and 4 GB with no committed spend, normalised to an hourly figure. Several vendors bill per second or per credit and never publish an hourly number, so those cells are marked inferred with the arithmetic noted, or left null where a guess would be worse than saying nothing.

Cold start is the reason this page exists, so read the two columns together. Claimed cold start is whatever the vendor puts on its own homepage, and it is scored at weight zero on purpose — it is a marketing artefact, not a measurement. Vendors quote wildly different things under the same word: time to restore a memory snapshot on already-provisioned hardware, time for the guest kernel to boot, time for the API to return a sandbox ID, or p50 across a pool deliberately kept warm. Measured cold start is what toolweight publishes from its own harness: a single client in a fixed region, TLS handshake included, calling create-sandbox and blocking until a trivial command returns output — the full round trip an agent actually pays for. It runs against an account with no sandboxes alive, after a deliberate idle period, so nothing is pool-warm, and reports p50 and p95 over at least 50 runs so one good afternoon on a vendor's cluster cannot flatter the number. Until that harness has run against every provider here, cells in that column are estimates flagged as inferred, and no cell on this page currently carries measured confidence. We would rather show an honest estimate than launder a vendor's number into a benchmark.

Four rows come from a different kind of source and are flagged accordingly. The capability cells for box, ascii, exe.dev and Islo are transcribed from the comparison table box publishes on its own site, at box.ascii.dev/compare. That is the least neutral source on this page: a chart drawn by a vendor, with that vendor's two products in the first two columns and its competitors arranged around them. toolweight has verified none of it. Every field the table does not address — price per hour, cold start, isolation technology, persistence, regions, SDKs, funding, stars — is left null and unknown rather than filled in by inference.

Three rules keep that table from being laundered into evidence it is not. First, only a cell the table states directly is marked vendor-claimed; where a value had to be derived — reading root access off a "Docker inside the VM" row, or a preview-URL rating off two rows about IP addresses — the cell is marked inferred, because a sound derivation from a vendor's claim is still a derivation. Second, a marketing row is not a measurement: "runs 24/7" is not a published runtime ceiling and "1000+ concurrent VMs ergonomically" is not a published concurrency limit, so those cells are unknown rather than awarded this page's maximum. Third, and most important, absence from a row is scored asymmetrically on purpose. A vendor leaving its own product out of a row is a concession against interest and is credited — box and ascii are both absent from the process-fork and sub-500 ms rows, and that is recorded. A vendor leaving a rival out of a row is the weakest class of claim on this site, so it is recorded as nothing at all: exe.dev and Islo are missing from the snapshot rows, and their snapshot-and-fork cells stay unknown rather than becoming a scored zero on a competitor's say-so. These four rows stay in this shape until they can be re-sourced from each vendor's own documentation, at which point the provenance on every cell changes with them.