# What is a memory snapshot?

A memory snapshot saves a running virtual machine's RAM and device state to files, so it can later resume from exactly that moment.

**On Runtime every sandbox can be paused with its memory and running
processes, and compute billing stops the moment it pauses.** A pause took a
median 234 ms on 24 September 2026 ([speed](/docs/speed)), and the saved state
costs $0.08 per decimal GB per 30-day month for up to 365 days on a paid
account ([pricing](/docs/pricing#paused-storage)).

## What is in a memory snapshot?

A disk snapshot keeps files. A memory snapshot also keeps everything that
existed only in RAM: running processes, open sockets inside the guest, a
loaded model, a warmed cache, a half-finished shell session. Resuming it does
not boot anything. The guest carries on 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 calls full
snapshots production-ready and diff snapshots 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", and writes go to [copy-on-write](/glossary/copy-on-write)
memory. That is why a resume can be fast, and why the memory file must stay
available for the microVM's whole life. A UFFD backend hands page faults to a
user-space process instead, for more control over how pages arrive.

## Why memory snapshots matter for AI agent sandboxes

An agent's setup is often slower than its task: clone, install, build, start a
server. A memory snapshot turns that setup into a saved moment. Pause while
waiting on a user and pay only for storage; branch one prepared machine into
several attempts; start an evaluation from a known state every time.

Cloning has one trap. 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 that changes on
resume, so they can reseed their 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 and wakes
  it on the same host. Each pause replaces the previous saved state.
- **Fork** makes 1 to 10 running copies with memory and processes, and its own
  snapshot is free ([sandbox fork](/glossary/sandbox-fork)).
- **Snapshot** saves a machine to start new sandboxes from later, copied off
  its server, encrypted, as soon as it is ready
  ([sandbox snapshot](/glossary/sandbox-snapshot)).

Updating Runtime's default image does not touch a paused sandbox's saved
files, and a saved state that is incompatible or cannot be verified is refused
rather than silently restarted without its memory
([storage](/docs/storage#updating-the-default-image)).

Related: [pause and resume a sandbox](/how-to/pause-and-resume-a-sandbox),
[cold start](/glossary/cold-start),
[RL environments](/use-cases/rl-environments).

## Sources

Checked 25 September 2026.

- [Firecracker snapshot support](https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md)

Facts on this page were checked on 25 September 2026.