Half of what Claude Code costs is running commands

I have been running Claude Code every day for two months and could not have told you, to the nearest thousand dollars, what it cost. Not because the information was hidden — it is sitting in JSONL files on my disk — but because nothing read it back.

So I wrote something that does, ran it against my own machine, and got numbers I did not expect.

$10,513 over 58 days

That is what my sessions would have cost at Anthropic's list prices. I pay $200 a month for a plan, so the ratio is not a saving — it is what the same work would cost billed per token, which is a different thing and worth saying plainly.

The number I actually care about is smaller and more useful: $181 a day, on the days I worked. That is a figure I can reason about. The ten-thousand is just what it adds up to when nobody is looking.

Half of every tool call is bash

This is the one that changed how I think about the tool.

• Bash — 40,213 calls, 49%
• Read — 11,681 calls, 14%
• Edit — 7,862 calls, 9%
• WebFetch — 6,052 calls, 7%
• WebSearch — 3,525 calls, 4%

Nearly half of what an AI coding agent does is not writing code. It is running commands: tests, builds, greps, git. The writing — Edit and Write together — is under 12%.

That is obvious in hindsight and I still had it backwards. I thought of Claude Code as something that writes code and occasionally checks its work. The measurement says it is something that runs your toolchain and occasionally writes code.

It also explains why sessions cost what they do. A command's output goes back into the context — every test run, every stack trace, every ls of a large directory. The writing is cheap. The reading of what happened next is not.

A session is not twenty minutes

Every demo shows a session as a short exchange. Mine average far longer than that, and the long ones are where the money is: a session that runs for hours accumulates context, and context is what you pay for on every subsequent turn.

The practical consequence is that "should I start a new session" is a cost decision, not just a tidiness one. I did not know that a month ago because I had no way to see it.

99% cache hit, and why it is not the win it looks like

My cache hit rate is 99%, which cut 89% of what input would otherwise have cost. That sounds like the headline. It is not, for two reasons.

First, it is not something I did — prompt caching is on by default and the prefix of a long session is naturally stable. Second, and more importantly: a 99% hit rate on a growing context still means the 1% grows too. Cache made the cost survivable rather than small.

What I would tell someone starting

Measure before you optimise anything. I spent a week assuming my costs came from long conversations and they came from command output. I would have optimised the wrong thing, confidently, and had no way to notice.

The tool I used is Caprock — one binary, reads the transcripts Claude Code already writes, nothing leaves the machine. It is free and open source, and the numbers above are exactly what it prints. Run it against your own history and you will get a different answer to mine, which is the point.