The Machine Can Disappear. The Work Doesn't Have To.

There is a quiet assumption embedded in almost every AI agent deployment today:

The machine must not die.

That assumption is wrong - and expensive.

A coding agent might spend four minutes compiling 180 modules before its host is recycled by an autoscaler. A research agent might checkpoint state across a thousand turns before a node failure hits. A CI agent might be halfway through cloning dependencies when the pod is evicted.

The instinct is to prevent these events. The better answer is to design for them.

We call this property idempotent compute: the ability to replace the machine underneath an agent without losing the work the agent has already committed. Not crash-tolerance through redundancy. Not keepalive polling. Not expensive always-on reservations.

To test which platforms actually deliver this, we benchmarked three agent sandbox architectures - Nirvana with Accelerated Block Storage (ABS), Google Kubernetes Engine (GKE), and E2B - running identical workloads through XO as a neutral orchestration layer.

What idempotent compute actually requires

The idea is simple. The execution is demanding.

For compute to be safely replaceable, three things must be true:

Most platforms satisfy one of these. Nirvana's ABS satisfies all three - and this post is the evidence.

The disk is the argument

Every claim about idempotent compute traces back to one question: is the storage layer fast enough that durable persistence can be part of the agent's execution loop - not an occasional, expensive operation, but a continuous one?

We measured ABS directly using fio with O_DIRECT - the same write patterns that git commit, SQLite transactions, and checkpoint writes generate.

This is what makes idempotent compute practical, not theoretical: the storage is fast enough that agents can checkpoint continuously without slowing down.

The same test on GKE

GKE's persistent disk is genuinely durable - it passes the real fsync barrier test (data is actually flushed before the commit returns). But on a 20 GiB agent workspace, performance is in a different category:

We tested pd-ssd specifically because it is the obvious objection. It barely moved - because GKE's persistent disk IOPS scale with volume size and vCPU count, not disk class. At 20 GiB, both tiers hit the same ceiling. To unlock pd-ssd's full per-GB IOPS you would over-provision hundreds of gigabytes you do not need. ABS decouples performance from capacity - ~98K IOPS on 20 GiB is not an artifact of a large volume.

E2B: why fsync matters

E2B's disk is a different story. We tested durability three ways - os.fsync, an O_DSYNC file, and fio's sync latency. Every time, fsync returned in ~0 microseconds - no slower than a write with no sync at all.

ABS is not only durable - it is also 2.3× the IOPS and 6.5× the sustained throughput of E2B's local disk. The speed gap is not a tradeoff for durability. Against the tested local disk, Nirvana ABS delivers durability without sacrificing performance.

The practical consequence is agent density: because compute can be released in ~1.5 seconds and resumed with no state rebuild, a single cluster can serve far more concurrent agents than architectures that must keep a VM alive for each one. More concurrent agents, reclaimed faster, means more completed jobs per cluster at lower cost per job.

Two numbers matter most:

• fsync latency at 1.65 ms p50. Every durable checkpoint - every git commit, every SQLite transaction - waits for this before it is safe. At 1.65 ms, an agent can checkpoint thousands of times per minute without the storage becoming the bottleneck.
• Sustained throughput flat over 30 minutes. Many cloud disks perform well in brief bursts then hit throttling cliffs as burst credits expire. ABS held 2.71 GiB/s through the final quartile within 0.6% of the first. An agent that runs for hours does not encounter a different disk than one that runs for seconds.

The crash test: where idempotency is proven or lost

A benchmark that only tests clean pauses is measuring the easy case. The hard case is an ungraceful failure - the kind an autoscaler, a preemption event, or a node failure causes - where the agent gets no warning and no chance to flush state.

We wrote durable checkpoints, killed the compute ungracefully, recreated the environment on a brand-new pod (pod UID changed - we verified the original was gone), and counted what came back.

The Nirvana result is the definition of idempotent compute. The committed work outlived the compute that produced it. A new pod attached the same ABS volume and continued exactly where the old one stopped.

The E2B result is the consequence of a no-op fsync: every checkpoint that "committed" was sitting in a volatile write-back cache. When the microVM died, the cache died with it. Five thousand checkpoints, none durable.

Five compute destructions. Zero wasted compiles.

Synthetic checkpoints prove the principle. We wanted to see what idempotent compute looks like under a workload an agent actually performs.

We ran a real 200-module C build - roughly four minutes, with a deterministic checksum so correctness is verifiable. Then we crashed the compute mid-build, repeatedly, and checked whether the work survived.

On ABS, the incremental object cache lives on the durable volume. Each interruption created a brand-new pod. make resumed from exactly where it stopped.

Five full compute destructions. Zero wasted compiles. The build did not notice that the machine running it had been replaced five times.

GKE survives too - its persistent disk is durable, so the cache reattaches. But each interruption cost ~35 seconds of pod rebuild and workspace bootstrap. ABS interruptions were sub-second pauses. That ~20× difference is the gap between compute that is theoretically replaceable and compute that is practically disposable.

E2B's graceful pause preserves the running process - the build keeps going through a pause/resume without losing a module. That is a genuine advantage. But a crash kills the microVM's local disk. Two ungraceful failures destroyed 52 and 60 modules of progress, each requiring a restart from zero.

Only ABS combines crash-durability with sub-second interruption cost. GKE survives crashes but makes you wait ~20× longer each time. E2B is instant on a graceful pause, invisible on a crash.

Durable checkpoints at scale: the lead widens

For idempotent compute to be useful in practice, checkpointing must be cheap enough that agents do it continuously - not as an occasional, expensive operation, but after every meaningful step.

We ran a fleet-scale durable checkpoint workload scaled from 1K to 100K checkpoints, with every commit required to be durably flushed before it counted. ABS and GKE were held at a matched 8 vCPU so the disk was the only variable.

ABS runs the durable checkpoint path ~6× faster with ~6× lower p99 commit latency. The gap widens with load - approximately 3× at 1K checkpoints, 6× at 100K - which means the advantage compounds the more aggressively an agent checkpoints.

E2B posts high throughput numbers in this workload, but those numbers are the no-op fsync: commit returns in ~0.04 ms because nothing was durably written. The crash test is the honest accounting.

Releasing compute: the third requirement

Idempotent compute requires that releasing the machine is cheap. If pausing takes 30 seconds, it will not happen - agents stay running while idle, compute sits allocated, and the economics of disposable compute do not materialise.

Absolute percentiles across ~96 runs:

Pause and teardown stay sub-second even at p99. The tail is as tight as the median. Provisioning a brand-new workspace costs more (~21 s p50) - expected for a durable networked volume - but agents do not provision new workspaces often. They pause and resume constantly.

At 1.46 s pause p50, the break-even idle window is about 10 seconds: any idle gap longer than that makes pausing profitable. At GKE's 9.57 s pause p50, the break-even window is ~21 seconds - meaning agents must be idle for longer before it is worth reclaiming compute. A 1,000-agent fleet at ~70% reclaimable idle pays for roughly 2,800 compute-hours instead of 8,000.

Once the volume reattaches, the agent is back at work in milliseconds. git status over 2,394 files completes in ~20 ms cold. The agent does not rebuild its workspace - it just continues.

What this means for agent density and cost per job

Two implications follow directly from ABS's pause and checkpoint numbers that do not show up in raw throughput tables.

First, agent density. When a persistent VM is required per agent, cluster capacity is a hard ceiling. When compute is safely disposable, paused in ~1.5 seconds, resumed without workspace rebuild, the same cluster can serve significantly more concurrent agents by reclaiming idle compute between tasks.

Second, cost per completed job. Higher agent density and faster idle reclamation mean each unit of compute does more work. Combined with ABS's ~6× checkpoint throughput advantage over GKE, the economics compound: more durable work per second, fewer compute-hours billed per job, and no jobs lost to crashes that would require a restart from zero.

The cost of durable work

Everything above compounds into one number: cost per unit of durable work.

We computed this from public list prices × our own measured throughput - not vendor discount claims. At a matched 8 vCPU, ABS commits ~6× more durable checkpoints per second than GKE. Compute is billed by the second, so the same durable workload consumes ~6× less compute-time on ABS.

E2B drops out of the cost comparison on durable work - its commits are not crash-durable, so the fair denominator does not exist. The honest durable-vs-durable comparison is ABS vs GKE, and ABS is approximately 6× cheaper per unit of durable work at equal compute pricing - before any Nirvana discount.

The idle lever compounds this. ABS's shorter pause time (~1.5 s vs ~9.6 s on GKE) makes compute reclamation practical for much shorter idle windows, meaning a fleet running on ABS can reclaim far more idle compute without the agent experiencing meaningful delay on resume.

Three platforms, three definitions of "persistent"

The benchmark surfaces a more important distinction than raw speed: these platforms optimize for different failure models, and those models have different consequences for idempotent compute.

E2B is the fastest way to run a sandbox. It is not idempotent compute - a crash loses everything.

GKE provides idempotent compute in principle. In practice, ~35-second interruptions and ~30-second teardowns make it expensive to actually treat compute as disposable.

Nirvana ABS provides idempotent compute in practice: crash-durable storage, ~1.5 second pause and sub-second teardown, and a disk fast enough that continuous checkpointing is the default, not an optimization.

Conclusion: make the work permanent

The most resilient agent is not the one running on the most reliable machine.

It is the one that does not need any particular machine to be reliable.

Idempotent compute changes the design question from "how do we prevent compute from failing?" to "how do we make compute safe to replace?" The answer is a storage layer that is durable enough to survive compute death and fast enough that agents use it continuously.

Our benchmarks show what that looks like on ABS:

XO makes the agent lifecycle easy to orchestrate. Nirvana provides the compute. ABS provides the storage that makes those two lifetimes cleanly separable - and that separation is what lets a single cluster run more concurrent agents, reclaim idle compute faster, and complete more jobs without adding machines.

The result is an agent that can lose its machine five times and still deliver a byte-correct binary. That is what idempotent compute looks like in practice.

Methodology

All experiments ran through XO as a neutral orchestration layer, ensuring identical provisioning logic, lifecycle handling, and validation across all three platforms. The same workspace image, repository, and dependency installation were used throughout.

Workspace: 20 GiB persistent volume (ABS storageClass: "" on Nirvana; networked persistent disk on GKE). E2B used the same workspace image built as a template.

• Nirvana: nirvanalabs.io
• XO: app.xo.builders