The sandbox isn't a commodity — it's architecture

Every agent that writes code needs somewhere to run it. The market already counts at least a dozen providers, four incompatible billing models, and marketing pages that quote cold-start numbers under conditions no one publishes. ComputeSDK's comparison normalizes the units and tests the five platforms most teams evaluate — E2B, Daytona, Modal Sandboxes, Cloudflare Sandbox SDK, and Vercel Sandbox — alongside Runloop, Fly.io Sprites, and Northflank when they change the answer.

Four questions actually decide

Feature matrices in this category are mostly noise. Four traits change the architecture; everything else is preference. Cold-start under concurrent load, because an agent loop that spins up a sandbox per tool call pays that tax thousands of times a day. Filesystem persistence between turns — does turn two see the pip install from turn one, or does the agent rebuild the world? Network egress policy — does the sandbox reach the internet, can you turn that off, can you change your mind mid-session? Idle-time billing — agents spend most wall-clock time waiting on the model, and someone pays for those seconds.

The numbers vendors don't tell you

Vendor claims aren't comparable. Daytona advertises sub-90-millisecond sandbox creation; E2B quotes around 150 milliseconds; Modal talks sub-second for pre-cached containers. None of them mention concurrency, region, image size, or whether the clock stops at API acknowledgment or first command executed. The most useful public dataset is ComputeSDK's leaderboard — open source, run on a schedule — measuring Time to Interactive: elapsed time from creation to first successful command inside the sandbox, 100 iterations per provider, launched concurrently in a single burst, from a 4 vCPU host in Northern Virginia.

Burst isn't steady state, and the tail is what you plan for

Three things in the table matter more than the ranking. Burst is not the same test as sequential: Daytona's fastest median is real, and in a previous run of the vendor page it created sandboxes at a median 0.10 seconds when launched one by one. In the August burst run it posted the fastest median in the field and completed 37 of 100 attempts. A median you only hit one-third of the time isn't a latency number — it's a capacity number. Retry logic isn't optional on any platform. Tail latency is the number you design to: Runloop's and Modal's medians sit 10 milliseconds apart, but Runloop's P95 is 3.3× Modal's. If your agent's UX budget is one second, the median tells you almost nothing.

Cloudflare measures a different product

Cloudflare Sandbox SDK sits on Cloudflare Containers, which schedules a container instance and initializes an image. That's architecturally heavier than resuming a pre-warmed Firecracker microVM, and 5-second medians reflect it. Cloudflare's own GA post is candid about the shape of the problem: sandbox boot, repo clone, and npm install take roughly 30 seconds, while restoring the same environment from a snapshot takes about two.

How to reproduce this yourself

The task worth measuring is the one your agent actually runs, not echo hello. A useful harness runs the same unit of work everywhere: install pandas, read a CSV, plot a chart, return a PNG. Measure four checkpoints separately — t_create to t_ready to t_deps to t_result — run 100 sequential iterations then 100 concurrent, report median, P95, P99. That's the only way to get numbers that match production, not a landing page.