Architecture and the state boundary

This page describes what a checkpoint preserves and what sits outside its boundary. A checkpoint captures a microVM’s memory, filesystem and device state together. Session history records the work between checkpoints; forks branch that history. Proof separates historical results from availability, and Limits keeps material gaps public.

What a checkpoint contains

The boundary is the microVM. Its agent process, open buffers, workspace and installed tools are captured with its memory, filesystem and device state. Content hashing detects corruption; atomic publication prevents a partial checkpoint from appearing complete.

Historical crash tests left the previous checkpoint intact, and a corrupted checkpoint was refused rather than restored (gate 2b). These results apply to the tested runtime and failure scenarios.

What a checkpoint does not contain

Provider-side KV and attention caches. They live on the provider’s servers, outside the machine, and are not KeepState’s to save. What survives is the machine’s own copy of the conversation (see KV cache). On resume the runner sends its context again, as it always does.
The independent service record. Service accounting and event history have a separate lifecycle and retention policy.
External effects. A checkpoint cannot undo an email, network request, purchase or database write completed outside the guest. Design external actions for retries and idempotency.
Your provider key. It is stored by the service, outside every machine, image and checkpoint; a machine receives a per-session credential instead. A checkpoint cannot contain what never entered the machine (gate 3). A secret that you or an agent writes into guest memory or the workspace can be captured; keep such secrets out of the guest.

How interrupted model calls recover

A save can land while a model call is in flight. At that moment the gateway cannot know whether the response reached the program, so it stores every completed response, not only the ones whose delivery failed. The recovery path: the call in flight fails at resume (expected), the program retries, and the gateway serves the completed response from its store, billed once upstream and never again. In the test, 31,486 tokens were matched to the original call and billed at zero (gate 3). This was proven on the evidence bench; its standing in production is on What can I use today. From 20 September to 6 October 2026 a retry after a resume could be billed again; the fix is in production since 6 October 2026, and the paid gateway test re-ran green on 13 October 2026 (Limits, section 5).

Session history is reconciled before saved work continues. This supported provider replay behavior does not make arbitrary external actions exactly-once.

The recorded gateway result does not guarantee that every client retries. Claude Code retried in the historical test; aider retried 3 of 4 times while the gateway held the response 4 of 4 (Limits, section 5).

Where your state lives

Process loss and host loss. A session survives the loss of its processes, including the service’s own daemon, on one machine (gate 4). Host loss is survived within one stated test in one region, not as a standing property; see Limits, section 2.
Content-addressed storage. Content hashing identifies and verifies saved content, and identical content can be shared (concepts).
Retention. The retention policy keeps checkpoint content while the account exists, with no automatic expiry. Deleting a session removes its live resources and records and erases the checkpoint content only it held. Account deletion was tested separately; see Security.
Pinned restore. A checkpoint restores only on a host running the same pinned hypervisor and kernel, and the same CPU architecture, it was taken on (the pinned versions); see Limits, section 3.

Resume times, measured

No recovery-time objective is offered; these are measurements. On the aarch64 evidence bench, machines running an agent resumed in 13.7 to 25.2 seconds across gates 4, 6 and 7.

These are measurements across different workloads, not a single latency distribution. A memory-only machine resumed in 1.50 to 1.65 seconds during the soak, and a checkpoint 15.2 hours old woke in 14.3 seconds (Limits, section 4).

The x86_64 fleet has its own figures. The fleet resume test drove a 2 GiB agent machine through 20 interleaved resumes per condition: 25.1 seconds at the 95th percentile when the chunks were already on the host (warm), 47.5 seconds when they were not (cold) (rs-1). This was the 5 September 2026 laboratory run; sub-second recovery and a recovery-time objective are not established.

How each of these numbers was produced is on the methodology page.