Articles · November 12, 2026
How long until a fresh sandbox runs your first command?
Cold create to first successful command across five agent sandbox providers, plus the six I could not measure and why.
When an agent needs a sandbox, the first thing it does is ask for one and run something in it. So the first number I care about is simple: how long from “give me a new sandbox” until a shell command actually comes back?
I measured that for every agent sandbox provider I could get working. Five made it to a number. Six did not, and the reasons are part of the result.
The numbers
p50 over five fresh sandboxes each, default image, measured from one laptop over the public Internet:
| Provider | p50 | min | max |
|---|---|---|---|
| Cloudflare Sandbox | 483 ms | 467 ms | 888 ms |
| Freestyle | 976 ms | 897 ms | 1572 ms |
| Tensorlake | 1919 ms | 1895 ms | 2490 ms |
| BoxLite Cloud | 4067 ms | 3752 ms | 4428 ms |
| Upstash Box | 5019 ms | 2756 ms | 11667 ms |
The live chart, every replicate and the raw JSON are on the leaderboard page.
How it is measured
The clock starts right before the SDK’s create call. Then I run echo ok until it exits 0, retrying every 250 ms. That moment is the headline. After that, uname -a runs once to prove it is a real Linux guest, and the sandbox is destroyed, even if something failed.
The metric definitions come from StarSling’s open source sandbox benchmark (MIT). Their big public run compared providers on real CI pipelines and did not publish this create-to-ready number, so this fills that gap with a much smaller harness. It is not their code and not an official StarSling result.
Things that surprised me
SDKs disagree about what “created” means. Tensorlake, BoxLite and Upstash wait inside create until the sandbox is running. Cloudflare’s start() returns before the container is ready and the first exec waits for it. That is why only the end-to-end number is fair. The split between “create returned” and “first command ran” mostly tells you about the SDK.
Spread matters as much as the median. BoxLite was the steadiest of the slower group, every run between 3.8 and 4.4 seconds. Upstash ranged from 2.8 to 11.7 seconds across five runs. Part of that is mechanical: its SDK checks readiness every 2 seconds, so results land in 2 second steps.
Cloudflare is fast but has a catch. You can only drive a Cloudflare sandbox from inside a Worker. My number goes laptop to Worker to container, so it includes that extra hop and still came out first. If your agent already lives in a Worker, you skip the hop.
One SDK did not run on Bun. Tensorlake’s TypeScript SDK creates the sandbox and then throws DataCloneError under Bun, leaving the sandbox running. Their REST API worked fine, so the harness uses that.
The six I could not measure
A skipped provider is not a slow provider, so these are not ranked:
- E2B: a new workspace is blocked until a $5 card verification payment.
- Runloop: signup is invite only right now.
- boat: the API key works, but creating a sandbox needs a started plan with a card on file.
- Novita: the account had no balance yet. Their docs say the free credit unlocks after an onboarding survey.
- Celesto: my key was read-only. Creating sandboxes needs a key with the run-commands permission.
- Daytona: adapter is written, no key yet.
I will add each one as soon as it runs, with the same method.
What this does not tell you
This is one client location and five runs per provider. It ranks wide gaps, not close ones. Default machine sizes differ by vendor. And it says nothing about disk, CPU or how fast your actual build runs once the sandbox is up. For that, read StarSling’s pipeline results.
If you run a sandbox company and think I set something up wrong, DM me on X. I would rather fix the number than defend it.