Idempotent compute pays off when the storage keeps up (Cheap agents need fast disks)
April Wong
Quirq benchmarked Nirvana, Google Kubernetes Engine and E2B agent sandboxes. Nirvana recovered all 5,501 checkpoints and released compute in 1.46 s, against 9.57 s on GKE. E2B recovered none.
TL;DR
- Cheap agents need fast disks. Agents write constantly, but their machines get reclaimed, preempted and evicted mid-task. On most sandboxes the workspace lives in memory or on that machine's local disk, so losing the machine means losing the work. You pay again to redo it, and you pay for idle machines because releasing one safely is slow.
- Nirvana kept everything. All 5,501 committed checkpoints came back on a brand-new pod after an ungraceful kill. Its 200-module build was destroyed five times mid-run and still produced a byte-correct binary with zero recompiled work. E2B recovered none.
- It is faster on every operation an agent repeats. ~6× the durable checkpoint throughput (18,733/s vs 3,148/s), ~6× lower commit p99, idle compute released in 1.46 s against 9.57 s, teardown in 0.73 s against ~30 s.
- The disk is the reason. Compute was matched at 8 vCPU and orchestration was identical, so storage was the only real variable. An agent needs a disk that outlives the machine, stays fast on a small volume, has a real and quick durability barrier, and doesn't degrade over hours. Nirvana built its own to do all four.
- It costs ~6× less for the same durable work. Roughly $0.0040 per million durable checkpoints against $0.024, plus more agents per node and idle gaps short enough to reclaim. A 1,000-agent fleet pays for ~2,800 compute-hours instead of 8,000.
Agents write constantly: repos, dependencies, caches, checkpoints. Their machines get reclaimed, preempted and evicted, often mid-task.
On most sandboxes those files live in memory or on local disk, so losing the machine means losing the work. Which means paying for it twice: once for the compute you already spent, and again to redo it.
That is half of what makes agent fleets expensive. The other half is idle. Releasing a machine safely takes around ten seconds on most platforms, and if state might not survive, teams leave agents running rather than risk it. So you pay for machines doing nothing, all day.
Both problems have the same root. Fix where the state lives and how fast you can let go of a machine, and both bills shrink.
That is what Quirq set out to test. They ran benchmarking across Nirvana Agent Sandboxes, Google Kubernetes Engine and E2B. One question: can you replace the machine underneath an agent without losing what the agent already did?
The benchmark, in short
| Nirvana | GKE | E2B | |
|---|---|---|---|
| fsync p50 (durability barrier) | 1.65 ms, real flush | 2.9 ms, real flush | ~0 ms, a no-op |
| Checkpoints recovered after an ungraceful kill | 5,501 / 5,501 | durable, shown in build test | 0 / 5,000 |
| 200-module build, destroyed mid-run | 0 wasted compiles, 5 destructions | 0 work lost, ~35 s rebuild each | workspace lost on crash |
| Durable checkpoints/s at 100K | 18,733 | 3,148 | non-durable |
| Commit p99 | 12.4 ms | 72.0 ms | non-durable |
| Pause, release compute (p50) | 1.46 s | 9.57 s | ~0 s (memory snapshot) |
| Teardown (p50) | 0.73 s | ~30 s | not measured |
| Cost per 1M durable checkpoints | ~$0.0040 | ~$0.024 | undefined |
Compute matched at 8 vCPU. Lifecycle timings from ~96 runs, p50/p95/p99 reported. Cost is compute-time per durable checkpoint, with both platforms priced at GKE's public e2-standard-8 rate, so the gap is throughput and not pricing. Storage and platform fees excluded, no vendor discounts.
Note, creating a workspace for the first time takes ~20.6 s on Nirvana against GKE's ~12 s, because attaching a durable networked volume takes a few seconds. You pay that once, at setup. After that the agent pauses in 1.46 s, resumes with everything intact, and never rebuilds its workspace again. Ten seconds once, in exchange for never losing work, is a good trade.
E2B is the fastest of the three at a graceful pause, effectively instant, because it snapshots memory instead of using a volume.
Failure was induced differently on each platform, because each exposes different primitives. The checkpoint crash test ran on Nirvana and E2B only: Nirvana had the process killed mid-write and the pod rebuilt under a new UID, while E2B, which has no host-failure primitive, had the sandbox terminated. GKE's crash durability was verified in the build test instead. E2B Volumes is in private beta and was not tested.
Every number here is a storage number
Compute was matched at 8 vCPU. Orchestration was identical. The only real variable was the disk under the workspace, and it decided most of them.
Most block storage was built for databases and boot volumes. Agents are a different workload: created and destroyed thousands of times a day, writing the whole time they exist. They need four things from a disk, and each one produces a line in that table.
| What an agent needs | Why | What Nirvana does | What it produced |
|---|---|---|---|
| Outlive the machine | Local disk dies with the machine | Networked volume, reattaches to a new pod | 5,501 / 5,501 checkpoints recovered |
| Stay fast on a small volume | Hyperscaler IOPS scale with capacity, not need | 20,000 baseline IOPS on every volume | ~97,700 4K random-write IOPS on 20 GiB |
| Have a real, fast durability barrier | Slow means fewer checkpoints. Instant means none were safe | fsync returns in 1.65 ms after a real flush | 18,733 durable commits/s, 12.4 ms p99 |
| Hold up under load | Burst credits expire, then the disk collapses | 2.71 GiB/s held through a 30-minute write | ~3× at 1K checkpoints, ~6× at 100K |
Two of these results get mistaken for something else.
Fast pause looks like scheduling. It is storage. Releasing compute in 1.46 s only works because there is nothing left to move first. If an agent's state lives on the machine, pausing means copying it somewhere safe before the machine can go, and that is where the seconds disappear.
The cost advantage is not a discount. Compute bills by the second. A disk that commits ~6× more durable checkpoints per second finishes the same work in ~6× less compute-time, so the bill is smaller. Nothing was marked down.
Storage is why. Owning the path is how.
A fast disk on its own is not enough. Nirvana owns every layer the lifecycle touches: the metal, the storage, the networking, Kubernetes, and the sandbox orchestration. Volume attach, scheduling and cleanup are tuned together instead of negotiated across vendors, which is why teardown finishes in under a second. The storage is the part competitors cannot copy. Owning the path from metal to sandbox is what turns it into these numbers.
So the real comparison is not a sandbox against Kubernetes. It is a purpose-built platform against building one yourself. GKE runs the same container, but your team then owns namespaces, PVCs, ingress, auth, routing, lifecycle logic and cleanup. Nirvana ships all of that as one API, keeps the workload container-portable, and gives each customer a dedicated cluster of hardened, unprivileged sandboxes.
What it costs, and what it saves
Cost per unit of durable work, from measured throughput. Both platforms are priced at GKE's own public e2-standard-8 rate, compute only, no discounts:
| Platform | Durable checkpoints/s @ 100K | Cost per 1M durable checkpoints |
|---|---|---|
| Nirvana Agent Sandboxes | 18,733 | ~$0.0040 |
| GKE (e2-standard-8, public rate) | 3,148 | ~$0.024 |
That is roughly 6× cheaper for the same durable work, and it is a floor rather than a ceiling: Nirvana's own vCPU-hour rate is lower than GKE's, and this calculation gives Nirvana none of that advantage. It shows up in three places:
- More agents per node. An agent whose state lives on a volume does not need a machine held open for its whole life. One node can host many agents in sequence instead of one agent for hours.
- Idle time you can actually reclaim. At a 1.46 s pause, a 10-second gap is already worth releasing compute for. GKE's 9.57 s pause means waiting ~21 s before it pays. A 1,000-agent fleet with ~70% reclaimable idle pays for roughly 2,800 compute-hours instead of 8,000.
- No work paid for twice. An interrupted run that resumes costs you the remainder. An interrupted run that restarts costs you the whole thing again.
Try it
The agents people want next are the ones that remember. They hold context across sessions, run for hours, checkpoint constantly, and pick up where they left off. Every one of those behaviours is a write. So the ceiling on how capable your agents can be is set by the disk underneath them.
Nirvana Agent Sandboxes are generally available. Two endpoints and an API key, with SDKs in Python, TypeScript, Go, Java, Kotlin and C#.
Read the docs → ·
Talk to Nirvana →
About Nirvana Labs
Nirvana Labs is a high-performance storage cloud purpose-built for Web3, AI, and databases. Accelerated Block Storage (ABS) offers 20,000 baseline IOPS included, with no over-provisioning. Managed Kubernetes (NKS) with Karpenter auto-scaling, high-clock-speed compute, and private networking. Backed by Jump Trading, Crucible, and others, with 50+ customers live in production today.
Related Posts

GPU Starvation Is a Data-Path Problem, Not Just a Chip Problem
Nirvana's layer is high-performance block storage. ABS ships 20,000 baseline IOPS against AWS gp3's 3,000 default, bursting to 600,000, and in our own benchmarks runs 10.5x faster than gp3 on cold-read analytical queries.

The Ultimate AI Agent Sandboxes Comparison 2026
We compare every agent sandbox so you don't have to. Nirvana, E2B, Modal, Vercel, Daytona & 8 more compared on persistence, speed, and isolation.

Managed ClickHouse, Explained: the options and what actually decides performance
Managed ClickHouse, Explained: the options and what actually decides performance