145,481 Turns and Counting
8 min read
I've been capturing every Claude Code turn and every tool call to a Postgres telemetry lake since January. When I last wrote this up, it held 38,925 turns across 60 sessions. I shipped the post and moved on.
It now holds 145,481.
That's not a vanity number. It's a measurement of how a single person actually builds with AI tools, day after day, on hardware in his house — and the shape of it surprised me again. Here's the second pass.
The Headline
145,481 telemetry rows across 342 sessions, January 19 through June 23. Every turn the model took, every tool it called, every token it read and wrote, written to a session_telemetry table in the same memory platform I built to make agents remember.
The growth since the last snapshot is the part worth sitting with. Since May 4: 57,179 new rows across 171 sessions. That's seven weeks adding more than a third of the entire five-month total. The lake isn't filling at a constant rate. It's accelerating — because I am.
Inside those rows: 49,030 tool calls, of which 18,806 happened since May 4. Same story. More than a third of all the tool activity in the lake landed in the last seven weeks.
I go hard. The data doesn't let me pretend otherwise.
Where the Tool Calls Go
Forty-nine thousand tool calls, and the distribution is brutally lopsided:
| Tool | Count | Share |
|---|---|---|
Bash |
23,979 | ~49% |
Read |
6,828 | 14% |
Edit |
5,337 | 11% |
store_memory |
2,233 | 4.6% |
Write |
1,646 | 3.4% |
TodoWrite |
1,345 | 2.7% |
ToolSearch |
1,090 | 2.2% |
Grep |
783 | 1.6% |
Agent |
652 | 1.3% |
query_memory |
524 | 1.1% |
Bash is nearly half of everything I do with AI. That's not noise — it's the signature of the work. I don't use AI to write essays. I use it to wire systems together: run scripts, check forge status, kick off builds, tail logs, restart daemons, prove a thing is alive before I trust it. That's an infra workload, and infra runs through the shell.
Read beats Edit, 6,828 to 5,337. I read before I write — code review on existing code before I touch it. It's the one habit in here I'm proudest of, because it's the one most people skip.
Then store_memory at 2,233. That's me, and the model on my behalf, deliberately writing things into Coquina that have to survive the session. Nearly five percent of all tool activity is manufacturing persistent knowledge. Everything else is consumption and transformation — read it, change it, run it, throw the receipt away. The memory writes are the part I went out of my way to keep.
ToolSearch cracking the top seven is the tell of a system that grew. It now runs a thousand-plus times, loading deferred MCP tool schemas before they can be called. That's overhead, not output — the tax you pay for an MCP ecosystem that got big enough to need lazy-loading. Worth naming honestly: not every measured action is productive. Some of it is the cost of the surface area.
Where the Tokens Go
This is the number that stops people.
cache_read: roughly 18.4 billion tokens.
Against ~20.1M fresh input, ~92.5M output, and ~843M cache_creation. The cache is being read on the order of twenty times more than it's being written. That ratio is the whole economic argument for how I work.
Here's the mechanic. Every turn of a long session re-reads almost the entire prior conversation as cached input — at a fraction of cold-path cost. So when I sit in one problem for three thousand turns, I'm not paying full freight three thousand times. I'm paying to read the cache, which is cheap, and paying full price only on the thin sliver of new content each turn. 18.4 billion cache_read tokens is the receipt for staying in the conversation.
The output-to-input asymmetry says the same thing from the other side. The model produced ~92.5M tokens against ~20.1M fresh input — it generated roughly four-and-a-half times more than I fed it new. The rest of what it "knew" each turn was cached history. The cache pays the input bill, and it pays it over and over.
If you switch contexts constantly, open and close terminals, start fresh every hour — you never build this ratio, and you leave the savings on the floor. The cache rewards depth. My data is a five-month argument for going deep.
The Biggest Sessions Are All One Thing
The largest sessions in the lake run about 3,700 rows each — a single day where the model and I went the distance on one problem. And every one of the biggest is homelab.
That's not an accident of sampling. It's structural. The infrastructure work — building the Forge runtime, debugging worker pipelines, keeping the 25-step overnight chain healthy, reasoning about LaunchAgents and GPU coordination and self-healing daemons — is genuinely longer-running than anything else I do. Application work has a finish line. Infra is a system you keep alive, and keeping it alive is a marathon, not a sprint.
The model split backs the same period of intensity. By turn volume: opus-4-6 led with 45.8k, then opus-4-8 at 19.7k, opus-4-7 at 13.6k, with sonnet-4-5, opus-4-5, and fable-5 filling the tail. The fleet rotated under me as new models shipped, and the lake caught every handoff.
62% of Everything Is One Project
The project breakdown is the line that reframes the whole dataset:
| Project | Rows | Share |
|---|---|---|
| homelab | 90,500 | 62% |
| cortex | 18,400 | 13% |
| osu | 15,800 | 11% |
| website | 5,400 | 4% |
| personal | 3,300 | 2% |
| cloudclub-osu | 2,700 | 2% |
Sixty-two percent of 145,481 rows is homelab. That single number is the most honest thing in the lake about where my attention actually went. Not where I'd say it went in an interview — where it measurably went, turn by turn, for five months.
homelab is the Forge runtime, the 32 autonomous workers, the overnight chain, the local LLM fleet, Coquina's infra, the whole self-hosted agent stack running on Apple M4 with zero cloud. cortex at 13% is the memory platform that makes all of it remember. osu at 11% is the Salesforce consulting that paid while I built. The split is a portrait: most of my energy went into infrastructure that runs itself, a meaningful slice into the memory layer underneath it, and a steady third into the client work alongside.
You can't argue with where the turns landed. That's the point of collecting them.
What the Second Look Taught Me
Three things I see now that I couldn't see from a single snapshot.
The shape is lopsided, and it holds. Bash is half of everything. Read beats Edit. cache_read dwarfs all of it. That's not the profile of someone using AI to write essays — it's the profile of someone using it to run systems. The habits are set; the only variable is how hard I push them, and since May I pushed harder.
Acceleration shows up before you feel it. A third of the entire lake landed in the last seven weeks. From the inside it felt like steady work. The data says otherwise — it says the back half of this period was the heaviest stretch of building I've done, by volume, all year. I wouldn't have known without the receipts. That's exactly why I collect them.
Concentration is a feature, not a bug. Sixty-two percent in one project would read as a lack of focus if the project were small. It's the opposite. It's what deep work looks like when you measure it — one system, returned to for months, until it runs without you. The cache ratio rewards it. The session sizes prove it. The project split names it.
The lake exists because the evidence of how you work vanishes the moment the terminal closes — unless you capture it. Summaries survive. Receipts don't, unless you build the thing that keeps them. I built it, and every snapshot tells me something I'd otherwise have to guess at.
145,481 turns of proof that the work happened, and a clear-eyed read on the shape of it. The next snapshot will be bigger. I already know which project it'll be.
If you're building autonomous AI infrastructure and want to talk telemetry, model strategy, or what these numbers mean for how a team actually ships — I'm at reed@grainlabs.io.