Agent economics: the sandbox chapter

Storage-backed sandboxes save you twice: on idle, and on work you never redo.

TL;DR

• A lot of your agent bill is waiting. Agents spend far more time waiting on models, tools and people than doing work. Sandboxes bill wall-clock time, so you pay for all of it.
• You can kill the meter, but only round trips<wait. Handing the machine back and getting one again costs time. If the wait is shorter than that round trip, releasing loses you money, so the machine stays up and bills through it.
• The round trip is the number nobody publishes. Every provider advertises a boot time. Almost none publish release plus resume because almost every sandbox is RAM back i.e no real pause, but snapshots + teardown.
• Most sandboxes are compute plus RAM, not compute plus storage. Machines get reclaimed, preempted and evicted constantly, by design. When the work lives in memory, it dies with the machine.
• So you pay twice. Once for idle you could not reclaim, once to redo work you already bought. Both come down to the same two things: where the work lives, and how fast you can let go of the machine holding it.
• Fast disks. Persistent workspaces. Isolated sandboxes. And you pay for the work once. Run your agents on Nirvana.

Agents work in a sandbox

Think of an AI agent as a very fast intern. Capable, tireless, and not someone you can trust 100% in production.

So you give it a room of its own. That room is a sandbox: an isolated compute environment where the agent can install packages, run code, break things, and none of it touches anything that matters.

Almost every sandbox on the market today is the same shape: a machine with compute and RAM. Hold onto that, because it is where the bill comes from.

What an agent actually does in there

The agent does a lot of things in the sandbox: it reads files. It clones a repo. It installs dependencies. It runs a test suite. It writes notes to itself so it can pick up its own thread later. Those notes are checkpoints, and a busy agent writes them constantly.

And in between all of that, it waits.

• Waiting for the model to answer. A standard call takes two to five seconds. A reasoning model takes five to sixty.
• Waiting for a tool. A web search, an API, a database query, a test suite finishing.
• Waiting for human. Approving a pull request, signing off on a spend, answering a question the agent got stuck on. Minutes, sometimes hours.

There is a lot of wait, and the compute meter runs through every second of it.

And it is unusually hard to see. Nothing errors. Every job finishes. Nobody gets paged. The bill just looks like you are using more.

You can stop the meter. Sometimes.

The obvious fix is to hand the machine back during a wait and take a new one when the agent is ready again. It works, but leaving and returning costs time. You have to save the work, release the machine, then bring one back and get the agent going again. Call all of that the round trip.

Which gives you a simple rule:

Release the machine only if the wait is longer than the round trip.

If your round trip is ten seconds, a fifteen-second wait is worth reclaiming and a five-second wait is not. If your round trip is twenty-one seconds, that fifteen-second wait is now a loss, so you keep the machine and eat the cost.

The average round trip time

So the round trip is snapshot plus release plus boot. We publish ours, Quirq measured it alongside GKE, and for everyone else we went to their docs. Here is how it comes out:

• E2B, RAM-backed, from their docs. Pause is about 4 seconds per GiB of RAM, resume about 1 second. A 2 GiB sandbox round-trips in about 9 seconds, 8 GiB in about 33 seconds. It grows with the agent's state.
• GKE, storage-backed, measured. 9.57 seconds to release, around 12 to resume. About 21 seconds, fixed, and the lifecycle glue between pod and volume is yours to build.
• Nirvana, storage-backed, measured. 1.46 seconds to release, 8.9 to resume. About 10 seconds, fixed, whatever size the workspace is.
• Daytona, Vercel, Blaxel, RAM-backed, from their docs. Each publishes a resume time (seconds, under 1 s, under 25 ms) and none publish the pause or snapshot half, so the round trip cannot be computed.

But...machines die a lot

Not occasionally. Constantly, and by design. An autoscaler reclaims an underused node. A spot instance gets preempted. A pod gets evicted for a higher-priority workload. None of these are failures. This is cloud infrastructure working as intended, and it happens mid-task all the time.

When the work was on a volume, the question becomes how fast a replacement machine picks it up. In Quirq's build test, a Nirvana agent was back at work about 10 seconds after each destruction. On GKE it took around 35, because the pod has to be rebuilt and the workspace bootstrapped before the volume is useful again. Same durable disk, three and a half times the wait.

So you pay twice

You pay for waiting you could not reclaim. The gaps were shorter than your platform's round trip, so the machine stayed up and billed through every one of them.

You pay to redo work you already done but lost in RAM. The compute that produced the lost files is spent. Now you buy it again.

Both halves come from the same place: where the agent's work lives, and how quickly you can let go of the machine holding it. Put the work on a disk that outlives the machine and the second bill disappears. Make that disk fast and the first bill shrinks too, because there is nothing to copy before you let go, so most of your agent's idle becomes short enough to reclaim.

That is the argument in one line: cheap agents need fast disks.

Persistent agents are the default now

Agents that hold context across sessions, run for hours and checkpoint constantly are not the future. They are what people are building today. Every one of those behaviours is a write, and reasoning models are only making the waits longer and the state bigger.

If you are serious about running them, use Nirvana Persistent Agent Sandboxes. The workspace lives on ABS and outlives the machine, so nothing gets redone. The round trip is about 10 seconds, fixed, so idle can actually be reclaimed. fsync returns in 1.65 ms after a real flush, so a commit means something. And the disk holds 2.71 GiB/s for thirty minutes, not thirty seconds.

Fast disks. Persistent workspaces. Isolated sandboxes. And you pay for the work once. Run your agents on Nirvana.

Start with Nirvana Persistent Agent Sandboxes → ·
Talk to us →

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more at Nirvana Labs

Nirvana Cloud | Pricing | Blog | Docs | Changelog | LinkedIn | Twitter | Telegram | YouTube