Seven Agent Sandbox Vendors Shipped Snapshot by June 2026 — What Happens When a Differentiator Becomes Table Stakes

Eighteen months ago, "pause your agent's sandbox and resume it later" was a pitch-deck bullet. By June 2026, E2B, Daytona, Fly Sprites, Vercel, Runloop, Microsandbox, and CodeSandbox all expose some form of sandbox snapshot, pause/resume, hibernate, or suspend primitive in their public docs and SDKs. The feature converged that fast because the economics forced it: an agent that sits idle for forty minutes waiting on a human reply should not burn forty minutes of compute, and resuming should not mean replaying a five-minute clone-install-configure setup sequence.

Here is the verdict up front, for teams building their own sandbox substrate instead of renting one: filesystem-only resume is cheap — a rootfs commit plus an overlay on a fresh pod gets you most of the way there. True memory resume, where running processes wake up exactly where they froze, is the hard part, and on gVisor- or Kata-isolated pods it is very likely the line item your sandbox roadmap has not budgeted for. The rest of this post substantiates that claim: what each vendor's "snapshot" actually preserves, what each shape costs underneath, and where the competition moves now that the checkbox itself is worthless.

One clarification before the table. This post's universe is seven named vendors whose snapshot-class primitives were observable in public docs or SDKs on or before June 2026. Convergence here means convergence on the capability — stop paying for idle, stop replaying setup — not on semantics. What survives a snapshot differs enormously between vendors, and that divergence is the interesting part.

The seven, side by side: what actually survives​

Two things stand out. First, only three of the seven preserve running processes in place. The rest save the disk and reboot the world around it. Second, even vendors outside this list converged: Modal's gVisor-based memory snapshots restore an import torch in about a second instead of five using a FUSE-backed page server. When the vendors you did not count also shipped the feature, it is definitively table stakes.

Three shapes, three cost profiles​

Underneath the seven APIs are three genuinely different mechanisms, and mixing them up is how roadmap estimates go wrong.

Shape 1: hypervisor memory snapshot (E2B, CodeSandbox, Sprites). The sandbox is a Firecracker microVM: pausing dumps CPU registers, memory pages, and device state to disk, and resume maps those pages back and continues executing. This is why E2B can promise that running processes, loaded variables, and open files all survive, and why CodeSandbox's hibernate-then-fork works — a memory image is branchable the same way a disk image is. The cost is snapshot size (memory-sized, gigabytes) and a substrate requirement: you need a microVM to snapshot. Fly's own Machines documentation puts Firecracker-snapshot resume at a few hundred milliseconds, which sets the bar for this shape.

Shape 2: filesystem-only snapshot (Vercel). The sandbox stops, its filesystem is committed, and resume boots a fresh environment with the saved files. Nothing in RAM survives. This is dramatically cheaper to store and simpler to implement — it is a container-image commit by another name — at the price of reboot semantics: daemons restart, in-memory caches are cold, and anything that lived only in a process is gone. For agents whose state is "files on disk plus a transcript the orchestrator holds anyway," this is often sufficient, which is why Vercel can make it the default without controversy.

Shape 3: disk snapshot restored as a new sandbox (Runloop, Daytona, Microsandbox). The snapshot is a baseline image, and "resume" provisions a fresh sandbox from it rather than reviving the old one in place. Daytona's docs make the split explicit: memory-inclusive pause exists, but only for VM-class sandboxes; the container class and the snapshot primitive follow restore-as-new. The superpower of this shape is branching — Runloop's own SDK examples restore two independent devboxes from one snapshot and mutate the same file differently in each. The price is that identity does not survive: new sandbox ID, new network attachment, cold processes.

What breaks in every shape deserves its own paragraph, because vendors document the happy path. Open network connections do not survive any of these — TCP state is not part of a disk image and barely part of a memory image once the other end has timed out. GPU state is its own saga: CRIU only grew GPU support via CRIUgpu in CRIU 4.0, and hypervisor snapshots of GPU-backed VMs remain vendor-sensitive. And every memory-preserving shape assumes restore happens on compatible kernels and CPU features; live-migrating a memory image across heterogeneous hosts is a research project, not a feature flag.

The self-hosted build, priced honestly​

Now the question from the verdict: you run a Cluster-API-managed fleet on machines you own, your sandbox primitive is gVisor- or Kata-isolated pods, and you want E2B-style session resume. What do you get for free?

Filesystem-only resume: nearly free. The pattern is a rootfs commit to an OCI artifact on pause and a layer overlay on a fresh pod at resume — the same shape the Kubernetes BatchSandbox-style designs use, and roughly what every Shape 2 and Shape 3 vendor does. Object storage holds the deltas, the orchestrator holds session identity, and resume latency is dominated by image pull, which you already optimize for normal deploys. If your agents keep their state in files and transcripts, stop here. This is a weeks-long project, not a research program.

True memory resume: the hard part, three times over. Start with CRIU, the user-space checkpoint/restore tool that can freeze a running process tree and reanimate it later. CRIU demands kernel support (CONFIG_CHECKPOINT_RESTORE), identical libraries and filesystem mounts at restore time, and it gives up gracefully-or-not on external dependencies like database sessions and locked files. Kubernetes has been productizing this via the kubelet ContainerCheckpoint API, which reached beta in 1.30 — but it is a kubelet-local API with runtime-specific support matrices, GPU support is young, and the project's dedicated Checkpoint/Restore Working Group only formed in January 2026. Betting a production SLA on it today means tracking an alpha-to-beta surface across every node image you ship.

Then comes the isolation catch, and it is structural. Host-side CRIU operates on host processes. A Kata pod's workload runs inside a guest kernel in a microVM — host CRIU sees the hypervisor process, not the agent's processes, so it cannot capture in-VM application state. You would need guest-cooperative checkpointing (CRIU inside the guest, orchestrated across the fleet) or hypervisor-level snapshots (Firecracker snapshot/restore driven by your own controller, storage for gigabyte memory images, placement constraints so the snapshot restores on a compatible host). gVisor's story is no simpler: its user-space kernel interposes on syscalls in ways that make transparent checkpoint/restore a special project rather than a flag. Either path converts "session resume" from a storage feature into a virtualization-control-plane feature.

So the honest pricing is: FS-only resume costs an OCI pipeline you probably already have; memory resume on isolated pods costs a snapshot controller, a memory-image store, compatible-host scheduling, and ongoing maintenance against CRIU and kubelet beta APIs. The seven vendors above already paid that second bill — in E2B's and CodeSandbox's case, by building on Firecracker from day one so the hypervisor snapshot was always available. If your sandbox roadmap assumed resume would fall out of "we run containers, CRIU exists," that assumption is the gap. Budget the hypervisor path or scope v1 to filesystem-only and say so explicitly.

What the differentiator becomes now​

When every vendor has the checkbox, competition moves to the fine print. Three axes are already visible.

Branching. Runloop restoring N devboxes from one baseline and CodeSandbox forking a hibernated sandbox in under two seconds point at the same future: snapshots as version control for agent state. A/B-test two agent strategies from the identical frozen moment; fork a failing session to debug it without disturbing the original. Nobody prices "snapshot fan-out" well yet, which is exactly why it is the next battleground.

Resume latency and granularity. The spread between a few hundred milliseconds (Firecracker restore) and a container cold start plus setup replay is the user-visible gap, and vendors are compressing it from both ends — memory snapshots for instant wake, lazily-loaded page servers (Modal's FUSE approach) for cheap-but-fast. Expect SLAs on resume time the way cold-start SLAs exist today.

Retention economics. E2B keeps paused sandboxes indefinitely with no TTL; Daytona auto-stops containers after 15 idle minutes. Those are opposite answers to "who pays for frozen state," and as agent fleets grow, the storage-versus-compute tradeoff of a million paused sessions becomes a first-order cost line. Watch for tiered retention — hot resume for hours, cold archival beyond — to become the standard price-discriminating feature.

The pattern is familiar from every infrastructure cycle: a capability goes from differentiator to expectation in under two years, and the vendors who built it on the right substrate (microVM snapshots, branchable images) inherit the next competition for free while everyone else rewrites. Eighteen months ago snapshot was the pitch. Today it is the admission ticket. Tomorrow it is a version-control system for running agents — and the only question is whose substrate already supports that.

Building agent infrastructure on machines you own? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on hardware you control, with agent-operable APIs from day one. Star the repo on GitHub or deploy your first app today.