38,925 Turns and Where They Went

I dumped every Claude Code conversation I've had in the last few months into a Postgres database, indexed it, and queried it.

The numbers are kind of staggering — not because they're large in absolute terms, but because one developer running AI tools on a single Mac mini generates them in a few months.

Here's what fell out.

The Headline

38,925 turns. 60 sessions. 13,711 tool calls. 5.6 billion cache_read tokens. 191 million cache_creation tokens. 11.3 million output tokens. 173 thousand fresh input tokens.

That's all of my AI work — across the Cortex repo, homelab, OSU consulting, my personal site, side projects — packed into 85 megabytes of Postgres after it's indexed and the FTS columns are populated.

For perspective, 5.6 billion cache_read tokens is roughly forty times the total cold-path token volume. The Anthropic prompt cache earned its keep about forty times over the months it covered. That's not "doing my work." That's "doing my work cheaply."

Where the Tool Calls Go

Of 13,711 tool calls, the distribution skews hard toward five tools:

Tool	Count	%
`Bash`	6,543	47.7%
`Read`	1,836	13.4%
`Edit`	1,635	11.9%
`mcp__cortex__store_memory`	721	5.3%
`Grep`	628	4.6%
(everything else combined)	2,348	17.1%

Bash accounts for nearly half. That's not surprising for an infra-heavy workload — most of what I do with AI is wire stuff together, run scripts, check process state, kick off builds, inspect logs. Read, Edit, and Grep are the file-IO trio that dominates the rest.

The interesting one is mcp__cortex__store_memory at 5.3%. That's me (and Claude on my behalf) writing things into the curated memory layer. Five percent of all tool activity is creating knowledge that survives the session. The rest is consumption, manipulation, transformation.

That ratio surprised me. I would have guessed two percent. The memory layer is doing more work than I gave it credit for.

Where the Tokens Go

The cache numbers tell a different story than I expected.

5.6 billion cache_read tokens. 191 million cache_creation tokens. The cache is being read about 30× more than it's being created.

That ratio is what you want from a prompt cache. Each turn of a long conversation re-reads almost all of the prior conversation as cached input — at roughly 10% of the cold-path cost, with much higher throughput. The price-performance asymmetry of a well-utilized cache is the single largest reason solo AI work is economically viable on consumer hardware.

The output side: 11.3M tokens generated. Compare to 173k fresh input tokens. The model is producing sixty-five times more text than the new content I'm feeding it on each turn. The rest of its context is cached prior turns. That's a stable pattern across sessions — the cache pays the input bill.

The Biggest Sessions

The five longest sessions by turn count:

Turns	Project	Topic
3,199	homelab	(long-running maintenance/upgrade work)
1,764	cortex	(a refactoring sprint)
1,664	homelab	(another long maintenance pass)
1,595	cortex	(where-are-we audit and fix)
1,583	homelab	(extended deploy session)

Three out of five are homelab. The infrastructure work is genuinely longer-running than the application work — wiring services, debugging worker pipelines, reasoning about LaunchAgents, keeping the overnight chain healthy. Nothing about that surprises me; it matches the felt experience.

The longer sessions also burn more tokens per turn on average. The 3,199-turn homelab session produced roughly 1.2M output tokens by itself — a chunk of the 11.3M total. A small number of "long days" account for a disproportionate share of total spend.

What This Tells Me About How I Work

A few things I didn't fully see until I had the data.

My cache hit ratio is excellent. 30:1 read-to-creation. The way I work — long sessions on a single problem, with continuous context — is exactly what the cache rewards. People who switch contexts a lot, or open and close terminals constantly, are leaving cache savings on the table. The cache wants you to stay in one conversation.

Tool call distribution mirrors actual workflow shape, not what people say their workflow shape is. I would have guessed Edit was higher than Read. It's not. I read more than I write, by a 1.12× margin. That's healthy — code review on existing code, before changing it.

Memory writes are 5% of tool activity but probably 50% of the long-term value. The 38,925 turns will probably mostly never be re-read by me. But the 721 memory writes are the things I went out of my way to make persistent. Those are doing the real load-bearing in future sessions.

Bash dominates because infra dominates. If you're using AI primarily for creative writing, your tool distribution would be inverted — Read and Edit would be everything, Bash would be irrelevant. My distribution is the distribution of someone debugging real systems. That's useful self-knowledge.

What's in the Lake That Isn't in the Curated Memory Layer

The reason the lake exists is that the evidence of those workflows is gone the moment the terminal closes — unless I store it. Until today, I was storing summaries (decisions, learnings, facts) but discarding the receipts (every command, every output, every reasoning step).

What I now have, for the first time, is the ability to ask:

"What was the exact debugging sequence I followed when I hit that Postgres error two weeks ago?"
"Which Bash command did I run before that thing started working?"
"What did the auto-fix worker output when it ran on PR #25?"
"How long did it actually take me to ship the rename audit tool, hour-by-hour?"

These questions are answerable from the lake. They were never answerable before, because the data simply wasn't being collected.

That's the point of evidence. You don't know which line you'll need until you need it.

The Long Tail

A few items from the data that didn't fit anywhere else but are worth noting:

Glob ran 8 times. I almost never use it. Most of my pattern-matching goes through find or grep via Bash. Probably worth retraining myself — Glob is faster and more structured for what I usually do with find -name.
mcp__cortex__query_memory ran 197 times. 27% of the rate of store_memory. So I'm querying the curated layer about a quarter as often as I'm writing to it. That ratio feels low — I should be reading more than I'm writing if the memory layer is doing its job.
The Agent tool ran 312 times across the period. Most of those are subagent spawns — research, code review, exploration. About 5× per session on average. The "swarm of small agents" pattern is doing real work in my flow.
No model field is populated for ~40% of turns. That's because user-side turns and tool-result turns don't carry a model identifier — only assistant turns do. The data is correct; the absence is telling me about the schema, not about the model.

What I'm Doing With This

For now, mostly looking at it.

The dashboard ships with a Telemetry tab that lists sessions by recency and lets you drill into any single session's turn list. That's the surface for browsing. The next layer is search — querying across sessions for specific patterns. The lake's full-text index is already populated; the dashboard just needs the search box.

After that: charts. Recharts is already in the bundle for the analytics tab. A simple "tokens-per-day" or "top-tools-this-week" view would give me a feel for whether my workflow is improving or drifting.

After that: integration. The lake should feed back into the curated memory layer when there's a clear pattern. If I run the same five Bash commands every Monday morning, that's a procedure worth promoting from receipts to opinion. The migration from raw to curated is the next system to build.

For now, though, just having the receipts is the thing.

5.6 billion tokens of evidence that I worked. That's the part I want to keep.

This is part 9 of a series on building autonomous AI infrastructure on consumer hardware. The numbers in this post are from a single developer running AI tools daily for a few months; if you're using these tools too, your numbers are bigger than you think.