92,653 Turns and Where They Went
9 min read
I dumped every Claude Code conversation I've had since January 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 four months.
Here's what fell out.
The Headline
92,653 turns. 175 sessions. 31,849 tool calls. 11 billion cache_read tokens. 394 million cache_creation tokens. 27.5 million output tokens. 1.2 million fresh input tokens.
That's all of my AI work — across the Coquina repo, homelab, OSU consulting, my personal site, side projects — packed into 215 megabytes of Postgres after it's indexed and the FTS columns are populated.
For perspective, 11 billion cache_read tokens is roughly twenty-eight times the total cold-path token volume. The Anthropic prompt cache earned its keep about twenty-eight times over the months it covered. That's not "doing my work." That's "doing my work cheaply."
Where the Tool Calls Go
Of 31,849 tool calls, the distribution skews hard toward five tools:
| Tool | Count | % |
|---|---|---|
Bash |
14,497 | 45.5% |
Read |
4,837 | 15.2% |
Edit |
3,919 | 12.3% |
mcp__cortex__store_memory |
1,432 | 4.5% |
TodoWrite |
1,276 | 4.0% |
Write |
1,190 | 3.7% |
| (everything else combined) | 4,698 | 14.8% |
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 Write are the file-IO trio that dominates the rest.
The interesting one is mcp__cortex__store_memory at 4.5%. That's me (and Claude on my behalf) writing things into the curated memory layer. Nearly five percent of all tool activity is creating knowledge that survives the session. The rest is consumption, manipulation, transformation.
TodoWrite cracking the top five at 4% is new — it reflects a shift toward more structured task tracking within sessions. It wasn't even in the original top ten back when this post first ran at 38,925 turns.
Where the Tokens Go
The cache numbers tell a different story than I expected.
11 billion cache_read tokens. 394 million cache_creation tokens. The cache is being read about 28× 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: 27.5M tokens generated. Compare to 1.2M fresh input tokens. The model is producing twenty-four 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 Model Split
Something that wasn't in the original version of this post: model-level breakdown.
| Model | Turns | Output Tokens |
|---|---|---|
| Claude Opus 4.6 | 33,279 | 7.3M |
| Claude Opus 4.7 | 13,541 | 20.1M |
| Claude Sonnet 4.5 | 6,239 | 28K |
| Claude Opus 4.5 | 2,777 | 18K |
Opus 4.7 is interesting: fewer turns than 4.6 but nearly three times the output tokens per turn. That's a chattier model — more verbose by nature. Whether that verbosity is useful or wasteful depends on the task. For code generation, more tokens often means more speculation. For analysis, it means more coverage. The jury is still out, but the data makes the difference measurable.
The Biggest Sessions
The five longest sessions by turn count:
| Turns | Project | Topic |
|---|---|---|
| 3,699 | homelab | (infrastructure marathon) |
| 3,230 | homelab | (extended build + deploy cycle) |
| 3,199 | homelab | (long-running maintenance/upgrade work) |
| 3,016 | homelab | (overnight chain + worker buildout) |
| 2,626 | osu | (Salesforce platform work) |
Four 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. The top session hit 3,699 turns and produced nearly a million output tokens by itself.
The longer sessions also burn more tokens per turn on average. A small number of "long days" account for a disproportionate share of total spend.
The Monthly Shape
| Month | Turns | Sessions | Tool Calls |
|---|---|---|---|
| January | 5,075 | 14 | 1,412 |
| February | 19,319 | 77 | 5,938 |
| March | 11,482 | 20 | 3,929 |
| April | 41,774 | 57 | 14,876 |
| May (4 days) | 15,003 | 8 | 5,694 |
April was the monster: 41,774 turns in one month. That's the period where Forge grew from a handful of workers to a full 25-step overnight chain, the website got rewritten, the Coquina rename happened, and a dozen blog posts shipped. May is on pace to match it — 15,003 turns in four days.
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. 28: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.23× margin. That's healthy — code review on existing code, before changing it.
Memory writes are 4.5% of tool activity but probably 50% of the long-term value. The 92,653 turns will probably mostly never be re-read by me. But the 1,432 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 the lake was built, I was storing summaries (decisions, learnings, facts) but discarding the receipts (every command, every output, every reasoning step).
What I now have 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:
Globran 343 times. Up from 8 in the original count — I've been retraining myself to use structured tools over rawfindvia Bash.mcp__cortex__query_memoryran 371 times. 26% of the rate ofstore_memory. So I'm querying the curated layer about a quarter as often as I'm writing to it. That ratio still feels low — I should be reading more than I'm writing if the memory layer is doing its job.- The
Agenttool ran 480 times across the period. Most of those are subagent spawns — research, code review, exploration. About 2.7× per session on average. The "swarm of small agents" pattern is doing real work in my flow. ToolSearchran 614 times. This one is new to the top ranks — it reflects the growing MCP ecosystem where deferred tool schemas need to be loaded before use. It's infrastructure overhead, not direct productivity, but it's measurable.- 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
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. 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.
11 billion tokens of evidence that I worked. That's the part I want to keep.
This is part 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 four months; if you're using these tools too, your numbers are bigger than you think. Updated May 4, 2026 from the original 38,925-turn snapshot.