Three layers. One window.
The ks command on your machine, a session microVM on our fleet, and any model behind it using your own provider key. Everything on this page is one of those three layers, and the one thing that matters is which layer holds the state: the middle one, always.
One job, from attempt to checked result
Illustrative workflow. Not a customer result.
Example task
Update a dependency and pass the repository's existing tests.
- step 1 Agree the checks
- step 2 Run the first attempt
- step 3 Restore and retry if needed
- step 4 Review the verified result and cost record
In the currently verified publication scope, KeepState authorizes a result for review. It does not create an external pull request.
diagram: the three layers as shipped at v0.1.26 · the middle layer is the durable object
layer 1 · your machine
The ks command is a small CLI and deliberately nothing more: the engine is not inside it. ks run names the workspace you choose to sync, flag by flag, and attaches your terminal to the session's window. What you never named never leaves your machine. The precise rules live in how sessions run.
layer 2 · the session microVM
Your agent runs in a microVM on the KeepState fleet, and that machine is the durable object: memory, filesystem, process and tool state checkpoint atomically, restore refuses corruption, and a hard kill is a measured 13.7 to 25.2 s interruption, not an ending. Gate-tested on the evidence bench; MEASURED .
layer 3 · any model
Model calls leave the session through the metering gateway. Use your own provider key. Gateway-managed keys remain outside the guest; user- or agent-written secrets can enter checkpoints. Managed inference is planned and is not currently available to purchase. Supported retries can replay a completed response without a second purchase; client and provider limits still apply.
resume speed, measured on the fleet
On 5 September 2026, a 2 GiB agent guest on an x86_64 laboratory host completed 20 interleaved resumes per condition. Warm resume p95 was 25.1 seconds and cold resume p95 was 47.5 seconds. These are recorded workload measurements, not a recovery-time guarantee.
Sub-second resume remains planned. Results from this workload do not establish latency for other workloads, guest sizes or deployments. Dated scope and limitations: the resume record.
The laptop lid, told properly.
At hour five of a long migration your agent is mid-thought: tests running, dev server up, a half-written file open. You close the laptop. The terminal window dies, because it was only ever a window. The session does not notice. The agent keeps working on the fleet, the gateway keeps holding its calls, and the next checkpoint lands on schedule.
On the train you open a different machine, type ks attach, and the same tmux window is there, further along than you left it. Nothing resumed, because nothing stopped. That is the whole architecture: the state lives in the one layer that never sits in your bag.