Limits

Customer limitations and dated evidence scopes remain public. Historical tests do not independently verify current deployment.

What KeepState cannot do today, with the evidence for each. It is the companion to the claims file: that lists what is proven; this lists what is not, or what is proven only within a stated test.

Where a limit is a number, the number was measured and the run is linked. Where a limit is an absence, it says what would have to exist to lift it.

1. Two provider families, and a translation path that is not “any provider”

The limit. Two model provider families are proven: an Anthropic-native route and an OpenAI-compatible route over OpenRouter, each with a cheap and a strong tier. Anthropic-native work running on an OpenAI-shape provider works by translation in the gateway, with its own scope: streaming is buffered rather than incremental, and replayed thinking blocks are dropped. “Any provider” is not claimed: each provider family needs its own contract before it can be served.

Evidence. The provider rows on the proof page.

2. Host loss is proven once, in one region, and not continuously exercised

The limit. A saved session survives the loss of its host within a stated test: two hosts in one region share a durable store, and a checkpointed session resumes on the replacement host with its billing history carried over. The failover is not continuously exercised, cross-region recovery is not claimed, the failover coordinator is not part of the production service, and no recovery-time objective or SLA is offered. The one measured failover took 47 s from the loss of the host to reconciled billing, one run.

Evidence. The failover record and the billing reconciliation record. The dated limits record states the tested scope.

What would lift it. Continuous exercise of the failover path inside the production service, a cross-region test, and a recovery-time objective measured over many runs.

3. Snapshots are pinned per architecture; the two stacks do not mix

The limit. A checkpoint restores only on a host running the same pinned stack and CPU architecture it was taken on. The production fleet is x86_64; the evidence bench is aarch64. A checkpoint does not travel between them.

Evidence. The pinned versions and the fleet’s re-run of the founding tests.

4. Resume is seconds, not sub-second

The limit. Resume times depend on the workload and environment. The historical measurements below do not establish a recovery-time objective or sub-second recovery.

The 5 September 2026 x86_64 2 GiB agent guest measured warm p95 25.1 seconds and cold p95 47.5 seconds, from 20 interleaved trials per condition. These and the table above describe separate laboratory workloads. These measurements do not establish zero downtime; see the dated resume record.

5. Client retry behavior differs by agent, and is not ours to promise

The limit. When a model call is interrupted by a freeze, the gateway is meant to keep the completed response and serve it again at no new cost if the program asks for it after the resume. From 20 September to 6 October 2026 it did not: when the answer had already been passed to the frozen program, the call it repeated after the resume was sent to the provider again and billed again. The fix is in the production gateway since 6 October 2026, and the paid gateway test re-ran green on 13 October 2026 (the gate record). The store serves a repeat only when the program sends the same request again: in one of that day’s three runs Claude Code rebuilt its request after a longer stall, which is new work and billed once. Whether the program asks again is its own behavior. Claude Code does; aider 0.86.2 did in 3 of 4 runs.

Evidence. The second-agent test, the gate 3 record, and the resumed-retry finding in the public defect status.

6. Two agents is evidence of generality, not proof of universality

The limit. “Any agent works out of the box” is not claimed. In plain sessions two programs have been frozen and resumed in recorded tests: Claude Code and aider 0.86.2. Agent sessions run one of two certified runners, each certified by its own run of every KS-009 row, keyless then paid: Claude Code 2.1.296 (since 2026-10-14; re-certified on the launch candidate 64473f7, docs/upgrade/evidence/KS-009/paid-2026-10-16-64473f7-PASS; 2.1.251 stays certified by its own run for the sessions created on it) and Codex CLI 0.162.1 on GPT-6-Luna (since 2026-10-16, candidate 64473f7, docs/upgrade/evidence/KS-009/paid-codex-2026-10-16-64473f7-PASS; Codex calls your own OpenAI key, and its other models are not offered). Another runner, another version of either, or another Codex model is not covered.

Evidence. Runners and the compatibility matrix.

7. The durability rate is bounded by its sample, not by its successes

The limit. 25 of 25 fresh kill-and-resume cycles succeeded: 100% observed, with a Wilson 95% interval of 86.7%–100%. This small controlled sample does not guarantee customer reliability or every failure scenario.

Evidence. The soak.

8. Storage: full snapshots, fixed chunking, local filesystem

The limit. Saved state can share identical content, but storage savings depend on the workload. Across 82 checkpoints in one historical soak, the store held 4,233 MiB instead of 80,952 MiB (19.1×). Changes that shift data can reduce sharing; no general savings ratio is promised. Storage architecture does not by itself establish cross-region recovery.

Evidence. The soak.

9. Snapshot compatibility is pinned, not portable across versions

The limit. A checkpoint restores only on a host running the same pinned hypervisor and guest kernel it was taken on. There is no migration of a checkpoint across versions.

Evidence. The pinned versions.

10. Limits you meet using the service today

• Bring your own key. Model calls use your own provider key; KeepState’s own keys are not available. One key per provider per account: adding a key again replaces it.
• One running session on the free tier; forking a session needs a paid plan.
• Two token figures. A session’s machine is bounded by its gateway budget; calls made through the service (such as adviser consultations) are admitted under the session’s token cap. Which of the two will govern agent sessions is an open decision; today the gateway budget is the one that stops a machine’s model calls.
• At the budget. When a session’s gateway budget is spent, further model calls are refused. A plain session is saved and paused; for an agent session, pausing at the budget has not been tested on its own.
• When credit runs out, running sessions are saved and paused rather than killed. That path has not yet been verified on a running production session.
• Permission requests. While an agent waits on a request, a decision must arrive within about 45 seconds; after that the tool is refused and the request is closed, and a decision sent later is refused, not applied.
• Cruise spend ceiling. Until per-model rates are ratified, model calls are unpriced and a Cruise job’s spend ceiling does not stop it. What bounds a job is its attempts limit, each attempt within the session token budget of your tier; resuming a job from review grants a fresh attempts limit. The job, its status and the console say so wherever the ceiling is shown.
• What a Cruise acceptance proves. A Cruise job on your repository is accepted when your own tests pass. Those tests run in the same test runner as the code they check, so code written to cheat could make the runner report passes it did not earn, and the service cannot rule that out. The accepted result says so. Review the change before you rely on it. The spend-ceiling and acceptance limits are open findings in the public defect status.
• Deleting a session stops its machine, removes its records and erases its checkpoint content, except content a surviving fork shares, which stays that fork’s under the retention policy. Its deletion plan says which applies before you confirm. Sessions saved before 6 October 2026 were re-sealed on 10 October 2026, so this holds for them too. Scheduled expiry is not offered. Historical account erasure tests apply to their stated key-custody conditions.
• Terminal resize is not relayed to an attached plain session.

Historical operational edges

Historical operational defects affected session-state reporting, help behavior and service restart. Their release fixes apply to the recorded versions. The available record also describes a restart edge that can leave service unavailable; customers should use the documented troubleshooting path rather than an internal repair procedure.

A reconciliation monitor can miss a stopped worker while there is no outstanding usage; detection may occur only after usage resumes. Current evidence of complete idle-period monitoring is not available.

Stopping or killing a session does not delete stored checkpoint content; deleting the session does, as section 10 describes. Automatic expiry remains an implementation gap under the published policy.

11. Liveness across sleep is verified, never assumed

An early Apple Silicon laboratory run was interrupted by host sleep. It could continue from recorded state, but this is a property of that test environment, not proof that arbitrary host suspension is transparent. The hosted service and the user’s local terminal have different failure boundaries.

12. The defect ledger is public, and two entries deserve this page

A historical session-record defect could leave writes unrecorded; v0.1.3 reports a fix. A separate gateway recovery finding could leave requests returning a visible unavailable response until team recovery. The record states refusal rather than silent loss or double billing. These historical findings do not prove current exploitability or current remediation. Findings.

Signup-credit incident, September 2026: a published credit amount was applied incorrectly. The incident record reports that affected credit was corrected and a guard was deployed on 18 September 2026. A remaining gap concerned keeping operational values aligned when the published policy later changes. No customer identifiers or account-level financial rows are needed to explain that impact. Incident history.

Open durability findings

The product’s findings record lists no open durability finding for release v0.1.21 (checked 13 October 2026). The six recorded open in the first v0.1.19 release record were resolved before that release was published:

Per-session deletion and one home for account keys: fixed and served in production since 6 October 2026. Deleting one session now makes the content only that session held unreadable, from every checkpoint and backup copy, and an account’s keys are held in one place, so an erasure reaches every host. Sessions saved before 6 October 2026 had to be re-sealed before they could be deleted one at a time; the accounts holding them were re-sealed on 10 October 2026. Evidence: per-session deletion, 4 October 2026. Retention policy and gaps.

Restored memory under host memory pressure: fixed and served in production since 6 October 2026. A restored session’s memory is now held in memory the host cannot evict while the session runs, and the host checks it has room for the largest session before it starts.

Encrypted checkpoint soak: fixed in test and deployed on 6 October 2026. A three-hour soak of encrypted sessions (306 resumes) passed on 5 October 2026, and its deliberately broken control failed as it must. Evidence: encrypted soak, 5 October 2026.

A paused session after a failed checkpoint: fixed in test and deployed on 6 October 2026. A checkpoint that fails after pausing its session now resumes the session and records that it did.

Resumed session network attachment: closed as not reproduced. 461 resumes under the recorded conditions each attached to their own network, and a permanent check watches for a recurrence. The related fork-networking fix is fixed in test and deployed on 6 October 2026. Findings.

A resumed retry billed again: from 20 September to 6 October 2026, a model call interrupted by a pause could be sent to the provider and billed a second time after the resume. Fixed and served in production since 6 October 2026; the paid gateway test re-ran green on 13 October 2026 (the gate record); section 5 states what the store does and does not serve. Findings.

Session-store concurrency safeguards: the engine’s session store waited for a busy database on only one of its connections; its other connections could give up at once on meeting another writer. No failure has been observed from it. Fixed in tests on 30 September 2026; the fix is in the production engine since 6 October 2026 and has not yet been exercised there. Findings. Evidence: public defect status.

Soak coverage: the original seven-hour soak remained a historical result for later releases until separately rerun. A failed six-hour attempt recorded 71 of 72 checkpoints. Its later amended run recorded 72 of 72, completed on 19 September 2026, in one x86_64 guest scenario. The failed record remains failed; the later pass does not rewrite it or cover every workload. Soak summary.

Account erasure and scheduled expiry: historical account-deletion tests made tested checkpoint and credential backups unreadable under their stated key-custody conditions. The policy keeps checkpoint content while the account exists, with no automatic expiry; scheduled expiry is not offered. Retention policy and gaps.

Host-loss billing continuity: the 6 September 2026 test reported preserved spend, no repeated billing of the tested retry and reconciliation before settlement. Its 47-second interval is one run, not an SLA. Evidence: billing state across a real host loss.

How to read this file

A limitation is a customer-impact statement, a measured boundary or an explicitly missing assurance. Fixed, open, superseded and not-run records remain distinct. Public summaries retain outcomes and limits while internal repair instructions remain private.