Snapshot and Restore Scheduling for Idle AI Agents

Snapshot-restore scheduling for idle AI agents replaces a permanent compute reservation with stored state between tasks. It freezes an agent’s working environment, releases active resources, and restores that environment when work resumes. This makes per-user agents economically viable only when restores are fast enough and the scheduler saves more on idle compute than it spends on capture and restore.

Why persistent agents cannot stay resident when idle

A resident VM waiting for a human approval continues to consume compute budget even though its agent has nothing to execute. The same wait can occur while an API responds or a long downstream job completes. These pauses are part of the workload. They are not necessarily evidence of poor agent design, and making tool execution faster does not eliminate the intervals between tasks.

Rethinking AI Cloud Infrastructure for Agentic Serving Systems with the Aries Experimentation Framework finds that tool sandboxes alternate between long idle periods and short resource bursts. Static peak provisioning avoids throttling those bursts but leaves resources stranded for a significant portion of the time. Per-user deployment makes this mismatch especially costly. Most agents in such a fleet are doing nothing most of the time, yet permanent residency reserves capacity for each of them, making idle reservation the default operating condition.

The false choice current systems force on developers

Tearing down a sandbox after every tool call appears to remove the waste directly. No resident sandbox means no idle compute charge. But keeping state across those teardowns takes repeated snapshot capture and restore, so the money saved on residency goes back into state-management overhead. The Aries paper finds that this approach cuts sandbox cost sharply but raises total customer cost well above the persistent baseline. Optimizing the sandbox bill alone produces the wrong answer.

Keeping the VM resident avoids those repeated transitions, but restores the idle reservation that motivated teardown in the first place. Neither extreme resolves the workload’s changing resource needs. Residency works well for a short wait before another tool burst, while suspension works well for a long wait with no work to do. The distinction between them must become a scheduling decision.

The Aries paper describes an ideal system that could reduce total cost by 3× compared with the persistent-sandbox baseline. Achieving that design goal requires deciding when retaining an environment is cheaper than freezing and later restoring it. The mechanism alone cannot make that decision. Snapshot-restore becomes economically useful when a scheduler places the transitions around the workload rather than triggering them indiscriminately after every invocation.

What snapshot-restore actually does at the infrastructure level

Snapshot-restore freezes a running microVM’s state to disk and revives it from that state on demand. The captured state includes guest RAM and emulated hardware state, including vCPU registers, device state, the interrupt controller, and the clock. This is more than a saved conversation. It preserves the execution environment in which the agent’s processes, loaded credentials, and unfinished work reside, allowing execution to continue from the point of suspension.

Firecracker’s snapshot documentation distinguishes guest memory from emulated hardware state. Open files and running processes survive through the guest-kernel data structures held in RAM, rather than through separate application-level exports of each item. The distinction explains the scope of continuity. The infrastructure preserves the environment that contains the agent’s work instead of requiring application code to describe and reconstruct every part of it. Keeping the disk state as well means the restored environment can skip installation and setup that have already been done.

Firecracker uses one virtual machine monitor process for each microVM, which boots quickly and has little memory overhead. For restoration, however, boot has already happened. Loading the frozen state skips that sequence entirely. Restore can therefore be useful between periods of agent activity. A warm environment can also become a repeatable starting point. Heavy packages and toolchains can be installed once, then restored from a known-good snapshot on subsequent invocations.

Copy-on-write, or COW, forking extends that starting point into multiple concurrent continuations. Project Lunchbox describes forking a live agent’s memory and disk into divergent trajectories while creating private copies only for pages that diverge. The shared base memory is not duplicated. Lunchbox identifies warm snapshots and forking as building blocks for production agent fleets and reinforcement learning evaluation environments.

Why sub-second restore latency is the linchpin of the whole model

A scheduler can release resources during a wait only if bringing them back does not impose an unacceptable delay or erase the savings. Restore latency therefore governs whether suspension is practical. If every wake takes seconds, the system must either expose that delay to users or maintain a pre-warmed pool of resident VMs. The first choice makes waking an agent visibly disruptive. The second brings idle compute expenditure back into the design.

Firecracker enables frozen-state restoration in tens of milliseconds because the restore skips the boot sequence. That figure illustrates the relevant mechanism. The scheduler needs the actual restore time of its underlying substrate. A fast restore operation creates room to suspend during shorter idle periods, whereas a slower one restricts suspension to longer waits if the transition is to remain worthwhile.

The distinction is whether an agent can sleep between tasks without turning each return to work into a cold-start experience. Google’s Agent Compute Engine design, announced October 22, 2026, uses fast checkpoint and restore to pause idle microVMs and release active compute resources to other active agents. Its resource-reallocation mechanism connects wake speed directly to the ability to stop reserving capacity during inactivity.

Latency still cannot determine the suspension threshold alone. Capture and restore also impose costs that must be recovered during the idle interval. Shorter thresholds demand faster restores, but even a fast restore may be uneconomical when the next task follows almost immediately. Above that threshold, suspension can save more on idle compute than it costs to wake the agent.

What the scheduler must get right to avoid eating the savings

The suspension threshold is the scheduler’s central tuning variable. It determines how long an idle agent remains resident before the system freezes it. When the threshold is too short, repeated capture and restore cost the most. When it is too long, idle compute costs the most. The Aries paper documents a 4.9× cost amplification at short keepalive timeouts, where frequent state-management operations more than offset the savings from suspension. Aggressive eviction is not inherently efficient.

Workload phase gives that threshold its context. Agent sandboxes can remain idle during LLM inference and then need short CPU and memory bursts for tool execution. A scheduler needs visibility into that alternation before deciding whether inactivity signals an opportunity to suspend or a brief gap before more work.

A full snapshot writes all guest memory regardless of how little has changed since the previous capture. With dirty-page tracking enabled, a diff snapshot writes only the pages dirtied since the preceding snapshot, so its write cost depends on accumulated changes. Taking captures more often can therefore leave fewer dirty pages in each capture. That favors shorter capture intervals at the level of each diff write, but does not establish that more frequent suspension lowers total cost.

Capture also has to preserve state without corrupting the running agent. The relevant comparison includes the cost of writing state and restoring it, as well as the residency avoided during the resulting sleep. This explains why neither snapshot size nor restore latency is sufficient on its own. Both contribute to a transition whose value depends on how much inactivity follows it.

A server can host more microVMs than their configured allocations would suggest because most agents use only a fraction of those allocations at a given time. Simultaneous wakes can invalidate that assumption. A sufficiently large burst can trigger the Linux OOM killer, so economical suspension does not remove the need for memory headroom when agents resume.

Scheduler calibration should use measured idle-time distributions. If traces show an agent class typically waiting minutes for its next message, a lower threshold can release resources during that wait. If agents usually resume within seconds, keeping the VM resident saves the work of freezing and restoring it. These decisions must fit the host’s wake capacity as well as the individual agent’s behavior.

How do you stop paying for compute while your AI agents are idle?

Under a pay-for-storage model, a suspended agent accumulates storage cost while compute charges apply during its active windows. Storage is the cheaper resource in this comparison. An agent that spends most of its time asleep therefore costs less to retain than an agent that reserves a resident VM throughout those waits. The ratio of idle time to active time determines the opportunity for savings, while capture and restore overhead determine how much of that opportunity remains.

This changes the economics of assigning an isolated agent to each user. Enrollment no longer requires a matching fleet of continuously running VMs, because most environments can exist as stored snapshots until their users need them. Stored state still grows with the fleet, so persistence is not free, but adding an infrequently active user does not require another permanent compute reservation. That difference makes the per-user pattern viable at product scale.

Fleet sizing then becomes a question of concurrent demand. The operative constraint shifts from how many VMs can remain running within budget to how many simultaneous wakes the scheduler can safely accommodate within each host’s memory headroom. A large sleeping population can therefore be economical while still requiring careful scheduling when activity arrives in bursts.

Agent Compute Engine reflects this economic logic by allowing idle microVMs to pause so customers do not pay for idle VM compute. Its billing mechanics have not yet been detailed. That limits what can be concluded about its specific storage charges or total customer bill. The architectural capability to release active resources and the commercial promise of storage-only idle billing are related, but they are not interchangeable claims.

What persistent state across sessions makes possible that stateless approaches cannot

A stateless function restarted between sessions does not retain its working environment by itself. Files, installed packages, loaded credentials, and partial results must be reconstructed or stored externally and re-injected. Snapshot restoration preserves that environment instead. Its value is not merely avoiding setup time, because the saved state also includes the unfinished execution that gives a long-running agent continuity across separate periods of activity.

A restored agent resumes with its kernel state intact, its disk as it was, and its in-flight processes able to continue. That enables tasks spanning hours or days without requiring application code to implement manual checkpointing of the whole working environment. Human approval is a particularly clear case. The agent can remain suspended while a person reviews a draft or authorizes an action, then resume with its context and partial work preserved. Lunchbox names these long waits for people to respond as a main use case.

COW forking adds a different form of continuity. Instead of resuming only one trajectory, the infrastructure can branch from a shared execution state into multiple parallel continuations. Multi-step planning, reinforcement learning evaluation, and agentic debugging can use those continuations without reconstructing each environment from stateless inputs. The isolation boundary remains the individual microVM. Each agent has its own kernel, keeping one agent’s disk and memory separate from another’s even when both resume on the same host.

Snapshot-restore is therefore more than a cheaper way to wait. When fast restoration and workload-aware scheduling work together, an agent can keep its state without staying resident. An agent can retain unfinished work, sleep through an extended pause, and return as the same execution environment.