Fly.io Sprites at $0.07 Per CPU-Hour: Why Zero When Idle Still Cost $35,000 for 200 Sandboxes

AI sandboxes finally have too many pricing models, not too few. E2B and Daytona charge a flat $0.0504 per vCPU-hour whether your agent is thinking or sleeping. Modal charges $0.1419 per physical core-hour. And then there is Fly.io Sprites — $0.07 per CPU-hour, but only while the sandbox is actually running. Idle? Zero.

That last line is the hook every vendor wants you to remember. The part that matters for your bill is how often your sandboxes are actually idle.

A 2026 benchmark that put 200 concurrent sandboxes side by side found Sprites the most expensive of the bunch at over $35,000 per month, even with free idle time, while Northflank's PaaS-hosted sandbox pricing landed around $7,200 for the same workload. The spread is not a rounding error — it is the difference between a meter that stops when idle and a workload that is rarely idle. When your agents spend 80 to 90 percent of wall-clock time executing code, waiting on a model, or holding state, "zero when idle" saves you almost nothing. Owned Hetzner capacity, where 200 sandboxes bin-packed onto a small fleet have no per-second meter at all, comes in an order of magnitude lower still.

Here is what each model actually charges, when idle-free billing helps, and where it stops being a discount.

What Sprites Actually Is​

Sprites is Fly.io's answer to the ephemeral sandbox problem. CEO Kurt Mackey framed it directly: traditional container sandboxes force agents to rebuild their environment on every invocation. Sprites instead are persistent Firecracker microVMs — Linux VMs that boot in seconds, carry up to 100 GB of persistent storage, and preserve filesystem state across runs.

The billing innovation is separate from the VM innovation. A Sprite runs only when there is activity. When idle, it shuts down but keeps its disk. You are billed per second for CPU time, memory, and storage actually consumed — not for the wall-clock time the sandbox exists. Fly.io's own framing puts a typical four-hour coding session at roughly $0.46, precisely because most of that session is idle from the infrastructure's point of view.

That is a real improvement over always-on VMs and over serverless containers that bill for provisioned memory even while the agent waits on an LLM response. But it is a specific kind of saving: it optimizes for bursty, low-duty-cycle use.

• CPU: ~$0.07 per CPU-hour, billed per second while active, $0 when idle
• Memory and storage: billed proportionally while active, plus persistent volume cost at rest
• Idle: no CPU or memory charge — only the disk you keep

Compare that to the flat-rate competition that bills for every second the sandbox container exists, idle or not:

E2B and Daytona are the flat-rate baselines most teams quote. Modal is higher per core but scales to zero between invocations. Sprites sits in the middle on sticker price per hour — more expensive per active hour than E2B/Daytona, cheaper than Modal — with the unique idle-free discount.

The question is not whether $0.07 is more than $0.0504. It is whether "more per hour, but fewer billed hours" nets out cheaper for your workload.

The Math: When Idle-Free Wins and When It Does Not​

Take a single sandbox configured as 1 vCPU and 1 GiB RAM — the minimum most agent frameworks request.

At flat-rate pricing, the monthly cost for one always-allocated sandbox is deterministic:

• E2B / Daytona: ($0.0504 + $0.0162) x 730 hours = $48.62/month
• Modal (1 physical core, 1 GiB): ~$0.1419/hr x 730 = ~$103.60/month before memory add-ons and multipliers
• Northflank (same 1 vCPU/1 GiB): ($0.01667 + $0.00833) x 730 = $18.25/month

At Sprites' active-only pricing, the same sandbox costs:

• Sprites 100% active: $0.07 x 730 = $51.10/month (plus memory and storage while active)
• Sprites 50% active (idle half the time): $0.07 x 365 = $25.55/month
• Sprites 20% active: $0.07 x 146 = $10.22/month
• Sprites 10% active: $0.07 x 73 = $5.11/month

With memory included proportionally, add roughly $0.01 to $0.02 per GiB-hour while active, so the cross-over points shift slightly — but the shape is the same.

That reveals the sensitivity the headline hides:

• If your sandbox is idle more than ~60% of the time, Sprites undercuts E2B/Daytona's flat $48.62. A human developer who opens a sandbox, runs a command, and idles for minutes between prompts lives here. The $0.46 per four-hour session number assumes exactly this pattern.
• If your sandbox is active more than ~60% of the time, Sprites costs more than the flat-rate alternative it was meant to undercut. An AI agent that loops continuously — execute code, read output, call the model, execute again — lives here.
• At 90 to 100% utilization, which is the normal state for 200 concurrent agents in a benchmark or production batch, the idle discount is near zero. You pay the higher per-hour rate for essentially every hour.

Most agent workloads cluster at the high-utilization end. An agent sandboxed to write code, run tests, and iterate on failures does not idle politely between steps — it burns CPU waiting on tool output, holds memory for the repo and language servers, and keeps the filesystem warm. The model may be the bottleneck, but from the sandbox's perspective that is still active time holding state.

That is why a per-second meter that charges nothing when idle can still produce the highest bill in a comparison. The meter is generous on a dimension your workload does not use.

The 200-Sandbox Bill: $35,000 vs $7,200 vs Owned Hardware​

Scale the single-sandbox math to the 2026 benchmark that compared 200 concurrent sandboxes across vendors. The benchmark's headline numbers were:

• Fly.io Sprites: over $35,000/month for 200 concurrent sandboxes
• Northflank: around $7,200/month for the same 200
• E2B / Daytona at flat rate: 200 x $48.62 = ~$9,724/month (compute + memory, before volume)
• Modal: 200 x ~$103.60 = ~$20,720/month at list, often lower with preemptible or committed discounts

Sprites lands on top despite the idle-free design because 200 concurrent agents are, by definition, not idle. Concurrency is utilization. When every sandbox has work queued, "free when idle" is free on zero hours.

Northflank's lower number reflects a fundamentally cheaper per-unit rate ($0.01667 vs $0.0504) more than a better idle policy. E2B and Daytona sit in between — cheaper sticker than Sprites, more expensive than Northflank, but all three meter the same way once the sandbox is allocated.

Now compare to owned hardware with no meter at all.

What 200 sandboxes cost on Hetzner​

A self-hosted sandbox fleet does not pay per second. It pays per machine per month, and bin-packs many sandboxes onto each machine using lightweight isolation — Firecracker microVMs, gVisor, or container-level sandboxes behind your own orchestrator.

A representative Hetzner fleet for 200 sandboxes (1 vCPU, 1 GiB each, burst overcommit 1.5 to 2x since not every sandbox peaks simultaneously):

Even after Hetzner's three 2026 price adjustments — April cloud increases of 30 to 37 percent, dedicated setup-fee hikes, and the June 15 portfolio standardization that raised CCX/CPX dedicated lines by over 100 percent on top of April — a fleet that comfortably holds 200 sandboxes lands in the €400 to €900 per month range depending on instance family and packing density.

That is not a typo against the metered numbers:

• Sprites: ~$35,000/month
• Northflank: ~$7,200/month
• E2B/Daytona: ~$9,700/month
• Hetzner fleet (owned, bin-packed): ~€500–900/month

The owned fleet is 8 to 70 times cheaper for sustained concurrent workloads, even after the steepest Hetzner hikes in a decade. The gap narrows only when average concurrency is low — which is exactly the sensitivity analysis in the previous section. At 10 percent average utilization (20 of 200 sandboxes active at any moment, the rest idle and un-billed on Sprites), the metered bill falls proportionally while the owned fleet cost stays flat. That is the one shape where idle-free billing genuinely wins over flat hardware.

For teams running agent sandboxes as a product feature — code execution for every user session, CI-like agent loops, or batch evaluation — concurrency is high and sustained. Owned hardware wins decisively.

Where Per-Second Idle-Free Actually Helps​

Sprites' model is not bad. It is narrow. It is excellent for three specific shapes:

1. Human-in-the-loop development sandboxes. A developer who spins up a Sprite, runs a few commands, and leaves the sandbox idle for 50 minutes while reading docs pays for minutes, not hours. The $0.46 per four-hour session estimate is realistic here. For interactive use with long idle gaps, idle-free billing beats any flat allocation.

2. Bursty, low-concurrency agent fleets. If you run 1,000 sandboxes but only 50 are active at any second — for example, agents that wake on a webhook, do 30 seconds of work, and sleep — you pay for 50 CPU-hours per hour, not 1,000. The per-second granularity matters more than the per-hour rate.

3. Ephemeral, short-lived tasks where startup time dominates. Sprites boot in seconds and preserve state without paying for idle. If your alternative is keeping a warm pool of always-on VMs "just in case," idle-free billing eliminates the standing cost of that pool.

Where it does not help is the workload most teams actually benchmark: sustained parallel agents.

• Batch evaluation: 200 agents each running a full test suite for minutes without idle gaps. Utilization near 100 percent.
• Continuous coding agents: agents that loop on compile-run-fix until green. The sandbox is active the entire time, even while the LLM generates the next patch — the filesystem and language server stay resident.
• User-facing code execution: if every active user gets a sandbox and your concurrent user count is the load, idle time is not free capacity — it is unused capacity you already paid the fixed fleet cost for, but on metered billing it is still billed active hours for every concurrent user.

The honest way to read "zero charge when idle" is as a discount whose value equals your idle ratio. If you do not know your idle ratio, you do not know whether the discount is 5 percent or 80 percent — and most teams discover it is single digits only after the invoice arrives.

The Platform Question Behind the Pricing​

The sandbox pricing debate mirrors the larger PaaS versus self-hosted debate this blog has tracked all year. Metered per-second billing, like metered egress and metered build minutes, shifts forecast risk onto the tenant. A fixed hardware bill shifts utilization risk onto the platform — if your sandboxes sit idle, you still paid for the machines.

Which risk you prefer depends on your workload shape:

• Unpredictable, spiky, low-average-concurrency workloads favor metered billing. You pay only for what you use and avoid provisioning for a peak that rarely arrives.
• Predictable, high-concurrency, sustained workloads favor owned hardware. The fixed bill is lower than any meter at high utilization, and the only variable is how well you bin-pack.

For AI sandboxes specifically, the trend is toward higher sustained concurrency. Agents are not a feature you offer to ten power users — they are the product. When every user session spawns a sandbox and sessions overlap, concurrency tracks user growth, not idle gaps.

A self-hosted PaaS that bin-packs sandboxes onto owned Hetzner capacity via Cluster API makes that trade explicit. There is no per-second meter, no idle discount to calculate, and no surprise when utilization climbs. The fleet autoscales on machine count, not on billed seconds, and the cost per additional sandbox falls as packing density improves — the opposite of a linear per-sandbox meter.

That does not mean you should self-host sandboxes on day one. If you run a handful of sandboxes for internal tooling, the operational overhead of a fleet dwarfs the $50 per sandbox per month you would pay E2B or Sprites. But at 50, 100, or 200 concurrent sandboxes — the scale where the $35,000 benchmark lives — the operational cost is already amortized and the meter becomes the dominant line item.

A practical decision framework:

1. Measure your idle ratio first. Instrument a week of sandbox CPU active time versus wall-clock allocated time. If active time is above 60 percent, flat-rate or owned hardware will beat idle-free on price.
2. Project concurrency, not total sandboxes. 1,000 sandboxes at 5 percent concurrency is a very different bill than 200 sandboxes at 90 percent concurrency, even though the first number sounds larger.
3. Price the owned fleet at current Hetzner numbers, not 2024 blog posts. After three 2026 hikes, the CCX/CPX lines that many comparisons quote have more than doubled. Use the June 15 standardized -1/-2/-3 SKUs and verify the region. Even at new prices, the fleet math still wins at high concurrency — but the margin is smaller than stale comparisons suggest.
4. Consider the control plane. A managed sandbox vendor bundles isolation, networking, and snapshot management. Self-hosting means you own that too — via Firecracker, Kata Containers, or gVisor — and the cost of building it belongs in the comparison.

Bottom Line​

Fly.io Sprites is a genuinely good sandbox primitive — persistent Firecracker VMs with fast boots and stateful disks solve a real pain for agent workloads. Its per-second, zero-when-idle billing is the right model for bursty, human-paced development where sandboxes spend most of their lives idle.

But "zero when idle" is not "zero, period." For the sustained, high-concurrency agent workloads that dominate both benchmarks and production — where 200 sandboxes are concurrent because 200 agents are working — the idle discount approaches zero and the higher active rate becomes the whole bill. That is how Sprites lands at over $35,000 for 200 sandboxes while Northflank quotes around $7,200 and a bin-packed Hetzner fleet does the same work for a few hundred euros.

The cheapest sandbox is not the one with the cleverest meter. It is the one whose billing shape matches your utilization shape. If your agents are busy, own the hardware they run on.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Bin-pack agent sandboxes onto your own Hetzner fleet with no per-second meter. Star the repo on GitHub or deploy your first app today.