On Runtime, every sandbox can be paused with its memory and running processes. Compute billing stops when it pauses. The saved state costs $0.08 per decimal GB per 30-day month while you have credit on a paid account (pricing).
What is in a memory snapshot?
A disk snapshot keeps files. A memory snapshot also keeps everything that exists only in RAM: running processes, open sockets inside the guest, a loaded model, a warm cache, and a shell session in progress. Resuming a memory snapshot does not boot anything. The guest continues as if no time had passed.
Firecracker's snapshot documentation lists what its snapshots hold:
| Part | Contents | In the snapshot files? |
|---|---|---|
| Guest memory file | A copy of the guest's RAM | Yes |
| MicroVM state file | Emulated devices and KVM state | Yes |
| Disk files | The guest's block devices | No, the user manages them |
A full snapshot holds all guest memory and can be resumed on its own. A
diff snapshot holds only pages changed since the last snapshot, and is
merged onto a base with Firecracker's snapshot-editor. The project still
lists diff snapshots as a developer preview.
How does restoring work?
Firecracker does not read the whole memory file before the guest runs. It
maps the file with MAP_PRIVATE, "resulting in runtime on-demand loading of
memory pages". Writes go to copy-on-write memory.
A resume can therefore be fast. The memory file must stay available for the
microVM's whole life. A UFFD backend passes page faults to a user-space
process instead. That process controls how pages arrive.
Why memory snapshots matter for AI agent sandboxes
An agent's setup often takes longer than its task. The setup includes clone, install, build and start a server. A memory snapshot turns that setup into a saved moment. Pause while the agent waits on a user, and pay only for storage. Branch one prepared machine into several attempts. Start every evaluation from the same known state.
Cloning has one risk. Firecracker warns that restoring the same snapshot more than once can duplicate "unique identifiers, random numbers and random number seeds, the guest OS entropy pool, as well as cryptographic tokens". Its VMGenID device gives Linux 5.18 and later guests a 16-byte identifier. The identifier changes on resume, so the guest can reseed its random number generator.
How Runtime uses it
Runtime keeps a sandbox's memory in three ways:
- Pause and wake keeps one sandbox's files, memory and processes. It wakes the sandbox on the same host. Each pause replaces the previous saved state.
- Fork makes 1 to 100 running copies with memory and processes. The fork's own snapshot is free (sandbox fork).
- Snapshot saves a machine so you can start new sandboxes from it later. The snapshot is copied off its server and encrypted as soon as it is ready (sandbox snapshot).
An update to Runtime's default image does not change a paused sandbox's saved files. A saved state that is incompatible or cannot be verified is refused. It is not restarted without its memory (storage).
Related: pause and resume a sandbox, cold start, RL environments.
Sources
Checked 25 October 2026.
Facts on this page were checked on 25 October 2026.