The Rollout
Your agent history is a dataset. Almost nobody queries it.
For every instruction I typed into Codex over the last eleven months, it logged an average of 34 events: 2.7 assistant messages, 10.7 tool calls, and about 19 entries of bookkeeping around them. Claude Code’s ratio is different in shape but similar in scale — 13.5 assistant events and 5.7 tool results per instruction. I know this because the full record of every session is sitting on my disk in parseable form, 3.8 GB of it, and I finally parsed it.
The point is not the volume. The point is that this is a dataset about how you build software, generated as a free byproduct, complete with timestamps, tool inputs and outputs, and (in the better formats) per-message model and token accounting. Developers who would never dream of running a service without metrics are sitting on months of their own engineering telemetry and have never run a single query against it.
The first obstacle is usually just knowing where the files are. Each agent stores its sessions somewhere different, and the paths and formats are written up per agent in the local history guides.
Five questions your history can already answer
What did that feature actually cost? Sessions in the newer formats carry token counts and sometimes dollar figures per message. Group by day or by repo and you have cost-per-feature numbers that no dashboard gives you, because the vendor dashboard doesn’t know your project boundaries.
Which commands keep failing? Every failed build, every flaky test run, every permission error is in the tool-output events, with timestamps. The third time a session trips over the same broken script is visible in the data before it is visible in your patience. This one has direct payoff: the recurring failure is usually a one-line fix in the repo’s agent instructions.
What did we decide, and when? Search is the killer feature of an archive. “The session where we rejected the geometry redesign” is findable by keyword in seconds with an indexed browser, and the full context — what was tried, what the output showed, why it died — is all there. Git remembers the outcome; the transcript remembers the argument.
How has your prompting changed? Instructions from month one read differently than month eleven: shorter, more specific, front-loaded with constraints. Your own history is the before/after corpus, and skimming it is a faster prompting course than most prompting courses.
Where does the time go? Timestamps on every event mean a session has a measurable shape: how long between your instruction and the first tool call, how long the agent spent in test loops, how much wall-clock a “quick fix” session really took. Aggregate a month of that and you know which kinds of tasks to delegate differently, or not at all.
Why nobody does this
Three honest reasons. The formats are undocumented, so writing a parser means reverse engineering six dialects of JSONL and SQLite (we covered the details in the field study). The volumes are awkward: 3.8 GB is too big to grep casually and too small to justify a data pipeline. And the tooling is young: the vendors treat these files as crash-recovery state, not as a product surface, so nothing ships with a search box over your own history.
The parsing problem, at least, is solved for the reading half. Agent Sessions indexes all six formats into one searchable, local-only browser — that’s the “what did we decide” and “which command failed” questions handled without writing a line of code. The aggregate questions still need a script, and the one this post’s numbers came from is in the repo as a starting point.
A year of your engineering decisions is on your disk, already written down, already machine-readable. That is more than most teams can say about their human decisions. It seems worth a query or two.