How sessions run

This page is the precise version of the sentence “your terminal becomes a window into a machine of ours.” Four boundaries matter, and each has a rule.

The sync boundary: what the client uploads

Several commands create work on the fleet; only Cruise uploads your files.

• ks run --agent (and n in the app) sends a session name, an agent name, the id of the key to bind, and, with --task, the text of the first instruction. No files: an agent session starts with an empty workspace, and the agent brings code in with its own tools, each run subject to your permission.
• ks run (a plain session) sends an image name and a token budget and nothing else; you bring files in yourself, over ks exec or from inside the session.
• ks session fork and ks session migrate work from checkpoints that are already on the fleet, and ks cruise draft create --session (or --proposal) from a session’s files there; none of them uploads anything.

Cruise is the upload path: ks cruise run (or ks cruise upload, for a job created with --separate-upload) packs the repository you ran ks cruise init in and sends exactly that archive with the approved manifest. It leaves out the .git and .keepstate directories, dependency and tool directories such as node_modules and .venv, and sensitive or ignored files; ks cruise preview lists exactly what would go and why. ks cruise draft create --dir packs a folder with the same selection and sends it for the service to draft the job; --archive sends an archive you made, as it is, and the service applies the same selection to it. The browser console’s upload packs a folder in your browser, leaving out dependency folders and files that hold credentials before it is sent. There is no home directory scan, no dotfile collection and no environment harvest. What you never sent never leaves your machine. The stored categories and their retention and deletion rules are on Security.

The window model: what your terminal is

Your terminal is a viewport, not a host: closing it, losing the network, or closing the laptop ends what you see and nothing else. The agent keeps working, because the machine is the durable object.

• An agent session’s window is the ks app: run ks on its own to open it. It renders the agent’s conversation from the session’s journal and sends what you type as instructions; every ks command except agent open, attach, login and logout also runs inside it as a / command (slash commands). There is no shell into an agent session; the agent acts through its runner and your permission requests. One window steers an agent at a time (approvals and control).
• A plain session’s processes run inside its machine, and ks attach streams its terminal to yours. When the machine is killed and resumed, the window reconnects to the same machine.

Where model calls go

Two questions live here, and they have different answers: whose key pays for a call, and which provider serves it.

Whose key pays: yours, or, where it is offered, KeepState’s.

• Your own key. Calls go to your provider through the metering gateway, on the key bound to the session; the key never enters a machine, an image or a checkpoint. You pay your provider directly for model calls, and KeepState bills session time and storage. An agent session’s calls are its runner’s, to that runner’s provider (Runners); /usage shows their token total as the gateway metered it.
• KeepState’s key, where it is offered. A session can bind a provider to KeepState’s key instead of yours. Each call is then held against credit you have bought before it leaves, charged at the provider’s list price plus the published spread, and refused, with the session parked, at a limit. Pricing says whether it is offered today and lists its rates.

Which provider serves a call depends on the route. Every call leaves through the same metering gateway, which speaks more than one API shape. Two model families have been driven to task completion in recorded tests, an OpenAI-compatible route through OpenRouter and an Anthropic-native route, each with a cheap and a strong tier; proven in those tests, not enabled in production.

Continuing Anthropic-native work on an OpenAI-shape provider is a separate capability, translated by the gateway, and it is enabled in production: the actual Claude Code binary continued that way across a checkpoint, and the deployed gateway does the same on a real account. Its scope travels with it: streaming through translation is buffered rather than incremental, so the first byte arrives after the upstream response completes, and replayed thinking blocks are dropped. The dated state of each route is on What can I use today and Compatibility.

What the browser console is

The console is the same window in a browser: sign in at ctl.keepstate.ai, see your sessions, read the timeline, the meters and the ledger, and add credit. It shows no invented numbers: a metric with no live feed reads unavailable.

What this page does not claim

Where the fleet’s own tests have not run, a measured number on this site is a number about the evidence bench, and is labeled that way where it appears. Which kind of measurement any published number is (bench, production check or customer trial) is set out on the methodology page.