I had a theory about which of my projects was expensive. I was wrong about nearly all of it, and the thing I had been carefully rationing turned out to be about one percent of the total.
Here is what I found when I stopped guessing and counted.
The thing I was rationing cost almost nothing
I have been converting my old Minecraft videos into written episode recaps. Those videos are from 2017, most of them have no usable captions, and working out what happened in an episode without a transcript is expensive. So I slowed the project down. I started running a couple of episodes at the end of the week, only if I had capacity left over.
That project is roughly one percent of my usage.
The number that made me laugh: a single session back in July, where I converted 55 RV videos into blog posts, cost four times more than every Minecraft episode I have ever produced. I had been protecting my budget from the small thing while the large thing had already happened months earlier and I never noticed.
A single session cost 2.3 million tokens and was invisible
This is the finding that made the whole exercise worth doing.
When an agent works across several repositories at once, it clones them into temporary working directories. Each of those clones gets recorded as its own separate project. So one session, doing one piece of work, gets shredded into dozens of entries that each look small.
I had one session split across sixty directories. Individually they ranged from ten thousand to three hundred thousand tokens, none of them large enough to notice. Added together they were 2.3 million, which made that session the single most expensive thing I did that week, ahead of the project I thought was my biggest consumer.
There was no way to see this without deliberately folding those directories back into the project that spawned them. The information was there the whole time. The parent project name is encoded in every temporary directory path. Nothing was reading it.
My most expensive days are my best days
I expected token usage to track how much work got done. It tracks how hard the work was, which is not the same thing.
One day in early July produced 89 commits and cost 1.7 million tokens. That is about 19,000 tokens per commit. Another day produced 14 commits and cost 2.2 million, which is 159,000 per commit. Eight times the cost for a fifth of the commits.
The cheap day was mechanical: renaming, tidying, small fixes. The expensive day was the multilanguage system, the Search Console integration, and a rewrite of how the publishing pipeline syncs files. Those touch the exporter, the API, the renderer and the data model at the same time, and they are expensive because they are genuinely difficult.
So the days that look alarming on a usage graph are the days I shipped the things I most wanted to ship. There is nothing to cut there. That is just what building something hard costs.
The corollary is that commits per day is a terrible productivity measure, and tokens per commit is a worse one. I could halve my token usage tomorrow by only doing easy work.
I was measuring the wrong number
Here is where I had to correct myself.
I ranked everything by output tokens, which is the count of what the model actually writes. That is the intuitive measure and it is what most tools show you. It is also the number that does not move when you leave a session running for hours.
What grows in a long session is the input side. Every turn re-reads the entire conversation so far. I found sessions sitting at 996,000 tokens of context, which is the ceiling, meaning every subsequent message in those sessions was re-reading a near-maximum context window. One session ran 7,716 messages and accumulated 3.7 billion cached reads.
When I measured context carried per unit of work instead, the ranking changed. The project I had assumed was cheap turned out to have the highest ratio of all: it does a lot of reading and thinking per line of output, which never showed up in the number I had been watching.
The practical version of this: clear the conversation between tasks, not between days. The signal is whether the next thing you are doing shares context with the last thing. A session that ran for hours across a dozen unrelated tasks paid to re-read all of the earlier ones every single time.
Not all tokens cost the same
The last correction was the simplest and I had ignored it entirely.
Different models have different prices, and the spread is wide. Weighting by actual relative cost changed one project from four percent of my week to seven percent, because it happened to run entirely on the most expensive model. Everything else shifted a little. Comparing raw token counts across projects that used different models is comparing two different units and calling them the same.
What I would tell someone before they optimize anything
Measure first, and expect to be wrong. I had a confident theory about my own usage built on months of working in these codebases every day, and it was wrong in four separate ways. Not slightly wrong. Wrong about which project, wrong about which activity, wrong about which number to look at, and wrong about which direction to act.
The expensive thing is usually the invisible thing. Nothing about my setup was hiding that 2.3 million token session. It just did not appear in any total, because totals are computed per directory and one session had sixty of them. Look for the thing your measurement cannot see rather than optimizing the thing it shows you clearly.
A number without its own error bar invites being trusted too much. When I built the tooling for this, the piece that tries to attribute spend to individual commits gets it right about eighty percent of the time. The first version quietly labelled the other twenty percent with its best guess. The totals looked fine. Some of the labels were wrong, and there was no way to tell which. It now prints its own coverage on every run and reports the ones it could not identify instead of guessing. That change mattered more than any accuracy improvement.
Relative is not absolute. All of this compares my projects against each other. It is not a bill and does not claim to be. Knowing that project A costs twice project B is useful and actionable. Turning that into a dollar figure requires information I do not have, and pretending otherwise would make every conclusion above less trustworthy, not more.
The tool
I put it on GitHub as claude-code-token-usage. It reads the local transcript files, folds the temporary directories back into their parent project, splits by model, and can attribute spend to individual commits.
There are already a lot of good Claude Code usage monitors. Nearly all of them answer how much of your current window is left, which is a genuinely useful question and not the one I had. Mine answers which project consumed the week and what came out of it.
It also has an anonymize flag, which I added before making the repository public and would recommend to anyone building something similar. My own raw output is a list of my employer, my company, and a set of client brands. That is fine on my laptop. It is not fine in a screenshot.