Snapshot and Restore Scheduling for Idle AI Agents

Snapshot-restore scheduling exists because agent workloads do not act like the applications that cloud billing was built for. An AI agent sits idle for most of its life and then, for a few seconds at a time, pulls hard on CPU and memory while it runs a tool call, parses a response, or writes to a filesystem. That alternation between long quiet stretches and short bursts is structural, and it is what cloud compute pricing is bad at accommodating.

The Aries research paper, from a group spanning NTU Singapore, AWS, Microsoft, AMD, Ant Group, Imperial College London, and the University of Edinburgh, characterizes tool sandboxes this way directly: they alternate between long idle periods and short resource bursts, and the pattern holds up against production traces pulled from a commercial agent platform. Harness and tool execution, the paper finds, can account for up to roughly half of end-to-end latency in an agent's task, so the gaps where nothing is happening on the compute side are large and frequent enough to dominate the economics of running the fleet.

Standard cloud billing charges you for a provisioned slot whether or not anything is running inside it. Capacity sits stranded, paid for and unused, and that multiplies across every agent in a fleet.

The obvious fix, tearing the sandbox down the moment it goes idle and rebuilding it when work resumes, turns out to create a worse problem than the one it solves. Aries tested exactly this: tearing down tool sandboxes after each tool call cut instance cost by 65 percent, but the repeated cycle of snapshot capture and restore pushed total customer cost to several times the cost of keeping a sandbox alive persistently. Neither resolves the underlying mismatch between how agents actually spend their time and how infrastructure charges for it.

What snapshot-restore scheduling does, and how it differs from naive teardown

Snapshot-restore scheduling breaks that false choice by decoupling when an agent stops costing money from when it loses its state.

The mechanism depends on what a microVM snapshot actually captures. A coding agent that pauses mid-task on a Tuesday and wakes on a Wednesday finds its environment exactly as it left it, with no reinstallation and no rebuilding.

This differs from naive teardown in a way that matters enormously for cost. That rebuild cost is the larger share of the expense in the Aries findings. Scheduling-based suspension, by contrast, holds a complete state snapshot and restores it once, at the next meaningful event, rather than capturing and restoring at every tool-call boundary. Paying a rebuild tax dozens of times a day costs far more than paying it never, because there is nothing to rebuild.

Maritime's snapshot-restore scheduler was purpose-built to resolve this false choice: by pausing idle agents and charging for storage instead of live compute, it removes the cost penalty attached to either keeping sandboxes alive indefinitely or tearing them down repeatedly. Aries frames the target state for this whole category of system as a roughly threefold reduction in total cost relative to a persistent-sandbox baseline, and the paper is explicit that no production system has reached that ideal yet. That gap defines the engineering work still ahead.

Correctness problems introduced by snapshot-restore

Freezing and restoring a virtual machine is a well-understood operation at the hypervisor level, but an agent that does not know it has been restored will behave incorrectly, and the signals a developer would reach for first are precisely the ones that fail silently.

Restore detection has to come from a signal maintained outside the snapshot boundary. VMGenID, an afterRestore hook, or a host-updated restore token all work because the host updates them on every restore, so the guest has something external to compare against. The concrete failure is stark: an unnotified clone reproduces identical random streams, so two separate agent instances can generate the same "random" output from the same seed state, a correctness bug that can propagate into anything downstream that assumes uniqueness.

Network state introduces a second hazard. If a restore contract only accounts for memory and filesystem state and skips connection revalidation, it will hand the agent dead sockets and call the restore successful.

A third hazard involves side effects whose outcome was never recorded. A request accepted just before suspension, with no durable record of whether it completed, is genuinely ambiguous after restore, and replaying it blindly risks duplicating an action that already happened. Reconciliation, idempotency checks, and credential or lease revalidation all still have to run after every restore, regardless of how clean the underlying snapshot mechanism is.

None of these failure modes argue against the model. They argue for building a deliberate restore contract into it. Edera's Project Lunchbox treats this as a first-class engineering concern rather than an afterthought, exposing isolation, snapshotting, forking, and capabilities as explicit SDK and Kubernetes-native primitives, with the runtime handling the implementation while the application layer retains control over when and how restore signals get handled. Platforms like Maritime that run snapshot-restore scheduling in production have to enforce the same discipline: VMGenID invalidation, socket state handling, and clone-detection safeguards belong in the infrastructure itself, not left as an optional concern for whoever builds on top of it. Getting these details right, rather than treating the snapshot as a magic checkpoint, is what separates a restore contract that holds up in production from one that only works in a demo.

Firecracker on Bare Metal as the Infrastructure Layer That Makes This Scheduling Model Work

None of the scheduling logic described above is useful if the underlying infrastructure cannot snapshot and restore fast enough to make suspension invisible to the user. Sub-second restore latency, strong per-agent isolation, and direct hardware access are the three conditions that make aggressive suspension viable, and Firecracker running on bare metal is the combination that satisfies all three where most alternatives fall short on at least one.

Firecracker was built by AWS specifically to run many isolated, short-lived workloads with minimal overhead, and its isolation model gives each agent its own kernel. The implementation itself is deliberately minimal, roughly 50,000 lines of Rust covering exactly five virtio devices, a footprint small enough to keep both the attack surface and the boot time well below what a general-purpose hypervisor carries. Firecracker boots in roughly 125 milliseconds with very low per-VM memory overhead, and a well-provisioned server can bring up many fresh microVMs per second from a cold start, or restore from a warm snapshot considerably faster than that.

Bare metal is not a preference in this architecture, it is a requirement. Firecracker needs direct KVM access, and cloud VMs running nested virtualization add meaningful per-operation overhead, weaken isolation guarantees, and block PCIe passthrough. Any agent sandbox that needs a GPU has to run on bare metal for that reason alone, since nested virtualization removes the passthrough path a GPU workload depends on.

Production systems are converging on this pattern independently. Edera's Project Lunchbox brings snapshotting and copy-on-write live forking to Kubernetes clusters that operators already control, exposing them as developer primitives. Kubernetes itself is moving in this direction too: version 1.37 adds pod-level checkpoint and restore as an alpha feature, leaving the implementation to the container runtime and still lacking higher-level agent primitives, a sign that the ecosystem recognizes the pattern even though it has not standardized around it yet.

Edera's forking capability extends the model past simple pause-and-resume. Rather than booting ten fresh environments from scratch, the live state of one running agent can be cloned into ten divergent instances through copy-on-write, where only the memory pages that actually diverge require private copies, so cost scales with how much the instances differ. Maritime implements the core of this pattern on Firecracker microVMs running on bare metal, capturing full guest memory and disk state so an agent resumes from the exact instruction it paused on, with repositories, dependencies, and build caches all intact on wake and no rebuild overhead left over from the suspension.

The open problem at the GPU boundary: restore latency for large-model agent sandboxes

The snapshot-restore model holds up well for CPU-bound and I/O-bound agents, but GPU-backed sandboxes running large model checkpoints expose a restore-latency problem that the CPU-side mechanism does not solve. This is the honest limit of where the technology currently stands.

Beyond raw latency, repeated checkpoint-and-restore cycles for GPU containers run into structural complications. CUDA PID mapping currently assumes exactly two PID-namespace levels, a known implementation gap that is under active remediation, and a restored container ends up containing both an idle placeholder and the restored workload. Subsequent captures have to correctly identify the real workload process tree without snagging the placeholder along with it. A full repeated cycle (capture A, restore as B, capture B, restore as C) remains unproven in integration testing as of the current open issue tracking this work.

Prototype research points toward sub-millisecond restores on the CPU side using copy-on-write Firecracker snapshots, but that result is not yet production-proven, and the GPU path has nothing comparable yet. The practical guidance for anyone designing around this today is straightforward: the snapshot-restore model works well now for CPU-bound and I/O-bound agents, coding assistants, browser agents, and data pipeline runners among them, while GPU-backed agents carrying large model state face restore latency that currently undermines the economic case for suspending them aggressively. That gap is an active area of engineering work, not a reason to avoid the model where it already works.

The economics of per-user agent deployment under snapshot-restore scheduling

The technical mechanism matters because of what it unlocks economically: giving every end user a persistent, dedicated agent stops being prohibitively expensive once idle agents pay for storage rather than live compute. That shift is what makes the per-user agent pattern viable at scale, rather than a pattern reserved for a handful of premium accounts.

The underlying math follows directly from the workload characterization established earlier. Maritime's scheduling model is built directly on this insight: a snapshot-and-restore scheduler lets users pay for storage instead of idle compute, which is what makes it economically viable to give every end user a persistent agent at roughly a dollar per agent per month at scale, with lower usage tiers starting at $1.50 per extra agent per month.

The per-user agent is becoming the right primitive for a new category of software, and pricing has to catch up to it. In any multi-tenant fleet, you still have to enforce per-tenant resource budgets before dispatching work, because a small fraction of heavy users in agent-driven products can consume a disproportionate share of inference capacity, and if a flat pricing structure ignores that concentration, it creates real financial exposure at scale.

The build-versus-rent decision for fleet operators follows a curve you can predict. Snapshot-restore scheduling on a managed platform, where a provider amortizes idle hardware across many tenants at once, resolves that calculation for teams that have not yet reached the scale where owning the infrastructure outright pays for itself.

Building a production agent fleet on top of this scheduling model

A production fleet built on snapshot-restore scheduling treats the snapshot as the agent's primary state artifact, the object that defines its identity and continuity across sessions, not as a backup copy kept around for safety. Everything discussed above, the workload mismatch, the restore mechanism, the correctness hazards, and the infrastructure it runs on, converges into a set of concrete design decisions at this layer.

The canonical architecture runs one microVM per session per user, so you get tenant isolation by construction, but you still have to pair that isolation with state management discipline above the VM boundary. Episodic memory, the capability to capture specific events with full temporal and contextual detail attached, remains handled only at a basic level across most production frameworks today, so teams building agents meant to persist over long periods should plan for that gap and assume it is unsolved.

Every deployment needs a documented restore contract covering three things: what signal triggers restore detection (a host-updated token, VMGenID, or an afterRestore hook), what connections get revalidated on wake, and what side effects get checked for idempotency before anything is replayed. A fleet with that contract wakes agents correctly every time; without it, a fleet can silently produce incorrect behavior after a subset of resumes, often in ways that are hard to trace back to the restore itself.

The developer-facing surface should hide the virtualization details underneath it. Cloudflare Containers' durable_object scheduling policy follows a similar philosophy, letting application code choose each sandbox's image and instance type at runtime, starting containers roughly six times faster with a 648 millisecond median, and restoring filesystem snapshots so the workspace itself functions as a first-class runtime artifact. Maritime's approach follows the same principle at the deployment level: a single push from code to a live API endpoint, with snapshot-and-restore scheduling handling idle cost automatically in the background, reflecting the idea that infrastructure overhead should not be something a developer has to manage by hand.

The right threshold for how aggressively to suspend depends on restore latency and workload type. Aggressive suspension, pausing after every tool call, only earns its keep when restore happens fast enough that a user never notices the gap, which in practice means sub-second wakes. GPU-backed agents carrying large model state should not be suspended aggressively today, given the restore latency documented in the GLM benchmark above. CPU-bound and I/O-bound agents, coding assistants, browser agents, and data pipeline runners among them, are where this model already delivers on its promise.

The Aries paper's own benchmark leaves the field a clear target: a system that reduces total cost by roughly three times relative to a persistent-sandbox baseline, a target the paper states does not yet exist in any production system. Closing that gap, not proving the concept works, is the engineering agenda in front of the field now.