Reattach and Resume

A run emits events as it goes — steps starting, tool calls, agent output. Those events are journaled, which buys two things: you can close a tab mid-run and pick the stream back up, and a run that is interrupted resumes from where it stopped rather than from the beginning.

Reattaching to a running run

Every event is appended to a per-run journal as one line, each carrying a monotonic sequence id. When you reopen a run that is still going, the UI replays from the journal and then continues live — so you see what you missed rather than joining midway.

The sequence id is written into the line rather than derived from its position in the file. That is what makes a crash cheap: a torn final line costs exactly that one event, because reading skips lines that do not parse and the next write recovers the sequence from the last valid one.

Run, resume and human-input all share one journal for the same run, so the ids stay monotonic across the whole lifetime of a run no matter how many times it stopped and started.

In scale mode

A single process reads the journal directly. Scale mode publishes the same events to a Redis stream instead, because the reader and the worker are different processes. The read endpoints serve whichever of the two exists for a run, so the behaviour you see is identical.

What the journal is not

Two limits follow from that, and both matter if you are tempted to treat the journal as a record:

• 32 KB per event line. Past that, heavy fields — final state, shared state, previews, reasoning, output — are truncated deepest-first. The UI fetches full run state from the checkpoint endpoint instead.
• 20,000 events per run. Past the cap a run journals only structural events — starts, completions, errors — which is enough to reconstruct the run's shape without letting a chatty agent grow the file without bound.

For a durable record of what a run did, use Runs › Logs, which reads from the run's checkpointed state. Evals are built on that state for exactly this reason: a judge reading the journal would work on a laptop and quietly score nothing in production.

Builder conversations are not journaled at all — they are ephemeral UI sessions and bypass the run pump on purpose.

Resuming

Because state is checkpointed rather than held in memory, a run survives things that would otherwise end it:

• Human gates — a run waiting for a person survives a restart and resumes when they answer.
• Tool approvals — a call held for confirmation checkpoints the same way.
• Mid-step interruption — a run picks up at the step boundary it reached, not at the start.