Runtime bills saved state only on what is not shared. A paused sandbox pays for the blocks it alone owns, with shared base-image blocks left out. A block that two of your snapshots share counts once. Both cost $0.08 per decimal GB per 30-day month (pricing).
How does copy-on-write work?
The idea is to delay a copy until one is needed. Two users of the same data point to one shared copy, marked read-only. When one of them writes, the system copies only the affected piece, such as a memory page, a file or a disk block. It then gives the writer its own version. Everything unchanged stays shared.
Linux process creation depends on it. The fork(2) man page says: "Under Linux,
fork() is implemented using copy-on-write pages, so the only penalty that it
incurs is the time and memory required to duplicate the parent's page tables,
and to create a unique task structure for the child."
Where copy-on-write shows up
| Layer | Shared data | What a write copies |
|---|---|---|
| Process memory | Parent's pages after fork |
The page written |
| Container images | Read-only image layers | The whole file, into the container's writable layer |
| VM snapshot restore | A snapshot's memory file | The page written, into anonymous memory |
Docker defines it as "a strategy of sharing and copying files for maximum efficiency." A container gets a thin writable layer over its image. When it changes an existing file, the overlay2 driver first copies that file up into the writable layer. From then on, the container sees only its copy.
Firecracker uses the same technique for memory. On restore, it makes a
MAP_PRIVATE mapping of the snapshot's memory file, and loads pages on demand.
"Any subsequent memory writes go to a copy-on-write anonymous memory mapping."
See memory snapshot.
Why copy-on-write matters for AI agent sandboxes
Agents create many machines that start the same way: one image, one prepared state, many attempts. Copy-on-write keeps that inexpensive. Ten copies of a machine differ only in what each attempt wrote. So the storage and memory cost grows with the changes, not with the number of copies.
The catch is that anything shared is shared exactly. Firecracker warns that restoring one snapshot many times can duplicate "unique identifiers, random numbers and random number seeds, the guest OS entropy pool, as well as cryptographic tokens". It offers VMGenID, so Linux 5.18 and later guests can reseed.
How Runtime relates to it
This page covers the billing and the behavior. A paused sandbox is charged for the disk and memory-snapshot blocks it alone owns. Volume backups are incremental. Only what changed since an earlier backup of the same volume is stored again, and empty space is not stored (volume backups). A fork makes 1 to 100 running copies of a sandbox. The snapshot it takes for itself is free.
Related: sandbox fork, sandbox snapshot, pause and resume a sandbox.
Sources
Checked 25 October 2026.
Facts on this page were checked on 25 October 2026.