Why pause beats reboot

Give an AI agent its own computer and watch what it does with it. It clones a repository, installs dependencies, runs the tests, starts a dev server, and then waits. It waits for the model to think, for the user to reply, for the user to come back from lunch, for the user to come back tomorrow. In the agent products we have looked at, the machine sits idle for most of the day. We assume 70–90% idle time for a typical per-user VM, and we are validating that number with beta teams.

That idle time is where most of the bill goes. This post explains why, and why the fix is not just "stop the VM", but pausing it with its memory intact.

The arithmetic of idle machines

Take one VM with 4 vCPU and 8 GB of RAM, active 10% of the time: about 73 of the 730 hours in a month.

• If the VM runs the whole month, you pay for 730 hours. At our $0.030 per hour that would be $21.90 per month, of which $19.71 buys nothing but waiting.
• If you pay only for active time, you pay for 73 hours. At our planned $0.030 per hour that is $2.19 per month.

Multiply by a thousand users and the difference is about $19,700 every month. Cheaper hardware does not close that gap. The only thing that closes it is not running the machine when nobody needs it.

Most platforms already know this. The interesting question is what happens when the user comes back.

Option 1: keep it running

The simplest approach is to never stop. The user's environment is always exactly as they left it, and you pay for every hour. For a handful of VMs that is fine. We even sell it: an Always-on default VM costs a flat $19.90 per month. For a platform with thousands of mostly idle users, it means paying for 100% of the time to use 10% of it.

Option 2: stop it, keep the disk

The next approach is to shut the VM down when idle and keep its disk, often with a disk snapshot. Billing stops, the files survive, and everyone is happy until the user returns.

A disk snapshot captures the filesystem and nothing else. Everything that lived in memory is gone:

• The kernel boots again, systemd starts every unit again, Docker restarts its containers.
• The dev server the agent started is not running. The language server has to re-index. Build caches in memory are cold.
• The shell session, its environment variables and its history in the current terminal are gone.
• On a desktop VM, every window is closed. The browser the agent was driving has lost its tabs, and whatever was not persisted to disk (form state, an unsaved editor buffer) is lost.

Booting a lean VM can be fast, but getting back to the working state is slow: seconds for simple setups, a minute or more when the agent had several services running. Worse, the agent has to notice that its world was reset and redo work, which costs model tokens as well as time.

Option 3: pause it, keep the memory

A pause takes a snapshot of the whole machine: guest memory, vCPU registers and device state, plus the disk. Firecracker, the VMM that runs every Dormo sandbox, supports this natively. It is the same mechanism AWS uses for Lambda SnapStart.

Here is what happens on our side when a VM pauses:

1. No exec, no inbound traffic and no desktop viewers for 5 minutes (configurable), or an explicit pause() call.
2. The VM's vCPUs are stopped and Firecracker writes memory and device state to a snapshot file next to the disk.
3. The Firecracker process exits. The CPU and RAM go back to the pool, and compute billing stops.

When an HTTP request, SSH connection or API call arrives for that VM, our gateway holds it, a new Firecracker process restores the snapshot, and the request goes through. Memory does not need to be copied back up front: pages can be mapped and loaded lazily as the guest touches them, which is why restore is fast even for large VMs. Our target is p95 under 800 ms from request to running VM.

From inside the VM, nothing happened except a jump in the clock. Same processes, same PIDs, same open sockets on localhost, same terminal, same browser tabs.

	Always on	Stop + disk snapshot	Pause + RAM snapshot
Compute billed while idle	Yes	No	No
Files survive	Yes	Yes	Yes
Processes & windows survive	Yes	No	Yes
Back to working state	Instant	Reboot + warm-up	< 1 s (target)

The fine print

RAM snapshots are not free of trade-offs, and we would rather you hear them from us:

• Storage. A snapshot contains the memory the guest has used. A desktop VM with a browser open typically uses 1–3 GB. We store snapshots of paused VMs free for 30 days, then charge $0.03 per GB per month. A 3 GB snapshot costs $0.09 a month after the free period.
• External connections. While the VM is paused, the outside world keeps moving. A long-lived TCP connection to a remote database may time out, so clients should reconnect, which well-behaved ones already do.
• Clocks. The guest's wall clock jumps forward on resume. Software that measures elapsed time with the wall clock may be surprised, and timers that were due during the pause fire immediately.
• Forks share state. When you fork a running VM, both copies start with identical memory, including random-number state. Anything that must be unique per copy, like generated IDs or keys, should be created after the fork.

Why this matters for agents specifically

Human developers tolerate a reboot in the morning. Agents are different in two ways. First, they come and go constantly. A coding agent might be active for two minutes, idle for twenty, active again for five. Without automatic pausing, every one of those gaps is billed. Without RAM snapshots, every one of those returns is a cold start. Second, an agent's context is expensive. Rebuilding a working state means extra tool calls and extra tokens, on top of the wait.

Auto-pause after a few idle minutes, wake on the next request, and resume the exact machine in under a second. With all three, a platform can give every user a real computer and pay roughly for the time those computers are actually working.

That is what we are building with Dormo. We are in private beta, starting with teams that run a VM per user. If that sounds like your bill, start on the free plan or plug your own numbers into the calculator.

Price sources: boat.dev list price for 4 vCPU / 8 GB per battleships.dev, October 2026. Dormo prices are planned beta prices.