Snapshot and Fork Support Across AI Agent Sandbox Providers

Snapshot and fork support draw the clearest line between sandboxes that look good in a demo and sandboxes that survive contact with a real production agent fleet. This piece maps how the major providers actually implement these two capabilities, where each one's documentation stops short of the claim, and what that gap costs an engineering team that has to build around it.

Snapshot and Fork as Architectural Requirements for Production Agent Workflows

An AI agent, stripped of branding, is a loop: the model decides what to do, code runs, and the result feeds back into the next decision; this cycle repeats. The sandbox is where that middle step, the actual execution, takes place, and it sits directly in the path of every iteration. If the sandbox is slow, the whole loop is slow. If the sandbox forgets everything between calls, the agent has to rebuild its working state from scratch every time it wakes up, and that cost gets paid on every single iteration, not once.

Three primitives let an agent survive that loop without constant manual intervention. Snapshot and restore capture the filesystem and memory of a running sandbox at a specific moment and let a new sandbox boot from that exact point. Fork and branch take a single snapshot and seed several live sandboxes from it at once, so an agent can chase multiple solution paths in parallel instead of serially. Pause and resume suspend one running sandbox and wake it later with its accumulated state intact, rather than discarding it the moment the task goes idle.

Each of these has a direct payoff for teams running agents at scale. Forking lets a team spawn several sandboxes off the same snapshot to try different fixes simultaneously, which is the backbone of reinforcement learning rollouts, SWE-bench evaluations, and any workflow built around testing N candidate solutions at once. Snapshots that cache an expensive setup, say loading a large dataset or spinning up a long-running process, save an agent from repeating that cost on every restart. And a snapshot one user or agent configures interactively can become the starting point for every session after it, so the next agent in the chain doesn't begin from zero.

Teams working with sandbox platforms that lack these primitives, or cap them too tightly, end up writing their own retry logic, their own checkpoint systems, their own state serialization layers just to approximate what snapshot and fork would have given them natively, engineering debt that compounds across every agent in the fleet, every time one of them crashes, times out, or needs to branch into a new approach.

Isolation technology constrains what a snapshot can capture

Before comparing vendors, it helps to understand that a snapshot is only as good as the isolation layer underneath it. Two providers can both advertise "snapshots" while one captures a fraction of what the other does, and the difference traces back to architecture, not marketing copy.

Three isolation designs dominate the current market, and each sets a different ceiling on what a snapshot can hold. Hardened containers give a workload its own filesystem, process tree, and network namespace, but share the host's kernel, so a snapshot can only save disk state; memory disappears the moment the container stops. User-space kernels, the approach gVisor takes, intercept system calls more aggressively than a standard container but still fall short of a full memory snapshot, which makes them a reasonable fit for workloads that don't need to resume mid-thought. MicroVMs and full VMs, the category that includes Firecracker, Kata Containers, Cloud Hypervisor, and Xen, run each workload under its own guest kernel, and that separation is what lets a snapshot capture filesystem, memory, and running processes all together. That's the tier where pause and resume, and fork, stop being theoretical and start being something an agent can actually rely on.

The practical question to ask of any provider is what survives a pause. If the answer is filesystem only, an agent waking from a pause has to restart every process from scratch, reload every model weight, reparse every dataset. If the answer is filesystem plus memory plus running processes, the agent wakes up exactly where it left off, with everything still loaded.

Isolation strength carries a security dimension that providers have started to address directly rather than leave to inference. Edera's own analysis documents a Trail of Bits experiment in which an autonomous agent spent roughly 12 hours trying to research and escape a QEMU/KVM virtual machine, and among the configurations it tested was a Firecracker setup that crashed the host kernel but did not result in an escape. The honest framing for any virtual machine monitor is that it offers a dramatically smaller, better-audited attack surface, not an unbreakable one, and defense in depth still has a place sitting on top of the VM boundary even after that boundary holds.

How the major providers implement snapshot and fork

Morph Cloud built its platform around a feature called Infinibranch, which snapshots an entire running VM and can branch or restore it in under 250 milliseconds, with cold starts also under 250 milliseconds; a September 2026 comparison names SWE-Bench evaluations, RL rollouts, and computer-use agents as its core use cases, and fork reads less like an add-on than the actual product.

PandaStack's copy-on-write forking runs 400–750ms same-host and 1.2–3.5s cross-host, with no session cap. PandaStack's own materials are upfront about the tradeoff: owning the substrate end to end means self-hosting the control plane and the per-host agents yourself.

Runloop is built for enterprise coding agents, running on virtual-machine technology it calls Devboxes, with Blueprints for building reusable environments and snapshots for capturing disk state, plus support for suspend and resume. Its default session cap, per a September 2026 comparison, is one hour, configurable upward, and what survives a pause is disk only.

Northflank runs on a mix of Kata Containers with Cloud Hypervisor, Firecracker, and gVisor, posting a median time-to-interactive around 97 milliseconds (167 milliseconds at burst, ComputeSDK's numbers show), with no cap on maximum session duration. It supports bring-your-own-cloud deployment into AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare metal, without requiring an enterprise sales process. What survives a pause is filesystem state via volumes; memory is not captured.

Edera targets platform engineering and security teams running large Kubernetes or AI infrastructure footprints, whether on-prem, in the public cloud, or at the edge, and exposes an explicit fork(count=N) API. Its own documentation treats snapshot, restore, fork, object capabilities, and workload identity as primitives that standard Kubernetes abstractions struggle to express, and it sits underneath orchestration rather than replacing it. It runs on Xen-based virtualization with an option for KVM without QEMU, a different attack surface than the Firecracker configuration Trail of Bits tested.

OpenComputer, built by Digger, offers full persistent VMs with hibernate and wake, instant checkpoints it describes as snapshot, fork, and rollback, and 20GB of disk per VM. It's listed on the awesome-ai-sandboxes registry as API-based, with bring-your-own-cloud or self-hosting options unspecified.

SmolVM, from Celesto AI, is open source and supports QEMU, Firecracker, and libkrun backends, with snapshots for restoring state and the ability to stop and resume at any point. It has no GPU support in its current release and is built to self-host. An April 2026 community comparison ranked it first on five of six criteria, including snapshotting and fork, though the author disclosed working on SmolVM directly, and the methodology was contested in the discussion thread that followed.

Beam runs on gVisor or runc and supports full memory and disk snapshots alongside distributed volumes, with GPU checkpoint restore and unlimited long-running sessions subject to a configurable auto-shutdown. It doesn't support pause in the sense of suspending execution mid-run, relying on snapshots instead, and the registry lists it under an AGPL 3.0 license.

Vercel Sandbox runs on Firecracker microVMs, auto-snapshotting on stop and auto-resuming on the next call, with a 45-minute session cap on its Hobby tier and a 24-hour cap on Pro, unbounded across sessions. The September 2026 comparison clocked its resume latency at 3,333 milliseconds.

microsandbox uses libkrun microVMs with named sandboxes that follow a start and stop lifecycle, disk snapshots, and sub-100 millisecond boots, with local and cloud sandboxes built to be interoperable 1:1. Its managed cloud offering was in private beta as of the sources reviewed, and the registry confirms fork is not listed among its features.

Resume latency and session caps as the hidden production variables that comparisons tend to bury

Cold-start speed is the number every vendor leads with, but it answers the wrong question for a production agent. The numbers that actually shape how an agent behaves once it's running are resume latency, how long it takes to wake from a pause with state intact, and session caps, how long a sandbox is allowed to live before the platform reclaims it. These two numbers pull against each other depending on what the workload looks like: an agent that needs to pause for hours between steps cares far more about the session cap than the cold-start number, while an agent pausing and resuming constantly within a short window cares more about resume latency than almost anything else.

Session caps vary widely across the field once isolated from marketing pages. Vercel runs a shorter per-session cap on its Hobby tier and a longer one on Pro, though sessions are unbounded across the account as a whole thanks to auto-snapshotting. Other platforms scale session limits upward across plan tiers rather than fixing a single number. A short cap on a free tier, a longer cap once a team is on paid credits, and no cap at all on the top tier is a common shape for this kind of pricing ladder. Northflank, Beam, PandaStack, Freestyle, Morph Cloud, and OpenComputer document no session cap at all. Koyeb is the other extreme: a 24-hour auto-delete maximum after which nothing survives, snapshot or no snapshot.

One might argue that none of this matters much, since any team can engineer around a session cap with its own checkpointing and retry logic layered on top. That's true, and plenty of teams do exactly that. But each of those workarounds is engineering time spent rebuilding a capability the platform could have provided natively, and that cost doesn't show up once. It shows up on every agent in the fleet that hits the cap: the cost of running agents at scale shifts from a line item on the infrastructure bill to a permanent tax on engineering time.

The scheduling problem that fork architecture creates when same-host assumptions break down

Fork numbers look clean in a vendor's own benchmarks because those benchmarks almost always measure forking on a single host. PandaStack's own figures make the gap visible without needing outside commentary: copy-on-write forking runs 400 to 750 milliseconds when the fork stays on the same host, but stretches to 1.2 to 3.5 seconds when it has to cross hosts, not a rounding error.

Why does crossing a host cost so much more than staying on one? A same-host fork can often reuse memory pages and disk blocks already resident on that machine, copying only what changes. A cross-host fork has to move a meaningful slice of that state across the network before the child sandbox can even start running, and network transfer is a different cost category entirely from a local memory copy. Any provider advertising sub-second fork times is implicitly describing a same-host scenario, whether or not the marketing page says so.

This matters more as fleets grow past what a single host can hold. An agent workload running RL rollouts or SWE-bench evaluations at modest scale might comfortably fit its parent snapshot and every forked child on one machine, in which case the fast numbers in a vendor's documentation are the numbers that workload will actually see. But a workload that outgrows a single host, or a platform that schedules across a multi-tenant pool without guaranteeing locality, inherits the cross-host number instead, and that number is the one that should inform any capacity planning done ahead of time.

A provider can implement fork correctly, support memory-and-process snapshots at the microVM tier, and still hand a growing fleet a scheduling problem that only appears once the fleet is too big for one box. Providers that treat stateful execution, capturing filesystem, memory, and process state together, as a first-class design goal rather than a layer bolted onto container infrastructure built for something else are the ones built to keep that promise as the fleet scales rather than only at demo size. Daytona is one provider built around that premise, treating sandbox infrastructure as purpose-built for agent workloads rather than as repurposed container tooling. Whether that holds up for a given team's workload is a question of scale and locality as much as it is a question of which snapshot features a provider lists on its homepage, and it's the question worth asking before, not after, the fleet outgrows a single host.