Dora NodaFly.io will sell you a computer for your AI agent that costs nothing while it sleeps. Sprites — persistent Firecracker microVMs that boot in 1–2 seconds, checkpoint in about 300 milliseconds, and now expose themselves over MCP — bill $0.07 per CPU-hour only while awake, then go quiet after 30 seconds of inactivity and charge just pennies for cold storage. For a fleet of 200 agent sandboxes that each work only a few minutes per hour, that meter reads like the end of the sandbox pricing debate.
It is not. Run the numbers and a stranger picture emerges: per active hour, Sprites cost roughly twice what E2B and Daytona charge, and at any duty cycle above about 7%, a rack of owned Hetzner machines beats every managed meter on the page. The meter that matters was never the headline rate. It is who manages idle — you, with pause/resume code you write and maintain, or the vendor, with sleep built into the platform. This post recomputes the 200-sandbox receipt line by line, names the crossover points, and spells out what a self-hosted PaaS has to meter differently to compete.
The meter that changed
Sprites launched in January 2026 as Fly.io's answer to the "ephemeral sandbox" — a full Linux computer with a stateful filesystem, checkpoint/restore APIs, and network policy controls, rather than a container that forgets everything between runs. The pricing is the product as much as the VM: $0.07 per CPU-hour measured as cumulative CPU from cpu.stat, $0.04375 per GB-hour of RAM while awake, hot NVMe at $0.000683 per GB-hour, and durable storage at $0.000027 per GB-hour — about $0.02 per GB-month. A sprite that falls asleep stops billing for compute and memory entirely; a 10 GB box idling all month costs roughly twenty cents.
The MCP support is what turns this from an interesting meter into an urgent comparison. Sprites now sit behind a hosted MCP server, with first-party plugins for Claude Code and OpenCode that let an agent provision, drive, and tear down its own computers through the same tool protocol it already speaks. When the agent itself controls sandbox lifecycle, the billing meter taxes agent behavior directly: every idle minute the agent leaves a box awake, every checkpoint it keeps warm "just in case," shows up on the invoice. The question stops being "which sandbox is cheapest per hour" and becomes "which meter forgives the way agents actually work" — in bursts, with long thinking pauses between tool calls.
The rest of the market meters differently. E2B and Daytona have converged on identical raw rates — $0.0504 per vCPU-hour plus $0.0162 per GiB-hour, billed per second of wall-clock while the sandbox runs — with E2B's usable tier gated behind a $150/month Pro subscription (past 1-hour sessions and 20 concurrent sandboxes) and Daytona offering no subscription and a $200 signup credit. Modal prices per physical core at $0.1419 per core-hour, where a core is defined as 2 vCPUs, plus $0.024 per GiB-hour — roughly $0.071 per vCPU-hour equivalent. All three bill wall-clock while running; pausing to zero is possible (E2B snapshots, Daytona stop/archive) but it is an API call you make, not a default you get.
The 200-sandbox receipt
Here is the core deliverable: one fleet, 200 sandboxes at 1 vCPU and 2 GB each, priced across four duty cycles over a 730-hour month. Duty cycle means the fraction of wall-clock time each sandbox is awake and running. Two disclosures before the table: the Sprites CPU line assumes the vCPU is saturated while awake, which is an upper bound — real bursty agents consume a fraction of that, so reality favors Sprites over what you see below. And the Hetzner column is hardware-only, with no overcommit and no ops labor; both caveats get their own section.
| Duty cycle | Sprites (200×) | E2B (200× + Pro) | Daytona (200×) | Modal (200×) | Owned Hetzner (flat) |
|---|---|---|---|---|---|
| 5% (bursty agents) | ~$1,190 | ~$754 | ~$604 | ~$869 | ~$830 |
| 20% (active coding) | ~$4,640 | ~$2,568 | ~$2,418 | ~$3,475 | ~$830 |
| 50% (heavy use) | ~$11,538 | ~$6,194 | ~$6,044 | ~$8,687 | ~$830 |
| 100% (always on) | ~$23,036 | ~$12,239 | ~$12,089 | ~$17,374 | ~$830 |
How each column is built:
- Sprites: per sandbox, $0.07 × 730 × duty for CPU plus $0.04375 × 2 × 730 × duty for RAM, plus ~$0.20 for 10 GB of cold storage that bills regardless. At 5% duty that is $2.56 + $3.19 + $0.20 ≈ $5.95 per box, or ~$1,190 for the fleet. Cold storage for all 200 boxes is only ~$40/month — the sleep story is real; the awake rate is where the money goes.
- E2B/Daytona: per sandbox, ($0.0504 + 2 × $0.0162) = $0.0828 per running hour × 730 × duty. At 5% duty that is ~$3.02 per box, ~$604 fleet-wide. E2B adds the $150/month Pro subscription, which is noise at this scale (~2% of the 50%-duty bill) but a reminder that the sticker rate is not the whole contract.
- Modal: per sandbox, ($0.071 + 2 × $0.024) ≈ $0.119 per running hour × 730 × duty, billed on
max(requested, actual)per second. - Hetzner: 200 vCPUs and 400 GB of RAM map to seven AX102-class dedicated boxes (16 cores / 32 threads, 128 GB each) at €109/month with no overcommit — €763/month, roughly $830. The same arithmetic with a 2× overcommit, which bursty sandboxes tolerate easily, is four boxes at
€436/month ($475). Either way the line is flat: owned hardware costs the same whether the fleet idles or burns.
Read the crossover points off the table: the managed meters beat owned hardware only below roughly 4–7% duty cycle — about 3.6% for Sprites, 4.8% for Modal, 6.9% for E2B/Daytona at no-overcommit Hetzner prices. Past that, the flat hardware line wins by a widening margin, reaching a 14–28× gap at 100% duty. And note the upset inside the managed columns: E2B and Daytona beat Sprites at every duty cycle on raw compute, because $0.0828 per running hour is barely half of Sprites' $0.1575 per awake hour for the same 1 vCPU / 2 GB shape. Sprites' premium is the price of automatic sleep and a stateful disk — which is exactly what the next section tests.
Where zero-idle wins and where it loses
The table invites a lazy conclusion — "E2B is cheapest, buy E2B" — that collapses the moment you ask who manages idle. E2B and Daytona bill wall-clock while a sandbox runs. A coding agent that thinks for four minutes between 30-second bursts of tool use holds the meter open for the thinking unless your orchestration pauses the box, restores it, and handles the resume latency on every cycle. That pause/resume loop is straightforward to describe and genuinely annoying to operate: session lifetime limits (E2B's 24-hour Pro cap), snapshot storage accounting, cold-restore tail latency in the middle of an agent loop, and the failure mode where a pause call fails silently and the meter runs all weekend.
Sprites' auto-sleep after 30 seconds of inactivity deletes that entire category of work. Nothing to call, nothing to monitor, no weekend-meter failure mode — the platform observes idleness and stops charging. For bursty agent loops in the 5–20% duty band, that operational simplicity is the product, and the ~2× per-hour premium over E2B is the fee for never thinking about idle again. This is also why the MCP angle matters: when agents provision their own sandboxes through tool calls, "remember to pause your computer when you are done thinking" is not an instruction you can rely on. A meter that forgives agent behavior beats a cheaper meter that punishes it.
The symmetry breaks for continuously running workloads. CI-style pipelines, always-on preview environments, long-horizon agents that grind for hours without pausing, inference-adjacent sandboxes that hold models warm — anything past ~20% duty — pay the full awake rate with no idle to forgive, and there Sprites is simply the most expensive managed column. That is the honest shape of the "zero charge when idle" pitch: it wins exactly where agents are bursty and loses everywhere else, with the crossover against owned hardware sitting at a duty cycle most production fleets exceed by their second month.
One more nuance the table hides: Sprites bill cumulative CPU, not wall-clock-awake. A sandbox that is awake but 90% idle — an agent reading output, a dev box with an open terminal — consumes a tenth of the CPU line while E2B bills the full wall-clock hour for the same stillness (unless paused). My table credits Sprites with none of that; it assumes saturation. For real interactive-agent traces, where CPU while "active" often averages 20–40% of a vCPU, Sprites' effective rate drops toward and sometimes below the E2B line. If your workload is "awake a lot, computing a little," re-run the table with a CPU-utilization factor applied to the Sprites column only — that is the one case where the headline $0.07 rate understates how cheap Sprites can be.
Isolation parity: what "the same sandbox" costs to self-host
Comparing a managed Firecracker microVM to a bare Hetzner box is only fair if the self-hosted side actually delivers the same isolation. Sprites and E2B both run tenants in Firecracker microVMs — hardware-virtualized, KVM-backed, with a guest kernel per tenant. Daytona defaults to containers with Kata or Sysbox as the hardened option. So the $830 Hetzner column owes an isolation implementation before it can stand next to the managed columns, and there are three credible ones.
The closest to apples-for-apples is E2B's own open-source infrastructure: Firecracker on Nomad with Terraform modules, the same microVM substrate as the managed product, deployable on any bare metal you own. The cost is the control plane you now operate — image builds, snapshot storage, network policy, API surface — plus the engineering time to stand it up, which is weeks, not days, for a production-hardened deployment. The middle path is Kata Containers as a Kubernetes RuntimeClass: pod-shaped UX with a microVM per pod, a reasonable fit if the fleet already runs on Cluster API. The lightest path is gVisor, a userspace kernel that sandboxes syscalls without hardware virtualization — cheaper per sandbox and denser to bin-pack, but a weaker boundary than a microVM, and Spectre-class side channels have historically been its uncomfortable footnote.
Whichever substrate you pick, two cost lines the managed meters include must be added to the Hetzner side by hand. First, checkpoint and snapshot storage: Sprites' ~$40/month for 200 cold boxes looks trivial until you replicate it as NVMe plus an S3-compatible object store with lifecycle rules you wrote. Second, ops labor: someone pages when the snapshot store fills, when a kernel upgrade breaks the snapshotting path, when a noisy tenant eats the host. At small fleet sizes that labor dominates everything — one on-call engineer costs more than the entire hardware column. The fair reading of the table is therefore conditional: owned hardware wins above ~7% duty cycle once the fleet is large enough that ops labor amortizes, and the managed premium below that line is buying freedom from exactly this section.
What a self-hosted PaaS must meter differently
Suppose you are building the self-hosted answer to this market — E2B-style sandboxes on owned capacity, the way bex is the self-hosted answer to Render for web services. The table above is your pricing spec, and it demands three breaks from how platforms usually meter.
First, bill cumulative CPU-active, not pod-uptime. Every managed vendor in this comparison already does: Sprites via cpu.stat, E2B and Daytona per second of running time with pause supported, Modal on max(requested, actual). A self-hosted sandbox that bills wall-clock pod lifetime while competitors forgive idle will lose every bursty-agent workload on price, because bursty is what agents are. The metering primitive already exists — cgroup CPU accounting is exactly what cpu.stat exposes — so this is a billing-pipeline decision, not a research project.
Second, price checkpoint and cold storage near cost and say so. Sprites' $0.02 per GB-month sets the anchor: 200 sleeping boxes must cost tens of dollars, not hundreds. On owned NVMe plus object storage, that price still leaves margin — but only if the platform tiers hot execution storage away from cold checkpoint storage instead of billing one blended "disk" line. Tenants deciding whether to keep 500 sleeping sandboxes do that multiplication instantly.
Third, make sleep automatic and free, not an API the tenant must remember. This is the deepest lesson of the Sprites meter. E2B's pause exists and is cheaper per hour, yet Sprites commands a premium for doing it without being asked — especially now that MCP-driven agents, not careful humans, hold the lifecycle. A self-hosted platform that requires tenants to orchestrate their own idle will be compared against Sprites' effortlessness, not E2B's rate card, and will be found tedious. Auto-suspend with fast resume (Firecracker's snapshot path restores in hundreds of milliseconds) is table stakes for the roadmap, not a stretch goal.
None of this requires matching Fly's global footprint or E2B's template library on day one. It requires respecting what the comparison actually turned on: the duty cycle of agent work, and a meter shaped like it.
The decision rule
If your sandboxes are awake less than ~5% of the time — sporadic agent experiments, a few developers with AI assistants — buy managed and prefer the meter that sleeps by itself; the premium over owned hardware is a few hundred dollars a month and the ops savings dwarf it. Between 5% and 20% duty, do the honest pause-math: E2B or Daytona win if you will actually operate aggressive auto-pause, Sprites win if you will not, and owned hardware starts calling past ~7% for fleets big enough to amortize an operator. Past 20% duty, stop debating vendors and price the Hetzner column — no per-second meter survives contact with a workload that never sleeps.
The broader lesson outlives any single price cut. Sandbox vendors are converging on the same realization: agents work in bursts, think longer than they compute, and cannot be trusted to clean up after themselves. Meters are being reshaped around that behavior — cumulative CPU, automatic sleep, near-free cold state — and every platform that hosts agent sandboxes, managed or self-hosted, will have to meter the burst rather than the box. Price your roadmap accordingly.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
