Pricing
- Price / hour (/hr)
- $0.031 /hr
- Meter
- per-second
- Idle cost
- free-when-stopped
Hourly compute is the number everyone compares and rarely the number that dominates the bill.
Price is one group of 3 fields out of 26. Everything else — features, limits, portability, how well any of it works for agents — is on the full sandbox providers compared: cold start, isolation and price comparison.
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.
If the code comes from your own model and your own prompt, a hardened container is usually fine. If it comes from a user, assume a container escape is a matter of time and budget: shared-kernel isolation has a steady drip of CVEs. A microVM (Firecracker, Cloud Hypervisor) or gVisor gives you a syscall boundary a kernel bug in the guest cannot cross. Check what you are actually buying rather than what the homepage implies — Daytona, the quickest-booting agent-native provider here, runs Docker containers on a shared kernel by default, and several vendors describe a container as having a "dedicated kernel" when they mean a dedicated namespace. The price difference is now small enough that the container answer is rarely worth defending.
Yes, and for a handful of pages a day it is cheaper. Chromium in a sandbox with a CDP endpoint costs compute you are already paying for. What you do not get is residential egress, CAPTCHA handling and the fingerprint work dedicated providers do, so scraping targets with real bot defences will fail. Use the sandbox for your own apps and internal tooling; use a browser API when the site is fighting back.
It depends on the meter, and this is where bills go wrong. Fly charges nothing for a stopped machine beyond storage; E2B and CodeSandbox bill storage on a paused sandbox; Vercel bills active CPU, so a sandbox blocked on the network costs very little. Providers billing wall-clock per second charge you for every token the model is still generating. On agent workloads that idle time is usually the majority of the session.