Sandbox providers compared: cold start, isolation and price Pricing Compared

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

Last verified
2026-07-23 (today)
Source confidence
32%
Re-verified
every 30 days
Tools
20
Fields
3
20 tools · verified today
Fly.io MachinesRaw Firecracker microVMs with a REST API, durable volumes and 35+ regions.93.2

Pricing

Price / hour (/hr)
$0.031 /hr
Meter
per-second
Idle cost
free-when-stopped
Cloudflare SandboxContainer sandboxes driven from a Worker, addressed through Durable Objects.92.9

Pricing

Price / hour (/hr)
$0.18 /hr
Meter
per-10ms
Idle cost
free-when-stopped
RizaWASM-isolated code interpreter API for LLM output, with no filesystem or network.88.0

Pricing

Price / hour (/hr)
Meter
per-request
Idle cost
free-when-stopped
BlaxelAgent-first cloud claiming ~25 ms microVM boots from snapshots.79.2

Pricing

Price / hour (/hr)
Meter
per-second
Idle cost
storage-only
CodeSandbox SDKFirecracker VMs with memory snapshots, from the online IDE, now owned by Together AI.79.2

Pricing

Price / hour (/hr)
Meter
per-second
Idle cost
storage-only
FreestyleRun untrusted JavaScript and full dev servers, with git hosting and domains built in.79.2

Pricing

Price / hour (/hr)
Meter
per-request
Idle cost
storage-only
RunloopDevboxes, blueprints and eval harnesses aimed at teams training coding agents.79.2

Pricing

Price / hour (/hr)
Meter
per-second
Idle cost
storage-only
DaytonaSub-second container sandboxes for agent workloads, from a team that built a dev-env manager.78.6

Pricing

Price / hour (/hr)
$0.17 /hr
Meter
per-second
Idle cost
storage-only
E2BOpen-source Firecracker sandboxes with Python and TypeScript SDKs for AI agents.78.6

Pricing

Price / hour (/hr)
$0.17 /hr
Meter
per-second
Idle cost
storage-only
NamespaceFast microVM instances and CI runners with instant snapshots and cached builds.76.3

Pricing

Price / hour (/hr)
Meter
per-minute
Idle cost
free-when-stopped
ModalServerless Python compute with a Sandbox API bolted onto a GPU-first platform.75.8

Pricing

Price / hour (/hr)
$0.238 /hr
Meter
per-second
Idle cost
active-cpu-only
IsloPer-agent isolated cloud sandboxes with enterprise policy controls, from Incredibuild.72.5

Pricing

Price / hour (/hr)
Meter
Idle cost
Vercel SandboxFirecracker microVMs for running untrusted code from inside a Vercel deployment.71.5

Pricing

Price / hour (/hr)
$0.341 /hr
Meter
per-second
Idle cost
active-cpu-only
Val TownDeno isolates that run TypeScript on HTTP, cron and email triggers.70.4

Pricing

Price / hour (/hr)
Meter
subscription
Idle cost
free-when-stopped
GitHub CodespacesDevcontainer-backed cloud VMs built for humans, occasionally repurposed for agents.66.5

Pricing

Price / hour (/hr)
$0.18 /hr
Meter
per-minute
Idle cost
storage-only
asciiAgent orchestration over Telegram, running on box's VM infrastructure.61.0

Pricing

Price / hour (/hr)
Meter
subscription
Idle cost
boxPersistent Linux VMs with SSH, per-VM IPv4 and disk-level forking, priced flat.61.0

Pricing

Price / hour (/hr)
Meter
subscription
Idle cost
exe.devPersistent VMs you SSH into, with root, apt and systemd, on a flat monthly plan.61.0

Pricing

Price / hour (/hr)
Meter
subscription
Idle cost
NorthflankContainer platform with bring-your-own-cloud, GPUs and a sandbox-shaped API.44.6

Pricing

Price / hour (/hr)
$0.07 /hr
Meter
per-minute
Idle cost
full-rate
Self-hosted FirecrackerThe baseline: Firecracker on your own metal, plus every hard part you now own.40.3

Pricing

Price / hour (/hr)
$0.03 /hr
Meter
per-hour
Idle cost
full-rate
yespartialnounknown◆ measured · ▸ vendor-claimed · ▪ community · · inferredExpand a row for the source and date behind every cell.

Is the cheapest option the right one?

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.

The pricing traps

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.

How to choose in an afternoon

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.

How is this pricing data collected?

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.

Pricing questions

Is a container enough to run LLM-generated code, or do I need a microVM?

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.

Can I run a browser inside the sandbox instead of paying for a browser API?

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.

Do I pay while a sandbox sits idle waiting for the model to respond?

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.