A fresh sandbox forgets everything. Snapshots and forking let one save state, branch it, pause it, and rewind it. Follow a machine's state as it is frozen, thawed and cloned, one scroll at a time.
Spin up a fresh sandbox and it knows nothing: it boots, installs your dependencies, and warms its caches before it runs a single useful line. Do that on every call and the setup, not the work, dominates the time and the bill. Snapshots exist to skip it.
A snapshot captures the sandbox's entire state, its memory, CPU registers and disk, and writes it to storage. Not just the files: the running process, loaded libraries and warm caches are all frozen exactly as they were.
Restoring loads that saved state back into a live machine. Because the environment is already set up and already warm, a restore skips the boot, the installs and the cache warming entirely, so it returns in a fraction of a cold start.
A fork spins up a new live sandbox from a snapshot. One saved state can seed many forks at once, each an independent machine that begins from the identical, already-warm starting point.
Forks do not each copy the whole machine. They share the parent's unchanged memory and disk pages and only store what they change. Ten forks of a 2 GB machine cost the shared 2 GB plus each fork's small set of writes, not 20 GB.
The same freeze lets you pause an idle sandbox. Its state is kept, but compute billing stops while nothing runs, and you resume the exact machine later. On a long agent task, that turns dead thinking time into near-zero cost.
Snapshot before each risky step and a failed tool call is no longer fatal: roll back to the exact state just before it, instead of restarting the whole task. The same move, forking one state into many attempts, is how reinforcement-learning rollouts explore.
Snapshots are not free. You pay to store them, a restore only helps when the snapshot is genuinely warm, and support varies: some sandboxes do full memory snapshots, some only disk, and some none at all. Match the feature to how often you actually branch or pause.
A sandbox is disposable by design, but throwing everything away after every run is wasteful. Snapshots and forking are how modern sandboxes get the best of both: a clean, isolated machine, without paying the full setup cost each time. The idea is simple once you separate three moves, save, restore, and branch.
A snapshot freezes a machine's full state, memory, CPU and disk, into storage. A restore loads it back into a live sandbox. Because the restored machine is already booted, already has your dependencies, and still holds its warm caches, it is ready far faster than a cold start that has to redo all of that. You keep the isolation of a fresh environment while skipping the part that was slow.
A fork starts a new live sandbox from a snapshot, and you can start many at once. The reason this is not ruinously expensive is copy-on-write: the forks share the parent's unchanged memory and disk pages and only allocate space for what each one writes. That shared-page trick is what makes it practical to branch one warm state into dozens of parallel copies, which is exactly what a reinforcement-learning rollout or a parallel agent search needs.
Two payoffs fall out of the same machinery. Pausing freezes an idle sandbox so its state survives while compute billing stops, which matters on long agent tasks with a lot of think time between actions. Rewinding uses a snapshot taken before each step so a failed tool call rolls back to the last good state instead of restarting the whole run. Both turn "state" from something you rebuild into something you move around.
| Sandbox | Start | Isolation | State handling |
|---|---|---|---|
| Daytona | 90ms | Docker container | Persistent workspaces, snapshots |
| E2B | 150ms | Firecracker microVM | Pause/resume with memory state, snapshots |
| Fly.io Machines | 300ms | microVM | Persistent ext4 filesystem, checkpoints |
| Vercel Sandbox | 400ms | Firecracker microVM | Persistent by default |
| Runloop | 400ms | microVM | Git-style disk snapshots + branching |
| CodeSandbox SDK | 500ms | Firecracker microVM | Git-versioned filesystem, forking |
Live from our vendor data, verified and dated on each vendor page. "State handling" is each provider's own description of persistence, snapshots and forking.
A snapshot is a frozen copy of a sandbox's full state, its memory, CPU and disk, saved to storage. A fork is a new live sandbox branched from a snapshot. One snapshot can spawn many forks, and each starts from the same saved point.
A cold start boots a kernel and then re-runs your setup: installing packages, warming caches. Restoring skips all of that. It loads a machine that is already set up and already warm, so the environment is ready in a fraction of the time a fresh boot would take.
Forks share the parent's unchanged memory and disk pages and only store what each one changes, an approach called copy-on-write. Ten forks of a 2 GB machine do not cost 20 GB; they cost the shared 2 GB plus each fork's small set of writes.
On providers that support pausing, yes. Freeze the sandbox and its state is kept while compute billing stops, then resume the same machine later. E2B, for example, offers pause and resume with the memory state intact.
An agent can snapshot before each risky step, then roll back to the exact state just before a failed tool call instead of restarting the whole task. The same trick powers reinforcement-learning rollouts, where one saved state is forked into many parallel attempts.
In our dataset, E2B offers pause and resume with memory snapshots, Runloop does git-style disk snapshots with branching, CodeSandbox has a git-versioned forking filesystem, and Fly Machines keep checkpoints. Support and granularity vary, so check each vendor page.
Pricing changes, new entrants, benchmark refreshes and one sharp take from Eve Harper. Read by engineers choosing where their agents and apps run. No fluff. Read the archive.