Agent Sessions
The Rollout
Notes from building Agent Sessions: usage math, local agent-session formats, and what shipped.
-
A 4 KB database, a megabyte of rows: which SQLite readers go blind to the WAL
A SQLite database in WAL mode can hold a megabyte of committed rows while the main .db file is a 4,096-byte header page, and the readers that miss that data are not the ones folklore blames. We measured every reader configuration we could think of against a live writer: what decides the answer is whether the -wal file is there, not whether the connection is read-only, and the two readers that answer confidently with the wrong data are immutable=1 and a read-write connection to a .db copied without its log. Our own notes carried the wrong culprit for over a month, and the first correction was wrong too.
-
Session-Bench: 20 pass/fail gates for coding-agent session formats
Session files are the only durable record of the conversation behind your code, and most vendors treat them as a private implementation detail. So we built a benchmark: twenty scored pass/fail gates over the session formats of ten harnesses, generated by an evaluator from measurements, fixtures, and up to four months of weekly drift monitoring (windows vary per harness). The smallest harness has the cleanest format. Cursor ranks last. And the two harnesses at the top of the board are the ones that document their formats.
-
Agent-legible repositories: your repo now has two kinds of readers
Every agent session reads your repository from scratch, with no memory of the last one. That makes the repo itself the interface, and some repos are drastically more legible to agents than others. This post lays out the five memory surfaces of an agent-legible repo — instruction files, playbooks, executable scripts, handover state, and the transcript archive — with the failure modes each one prevents.
-
Your agent history is a dataset. Almost nobody queries it.
Every session with a coding agent leaves a complete machine-readable record on your disk. Measured over eleven months on one machine: a single typed instruction to Codex produces 34 logged events, including 11 tool calls. That corpus can answer real questions — what a feature cost, which commands keep failing, how your prompting changed — and it goes unqueried on almost every developer's machine.
-
The handover problem: agent sessions end, projects don't
A long-running project outlives every agent session that works on it. Each new session starts with amnesia and re-derives context you already paid for. This post describes the handover file pattern we use in production — a dated, append-only log of state, decisions, and next steps — and compares it honestly against built-in memory features, transcript mining, and re-reading git history.
-
Recovering an AI coding-agent session you thought you lost
A session that disappears from your agent's resume picker is almost never actually gone. It was archived, or it's filed under a project path that no longer matches where you're standing. Here is how to tell the two apart, get each one back, and what to do in the one case that is genuinely unrecoverable.
-
A prompt-injection-safe GitHub triage agent: give the model no tools
In January 2026 a researcher took over a GitHub repo by opening one issue at a triage bot. The fix for that class of bug isn't better input filtering; it's giving the model nothing to act with. Here's a daily triage agent built tool-less by construction — text in, text out, a human posting at the end — and the adversarial test that checks the confinement against the live model before it runs.
-
How coding agents remember: a field study of six session-history formats
Six coding agents on one Mac wrote 3,096 session transcripts over eleven months. We parsed all of them and measured what each format actually records: how many bytes it takes to remember one human sentence, which agents know what they cost, why most reasoning is now sealed even on your own disk, and which format can actually find anything again. With a feature scorecard and concrete recommendations for each vendor.
-
Where AI coding agents store your session history: the real paths and formats
Every coding agent writes a full transcript of each session to a local file, but no two agree on where it goes or what format it takes. This is a grounded tour of the actual paths and formats — Claude Code's per-project JSONL, Codex's date-sharded rollout files under ~/.codex/sessions, OpenCode's SQLite database, Cursor's two-store split, and a few others — with the parsing gotchas that bite when you try to read them yourself.
-
Projecting the Claude 5-hour limit: burn rate, not percent used
A usage percentage like "7% used" is a level, not a rate: it cannot tell you whether you will reach the reset before the rolling window fills. This is the burn-rate math behind Agent Sessions' Session Runway — how per-session token logs become a quota-minutes-per-hour rate, how run-out gets projected, and why the Claude side stays honest about being coarse by design.