What is copy-on-write?
Copy-on-write (CoW) lets copies share one set of data until one of them writes; only the part that changes is then copied.
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, and a block 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 defer a copy until it is needed. Two users of the same data point at one shared copy, marked read-only. When one of them writes, the system copies just the affected piece, a memory page or a file or a disk block, and gives the writer its own version. Everything unchanged stays shared.
Linux process creation depends on it. The fork(2) man page:
"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, and from then on the container sees only its copy.
Firecracker uses the same trick for memory. On restore it makes a
MAP_PRIVATE mapping of the snapshot's memory file, loading pages on demand,
and "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 make many machines that start the same way: one image, one prepared state, many attempts. Copy-on-write is what keeps that cheap. Ten copies of a machine differ only by 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", and offers VMGenID so Linux 5.18 and later guests can reseed.
How Runtime relates to it
What the guides state is the billing and the behaviour. 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 10 running copies of a sandbox, and the snapshot it takes for itself is free.
Related: sandbox fork, sandbox snapshot, pause and resume a sandbox.
Sources
Checked 25 September 2026.
Facts on this page were checked on 25 September 2026.