Skip to main content

Sessions and replay

Every run writes an append-only JSONL transcript. That file is the record: what was asked, what the model did, what the tools returned, what had entered the conversation, and what the run was configured with. Everything downstream — resuming, reflect, distill, and replay — reads it rather than a second copy that could disagree with it.

mecha sessions list
mecha sessions show 20260805T091500
mecha sessions path 20260805T091500
mecha sessions stats --days 30 # what runs cost
mecha sessions health --days 30 # how runs went

Transcripts live in ~/.mecha/sessions (override with MECHA_SESSION_DIR), in a directory created owner-only. --no-session opts out.

The file

One JSONL file per session: a header line, then one line per record. Append-only, so a crashed run still leaves a readable transcript. Ids are 20260805T091500-3f2a1b7c — sortable by name, and still unique when two runs start in the same second.

Seven record kinds:

{"record":"meta","id":"20260805T091500-3f2a1b7c","created_at":"...","provider":"anthropic","model":"claude-opus-5","workspace":"/home/you/project","title":"summarize what changed"}
{"record":"config", ...}
{"record":"message","role":"user","content":[{"type":"text","text":"..."}]}
{"record":"taint","private":true,"untrusted":false}
{"record":"rewrite","messages":[...]}
{"record":"summary","usage":{...},"turns":4}
{"record":"outcome","turns":4,"stop_cause":"end_turn","tool_calls":11,"tool_errors":1,"tool_denied":0,"ended_on_failed_call":false,"compactions":0, ...}

The rewrite record is how an append-only file expresses an in-place edit: compaction, eviction, and thinning all rewrite earlier messages, and slicing "what the run added" off a rewritten list would record a lie — the stale head kept, the rebuilt one lost. The record carries the whole current list, and loading replaces what was accumulated so far. The states a rewrite replaced are recorded too: the loop keeps each pre-rewrite message list on the conversation, and the end-of-run recording walks them before the final state — so a run long enough to compact itself still gets its whole head into the file.

load skips unparseable lines rather than failing — a truncated final line is the normal result of a killed process. A file whose first record is not a header is not a session mecha wrote, and is skipped.

Listing goes through peek_meta, which reads only the first line. That keeps mecha sessions list at O(number of sessions) rather than O(total transcript bytes); with reflect-on-close recording every interaction, a full parse re-read the whole store to print one line per file.

recall: the record is searchable

Sessions recorded by chat, the TUI, and resumed runs register a recall tool: a case-insensitive search over the union of everything the transcript ever recorded — including the messages a compaction rewrite replaced. When a summary drops the one detail the run later needs, the model looks it up instead of re-running tools or re-living the stretch.

Two properties make it safe to hand to the model. It is taint-neutral by construction: everything it can return entered this conversation once, and that arrival is what armed the interlock — taint never un-arms, so re-surfacing recorded content changes nothing the interlock knows. And the transcript path is fixed at registration, never taken from model input, so no other conversation's content is reachable. It is deliberately absent from Slack (one shared registry serves every thread; a per-run insert would point one thread's recall at another's transcript) and from fresh one-shots and triggers, whose per-run record is empty until the run ends.

The taint record

Taint is recorded because it cannot be recovered by reading the transcript back. Taint keys off provenance — whether a result actually came from outside the machine — and the transcript stores only content. Without the record, resuming a session that had read a hostile page would hand the model that page again with the interlock disarmed.

Every front end appends a taint checkpoint after the messages of the run it describes. On load, checkpoints are merged rather than replaced: taint only ever grows, a later clean checkpoint cannot disarm an earlier armed one, and a transcript written by an older build simply has none.

Session::taint_timeline positions those checkpoints against the messages. The checkpoint covering a message is the first one written after it — and by then the taint of everything earlier in that run has merged in. That ordering is what makes it safe to gate on: it can over-taint a message, never under-taint one. A message with no checkpoint after it returns None, which the caller must treat as unknown, and unknown provenance is never clean. This is what mecha learn uses to exclude non-clean reflections structurally — see Learning.

The outcome record

summary answers what did this run cost; outcome answers did it work. They are two records rather than more fields on one because the audience is different — cost is for a person reading sessions show, and the outcome is for a machine reading a thousand sessions at once.

It carries the stop cause, whether a budget was reached, tool calls attempted against errors, denials and stagings, malformed arguments, blocked sends, compactions taken, the end-of-run taint, and whether the run stopped of its own accord with its last call failed. Written by every front-end: before it existed, an interactive run was measurably less observable than a trigger, whose ledger already recorded most of this.

Two counters that must not be added together: tool_errors is the environment refusing, and tool_denied is a human or a policy refusing — which is the harness working. Everything downstream keys on that split.

mecha sessions health reads these back across the store, and the loop built on top of them is Run quality.

mecha sessions health --days 30

The config record

Selected fields are shown here; the record also includes tool-surface fingerprints, active harness levers, and the workspace and surface used to match learned rules.

pub struct RunConfig {
pub mecha_version: String,
pub provider: String,
pub model: String,
pub workspace: PathBuf,
pub system_prompt: Option<String>, // the resolved text, not a path
pub tools: Vec<String>, // in registry order
pub effort: Option<Effort>,
pub temperature: Option<f64>, // what was actually sent
pub seed: Option<u64>,
pub thinking: bool,
pub cache_prompt: bool,
pub max_tokens: u32,
pub max_turns: u32,
pub max_output_tokens: Option<u64>,
pub max_cost_usd: Option<f64>,
pub compact_at_tokens: Option<u64>,
pub compact_keep_recent: usize,
pub permission_mode: PermissionMode,
pub trifecta: TrifectaPolicy,
pub sandbox: String,
pub sandbox_network: bool,
}

The rule behind that field list: anything that shapes the request or constrains the run is a confound if it is not recorded. Not theoretical — compaction on versus off measured 1/5 against 5/5 on the same task, so a replay that did not know whether compaction was enabled would compare two incomparable runs and report a model regression. A denied call redirects the whole trajectory, so replaying a read-only session under --yes compares nothing. And shell declares narrower capabilities when confined, with the interlock believing them, so the same prompt can be refused under one sandbox and allowed under another.

The system prompt is stored in full rather than hashed. A hash tells you only that something differed; the text lets a replay rebuild the request. It is no more sensitive than the transcript beside it.

It is a record per attach, not a header field. A session resumed under different flags would make a header written at creation a lie about every turn after the first; within one process the configuration cannot change, so one record per attach is exactly the granularity that can differ.

The sampler is recorded only as far as it is pinned. None means the server chose, and the run is not repeatable.

The summary record

Record::Summary { usage, turns } is written when a run finishes, so sessions show and sessions stats can report cost without replaying the transcript. usage_totals sums every summary in a file; a transcript that predates the record or died before writing one totals zero — an honest under-count, never a guess.

mecha sessions stats rolls that up by provider and model, priced at today's configured rates. The transcript records tokens, not prices, so historical runs are re-priced rather than remembered — the table says so. A provider with no configured prices shows rather than $0.00; a local model with no prices really does cost nothing, and only rows with a price claim a dollar figure. A torn transcript still contributes what it recorded.

Replay

mecha replay 20260805T091500
mecha replay 20260805T091500 --on-divergence=error --json
mecha replay 20260805T091500 -p anthropic # same work, another model

Replay re-drives a recorded session with model calls and tool results taken from the recording. In the default stop mode, replayed tool calls do not execute their underlying tools. Model requests still cost tokens, and setup can connect configured MCP servers.

The result is a controlled comparison over recorded evidence, with limits: replay reapplies output limits and untrusted-content warnings, so the bytes shown to the model can differ from the original transcript. Modern recordings preserve per-call provenance. Legacy results with unknown provenance count as external, including old harness refusals; this can add a warning or a second warning envelope. In live mode it can also block a send the original allowed. The CLI reports this, and JSON includes legacy_provenance_calls and provenance_note. Compare arms under the same replay policy before attributing a difference to the model.

Recordings that dispatched harness plan checks cannot yet be replayed or used for trace-based counterfactual probes. Their check observations are part of the decision context, and replay cannot reconstruct them yet. These comparisons return an explicit unsupported result; independent artifact-task grading remains available.

How the run is rebuilt

From the session's RunConfig, not from today's flags: system prompt, tool list, effort, thinking, budgets, compaction settings. If a session has several config records, replay uses the first and prints a note. A session with no config record cannot be replayed.

In stop and error modes, saved tool schemas and descriptions take precedence when the surface store still holds the recording's tools_hash. They can also stand in for tools no longer available. If neither setup nor a recorded or supported display-only surface can supply a tool, replay refuses.

live mode uses today's tool definitions and requires executable tools, because it can actually call them after divergence. Recorded descriptions never grant capabilities or permissions to a live tool.

Provider and model default to the recorded ones and can be overridden. Replaying one model's session on another is how you compare them on real work — and when -p names a different provider, the model defaults to that provider's own, because sending the recorded name would name a model the other server does not serve.

Extraction

replay::extract reduces a transcript to a Trajectory: the user's turns, every tool call paired with its recorded result, and the final assistant text.

The distinction doing the work: a user message carrying tool_result blocks is the harness feeding results back, not the user saying something. Treating those as turns would replay a conversation with twice the turns and none of the same structure. Results are matched to calls by id rather than position, because calls are issued in parallel and nothing promises the results come back in order.

Text sitting alongside tool results is mid-run steering, and it sets trajectory.steered. Steering rides in the same user message as the results it accompanies (there is no legal slot between a tool_use and its result), which makes it indistinguishable from a turn once flattened, and re-submitting it as one would change the shape of the conversation being replayed. It is flagged rather than silently dropped, and mecha replay prints a note:

note: the recording was steered mid-run; steering cannot be re-injected, so the
comparison is approximate

Divergence

pub enum Divergence {
Tool { index, expected, actual }, // a different tool entirely
Arguments { index, tool, expected, actual },// right tool, different arguments
Extra { index, actual }, // the replay kept going
Missing { index, expected }, // the replay stopped early
}

The comparison preserves order between assistant turns. Within one recorded parallel batch, calls may arrive in a different order. Matching prefers the same tool and arguments, then the same tool name; each result keeps its own provenance. Legacy calls without batch markers remain positional.

Argument differences are reported separately and do not stop replay. The same file can have different path spellings, but changed arguments can also mean a different action. Replay returns the matched recorded result and leaves that judgment to the reviewer; an argument mismatch is not proof of equivalence.

--on-divergence decides what happens at a structural divergence:

ModeBehaviour
stop (default)end the run there — after a divergence, every later recorded result answers a question nobody asked
errorthe same, and exit non-zero on any divergence, argument spellings included
liveabandon the recording and continue against the real tools

Underlying tool calls do not execute in stop or error mode. live falls back to the configured permission mode: real tools run after the divergence and deserve exactly the scrutiny they always get.

A replayed episode comes back gradeable

The report carries the replayed episode's outcome counters — the same RunStats a live run records — alongside the calls and the final text. Without them a replay was gradeable only by a divergence diff, which answers "did it do something else" and not "did it go better".

That is what lets a replayed corpus be one arm of the candidate gate: each episode names itself, produces a cost, and is paired against the same episode in the other arm. Note the limit this arm has by construction — replay holds the tool results fixed, so it cannot see a change in what the model said. A prose change needs the eval --ab-config arm instead.

What replay is not

Replay against a non-greedy provider is pass@k-shaped, not exact-match-shaped. A local server's sampler is outside this process's knowledge, and the same case measures 5/5 rather than deterministically. One divergent replay is a sample, not a regression.

A replayed result is also not provenance. The transcript does not record which results actually came from outside, so replayed outputs carry no external marking and a replay's taint may be less armed than the recording's was. Refusals the interlock produced at record time were recorded as results, so they replay verbatim regardless.

The standing regression check

scripts/replay-regression.sh replays a set of pinned sessions against the current build and fails on any divergence.

scripts/replay-regression.sh # replay every pinned session
scripts/replay-regression.sh <id> [...] # replay just these

Pins live in ~/.mecha/regression-sessions.txt, one session id per line — machine-local on purpose, because transcripts are personal data and do not belong in the repository.

Adding a pin means recording a session that uses only built-in tools, verifying it replays clean once, and appending its id:

mecha run -p local --no-mcp --no-learned-rules \
--tool fs_read --tool fs_list -w eval/workspace "<task>"

Built-ins only, because an MCP surface makes a pin break whenever a server is rewired — which is drift, not regression.

The script refuses to run unless llama-server is on one slot (-np 1). Seeded replay is only repeatable sequentially against a single slot; continuous batching makes concurrent requests perturb each other's numerics, seed or no seed. Refusing beats reporting fake divergence.

A pin that diverges means the harness — prompt assembly, tool dispatch, request shape — or the model changed. Read the JSON before deciding which.