Sandbox Snapshot and Resume for Long-Running Agents

Long-running AI agents fail for a reason that has nothing to do with model quality. Their sandboxes, the isolated compute environments where they run code, install packages, and touch the filesystem, were built to be thrown away after one shot. That mismatch between agents that need to work across dozens of turns and infrastructure that assumes each turn starts fresh is what actually breaks production agent systems, and it's the reason snapshot-and-resume has become the infrastructure primitive worth understanding in detail. This piece looks at what that primitive actually does, and at how differently the platforms building it have chosen to solve the same problem.

Start with what engineers usually blame when an agent stalls out mid-task. Something times out, the agent restarts from scratch, and the postmortem points at the model (it hallucinated a bad command) or the orchestration layer (the retry logic was too aggressive). Both diagnoses miss the actual failure. Take a coding agent: on turn one it clones a repo and installs dependencies, then across the next dozen turns it edits files, runs tests, and reads output to decide what to fix next. Every one of those later turns depends on filesystem state built by the turns before it, the installed packages, the checked-out branch, the build artifacts sitting in a node_modules folder or a .venv. If the sandbox is one-shot and discards everything the moment a session ends, the agent framework is left with two bad options: re-run the full setup on every single tool call, which is slow and wasteful, or let the state disappear and watch the task become unworkable a few turns in.

There's a reliable tell that a team has outgrown one-shot execution. The framework is re-cloning the repo or re-installing dependencies on every turn, because nobody built a way to keep the environment alive between them. Once that pattern appears in the framework's repeated re-cloning or re-installing on every turn, the fix is not a smarter agent or a better prompt. It's a sandbox that can freeze and pick back up exactly where it left off, and teams that keep tuning the model instead of fixing the infrastructure layer are solving the wrong problem.

The stakes scale with task length. For agents running past the four-hour mark, systems without any way to persist state carry a 90% higher risk of total task failure from API timeouts or infrastructure hiccups alone. Degradation starts even earlier: after roughly 35 minutes of continuous execution, every agent shows some measurable drop in success rate, and doubling the task's duration roughly quadruples its failure rate. Put a dollar figure on it and the problem sharpens further. A single long-running agent run can cost anywhere from $10 to well over $100 in API calls, and without checkpointing, a failure on the very last step means restarting the entire run, doubling both the cost and the time spent. None of this traces back to the model. It traces back to an inability to preserve and restore state, and that's the frame the rest of this piece works from.

What sandbox state contains and why restoring it is hard

Ask what "state" means in a running sandbox and the honest answer runs deeper than files. It's a layered stack, and losing any one layer breaks the illusion of continuity. There's the filesystem, obviously: the working tree, installed packages, cloned repos, build artifacts. But there's also process memory, a Python kernel holding a trained model or a loaded in-memory data structure in RAM, never written to disk anywhere. There are open file descriptors, sockets, pipes, device handles the process is mid-conversation with. There's process credentials and execution context. And there's network state: listening ports, active connections, whatever a dev server has bound to.

Why not just re-run the setup script when the agent needs to resume? Because determinism is never guaranteed. A pip install today can pull a different transitive dependency than it did yesterday, an npm install can hit a registry that's since changed, and environment variables drift between runs in ways nobody notices until something breaks. Re-running setup also just re-incurs the original latency, the very thing snapshot-and-resume exists to avoid.

Persisting only the filesystem doesn't solve it either, and this is the part most agent frameworks get wrong when they build their own crude checkpointing. Consider that Python kernel again: it loaded a model into memory three turns ago, and that model exists nowhere on disk. Replaying files gets the repo back. It does not get the model back into RAM, so the agent's next command fails against a kernel that's lost its state, and the failure looks like a model error when it's actually a persistence gap.

Two mechanisms dominate how platforms actually solve this, and they solve different amounts of the problem. CRIU (Checkpoint/Restore In Userspace) freezes a running container and dumps file descriptor info, memory maps, process credentials, and memory page contents to disk, all restorable later. VM-level snapshotting, the approach Firecracker takes, goes a layer deeper: it captures the entire guest OS state, RAM contents, process state, open file descriptors, so a resumed VM picks up mid-instruction. The Python kernel still has its DataFrames loaded. The dev server is still listening on its port. The working tree hasn't moved.

The distinction matters because of where each mechanism operates. CRIU works at the process level inside a container. Firecracker snapshots work at the guest OS level, one layer down. That is why they capture more and restore with more fidelity. That's the useful definition of "resume fidelity" too: a woken sandbox is the original environment, unpaused, continuing an instruction it was already partway through, exactly as it left off.

None of this is trivial to build. Capturing every layer atomically, without corrupting an in-flight file write or leaving a socket in some half-open state, is a genuinely hard systems problem. That difficulty is why snapshot-and-resume has to be an infrastructure primitive built into the sandbox layer itself. An agent framework can't bolt it on afterward with a clever wrapper script, no matter how good the wrapper is.

How snapshot-and-resume changes the execution model for multi-turn agents

Once state can actually be frozen and restored, the assumption behind agent design shifts. Agents no longer have to complete their work in one unbroken session sitting on one machine. They can suspend, sit idle, move to different hardware, and resume later as if no time passed at all.

That shift opens up four patterns a one-shot sandbox simply cannot support. Pause and resume lets an agent hit a human-in-the-loop checkpoint, freeze the sandbox, wait for a person to review its work, and pick back up from the identical state once approved, no re-setup, no lost context. Failure recovery works through periodic checkpointing: instead of restarting from zero after a crash, the agent resumes from its last saved snapshot, which is the direct answer to that $10-to-$100-plus cost of a full restart mentioned earlier. Migration lets a paused sandbox move to a different node, or even a different availability zone, without losing state, though moving across zones requires the CPU microarchitecture to stay consistent between them (Google's GKE Agent Sandbox documentation flags this explicitly). Reproducible branching lets a running VM be snapshotted once and forked into several live copies, each continuing independently from that same instant, which is what makes tree-of-thought agents and parallel evaluation runs possible without reinstalling anything.

This pattern, sometimes called durable execution context, moved from a niche concern to something a lot of infrastructure teams are actively building for in 2025, with new offerings from AWS, Cloudflare, and Vercel arriving largely because AI agents needed it. Why can't the orchestration layer alone handle this? Frameworks like LangGraph or systems like Temporal are good at retrying failed workflow steps and tracking which node in a graph an agent is on. But that's workflow state, not sandbox state, and the two get confused constantly. Neither tool can reach into a container and restore its filesystem, its in-memory variables, and its open sockets. Solving the problem takes both layers working together: orchestration handles the "what step are we on" question, and the sandbox layer handles "what does the actual execution environment look like right now."

The effect compounds in multi-agent systems. Picture a coordinator that fans out work to several specialist agents running in parallel, each with its own sandbox. Because each of those sandboxes is independently snapshotable, one branch failing doesn't force a restart of the entire tree, just that one branch, from its last checkpoint. That's a meaningfully different failure mode than the flat, all-or-nothing collapse of a single ephemeral session, and it's the difference that decides whether a multi-agent system is worth running in production at all.

The underlying distinction is architectural. A sandbox is either built from the ground up to preserve and restore state, or it's ephemeral by default, and no configuration option turns it into something it isn't.

The isolation layer snapshot-and-resume depends on

Snapshotting an environment is only as trustworthy as the isolation producing it, and this is where the story gets less abstract. A snapshot of a standard container captures process state, but the container is still sharing the host's kernel. Resume that snapshot and it inherits the exact same escape surface it had before, unchanged. A Firecracker microVM snapshot is a different animal: it captures the entire guest OS, including its own dedicated kernel, so the resumed process stays fully contained inside the VM boundary rather than touching the host directly.

The market has settled into roughly three approaches through 2025 and into 2026, and they are not interchangeable despite often getting lumped together in vendor comparisons. Firecracker microVMs give hardware-level guest OS isolation and high snapshot fidelity, and they are a common choice among agent-focused platforms for exactly that reason. gVisor takes a different route, providing strong isolation without the overhead of a full VM, and shows up in some platforms as well as Google's GKE Agent Sandbox. V8 isolates are the lightest end, well suited to short, ephemeral tasks but not built with stateful, long-running agents in mind at all.

Standard containers alone don't cut it for production agent execution, and the historical record backs that up. Two documented CVEs in runc, the container runtime underneath Docker, show how this fails in practice: CVE-2019-5736 and CVE-2024-21626, nicknamed "Leaky Vessels," both let an attacker exploit the runtime to reach the host filesystem from inside what was supposed to be an isolated container. If a container is the isolation boundary an agent platform relies on, that boundary has already failed in the wild, twice, in documented, publicly tracked vulnerability disclosures.

This connects directly to prompt injection, and the connection isn't theoretical. PromptArmor's disclosure involving Snowflake's Cortex Code CLI (fixed in version 1.0.25, dated February 28, 2026) showed how an attacker could plant instructions inside content the agent processes, an indirect prompt injection, and use that to manipulate the CLI agent into escaping its sandbox mode and reaching cached credentials. Widen the lens and the picture doesn't improve: LLM-generated code patches introduce new vulnerabilities in 9.5% of cases. Agents that execute code generated in response to attacker-controlled input are operating on a real exploit surface. OWASP's Top 10 for LLMs, in its 2025 list, formally names this category (LLM10:2025, unbounded resource consumption), and strong sandbox isolation is a key mechanism for enforcing the boundaries the category highlights.

That raises an uncomfortable question for snapshot-and-resume specifically. What exactly gets restored when a weakly isolated sandbox wakes back up? Resuming a snapshot doesn't harden the environment it's resuming into; it restores the environment exactly as it was, vulnerabilities included. The isolation primitive and the snapshot mechanism are co-dependent, not independent choices, and picking a weak one undercuts whatever the other was supposed to guarantee. A platform that boasts about millisecond resume times while running on bare containers is optimizing the wrong variable.

WebAssembly is an alternative that solves a different problem for now, though it's still worth watching. It isolates memory through bounds-checked linear memory, its capability model restricts resource access by default, and runtimes like Wasmtime are building in additional safety mechanisms. Right now, though, that's positioned for language-level sandboxing of individual functions, not full VM-state snapshots of a running agent session.

How the platforms implement snapshot-and-resume differently

No single implementation has won this outright, and picking between them comes down to how long sessions need to run, whether branching matters, what compliance posture is required, and whether paying for standby time is worth it. What follows is a map of tradeoffs rather than a ranking. It's a map of tradeoffs, and the honest read is that most teams are choosing based on which constraint they can tolerate, not which platform is objectively best.

One platform emphasizes sub-90ms cold starts alongside a stateful-by-design model, meaning persistent workspaces hold state across sessions rather than treating each one as disposable. It runs OCI/Docker-compatible environments with a dedicated kernel, filesystem, and network stack per sandbox, auto-archives after 7 days stopped by default, and supports scaled evaluation runs across parallel environments with reproducible snapshot states, useful for reinforcement learning workloads involving long-horizon planning in dynamic settings. It raised a substantial Series A led by FirstMark Capital and holds SOC 2, HIPAA, and GDPR compliance. It offers a dedicated infrastructure model, a deliberate departure from shared execution services, and gives operators control over their execution environments. What it's built for is indefinite stateful persistence and enterprise compliance, without a hard session time cap.

Another platform, aimed more at developer speed, reports roughly 150ms cold starts and about 1-second warm starts via snapshot and resume, with median p50 sandbox creation down to 78ms as of January 2026. Its session limits are explicit: the free Hobby plan caps sessions at 1 hour, and the $150-per-month Pro plan extends that to 24 hours, a hard ceiling even for paying users. Paused sandboxes persist as long as needed. It has raised a substantial amount across four rounds, most recently a sizable Series A in July 2025, with backing from Insight Partners, Decibel, Sunflower Capital, Kaya, and former Docker CEO Scott Johnston. By August 2026 it reported crossing one billion cumulative sandbox launches and more than seven million monthly downloads, and states it's used by 88% of Fortune 100 companies for frontier agentic workflows. It optimizes for fast SDK integration and developer experience broadly, but the 24-hour cap is the real constraint for anyone running agents that genuinely need to persist for days, and no amount of adoption numbers changes that ceiling.

Blaxel takes yet another angle: sandboxes sit in standby indefinitely at zero compute cost, and resume happens in under 25 milliseconds with full filesystem and memory state intact, returning to standby automatically after 15 seconds of network inactivity. It carries SOC 2 Type II, ISO 27001, and HIPAA compliance via a BAA, plus production networking features like custom domains, dedicated egress gateways, and proxy-based secrets injection. It's described as the only provider currently offering unlimited standby duration, which matters most for agents that are active in bursts over long calendar stretches rather than continuously.

Morph Cloud is built around a branching primitive called Infinibranch: snapshot a running VM, then branch or restore in under roughly 250 milliseconds, producing multiple live copies that each keep going from the exact same instant. That's the mechanism behind tree-of-thought agents and parallel evaluation runs, where an agent reaches some interesting state once and then forks into dozens of branches, each trying a different path, without any of them reinstalling dependencies or replaying setup from scratch. Ordinary pause-and-resume can't approximate this; it's a structurally different capability, closer to version control for a running machine than to a save file. Morph optimizes for parallel exploration from a shared checkpoint, and is less suited to a single long linear session running for days.

Another provider caps alpha snapshots at 7 days, after which memory snapshots get deleted, while filesystem snapshots default to a 30-day TTL that can be configured. It scales to more than 50,000 concurrent sessions and serves over 10,000 teams, holds SOC 2 Type II certification with HIPAA-compliant workloads available on Enterprise plans via BAA, and offers a notably broad GPU lineup (T4, L4, A10, L40S, several A100 variants, H100, H200, B200, B300) without quota restrictions, relevant for agents that need inference alongside code execution in the same environment. It optimizes for concurrency at scale and GPU access, but the snapshot feature still carries an alpha label, a fact to weigh before betting a production workload on it.

Vercel Sandbox runs isolated code execution on Linux microVMs and supports snapshotting to save state and resume it later, with snapshots expiring after 30 days by default. Billing runs on active-CPU usage at $0.128 per hour plus memory at $0.0212 per hour per unit of memory consumed. It inherits SOC 2 Type II compliance from Vercel's broader platform, which also carries ISO 27001, HIPAA with BAA, PCI DSS, and GDPR certifications, a genuinely wide compliance footprint. It optimizes for tight integration with the Vercel ecosystem, and while the compliance coverage is strong, snapshot durability is bounded by that 30-day window regardless.

A separate provider works around the idea of Blueprints, reproducible templates for building reusable environments, paired with Snapshots that capture the disk state of a running Devbox so it can be resumed later or cloned into multiple environments from the same known starting point. Devboxes get suspended and resumed rather than rebuilt for every interaction. It runs on a custom bare-metal hypervisor and raised a modest seed round in July 2025. Blueprints plus Snapshots together give teams a consistent, auditable environment even at the cost of raw flexibility, and the earlier funding stage suggests a narrower, more enterprise-focused go-to-market than some competitors.

Finally, Google's GKE Agent Sandbox provides an isolated environment for running untrusted, LLM-generated code inside a Kubernetes cluster. GKE Pod snapshots save and restore the state of these sandboxed environments, supporting fast startup from a pre-warmed snapshot as well as pausing long-running sessions, folding snapshot-and-resume directly into the Kubernetes operational model a lot of existing infrastructure teams already run on.

Line these up and the pattern is less about one winner than about tradeoffs that map cleanly onto what a given agent actually needs: how long it runs, whether it needs to fork into parallel branches, what compliance box it has to check, and whether idle standby time is worth paying for. The 24-hour cap that kills one platform for a research team is irrelevant to a customer-support bot that never runs that long, and the alpha-stage snapshot feature that's a dealbreaker for a compliance-heavy enterprise might be perfectly fine for a startup moving fast. At bottom, though, the infrastructure question is the one raised at the start: can the environment remember what it was doing, and pick the thread back up exactly where it dropped it, without pretending the underlying isolation problem doesn't exist.