225 billion Claude Code tokens in 30 days: what the number actually measures

In my busiest 30 days, 15 September to 14 October, my Claude Code agents used 225.1 billion tokens over 736,633 API responses. That was one person: me, a Mac, a home PC and, on a heavy day, ten or more agents working at the same time.

For scale: the top user on Meta's internal token leaderboard reportedly used about 281 billion in a month, and Meta took that leaderboard down after a backlash. When I took my own number apart, most of it measured something other than work. What was left taught me more about running agents than anything else this year.

What the 225 billion tokens were: 97.9% cache reads

Across 225.1 billion Claude Code tokens and 736,633 API responses, 97.90% were cache reads, 1.75% were cache writes, 0.34% were output and 0.01% was fresh, uncached input.

The model is stateless. On every turn the agent sends the whole conversation again: system prompt, tool definitions, every file it has read, every earlier message. The prompt cache serves the part that has not changed, and that part is almost everything.

The average response took in about 305,000 tokens of context, 299,000 of them from the cache, and wrote about 1,000. For every token the model wrote, it re-read 291 from the cache.

That is also why the bill is survivable. Claude Opus 5.5 did 73% of my tokens, and on Opus 5.5 a cache read costs 5% of the input price (Claude API pricing):

At list prices my month comes to about $97,000 by ccusage's count. Without the cache it would be roughly ten times that. I don't pay list price: I'm on multiple coding plans with flat fees, so the dollar figure is only a yardstick.

So the first learning is a boring one. A token count is context size times turns times agents. It tells you how much you re-read, not how much got done.

It matters on a flat plan too, because re-reads still count. Claude Code sends the whole conversation with every request, so, in the words of its cost docs, "a one-line question in a session that has been open all day still draws usage for the whole conversation". With 291 tokens re-read for every one written, the habits that pay are the ones that keep context small: /clear between unrelated tasks, and verbose work like test runs, logs and doc lookups pushed into a subagent, so only a summary comes back.

Where the volume came from: parallel agents, around the clock

In the week of 31 August my agents used 4.0 billion tokens. Four weeks later they used 60.8 billion in a week.

The work per agent barely changed: tokens per agent-hour stayed between 52 and 80 million every week. Two other things changed. The number of agents running at once went from 2.0 on average to 6.9. And the hours with at least one agent running went from 38 a week to 145, almost 21 hours a day, so agents kept working while I slept.

Multiply the three and you get the total: 2.0 agents × 38 hours × 52 million tokens ≈ 4.0 billion in the first week, and 6.9 × 145 × 60 million ≈ 60 billion four weeks later. On the median day, 11 or 12 separate sessions answered within the same 10-minute window.

For a long time the bottleneck was me: more than a few agents at once overwhelmed me. In my finance studies I learned about span of control, the number of people one manager can lead. The answer depends on the work: McKinsey's spans-of-control framework runs from three to five direct reports for complex, varied work to more than 15 for routine, standardised work. Agents behave the same way. A vague task needs me every few minutes. A task with a written brief, a check for "done" that was fixed before it started, and a shared task list can run for an hour without me.

So I made the work more routine. Each agent gets a brief and writes its state to files. One manager agent, my chief of staff, runs on the home PC, keeps the board of who is doing what, and only brings me the decisions that need me. That part runs on Morndo, the harness I'm building for exactly this. Complex sessions stay on my Mac, where I watch them. Two other things helped, and I can't separate their effect from mine: Opus 5.5 arrived on 23 September, and the home PC started taking work on 28 September.

What 225 billion tokens built

Tokens and agent-hours are both inputs, so here is the output. This is what my agents and I merged on GitHub in the same 30 days:

Nearly all of it was customer-facing:

• A full rebuild of a production SaaS product: new sign-in, team workspaces, a public API with webhooks, an MCP server so AI assistants can use the product, billing on its own credits ledger, rebuilt change monitoring and alerts, and a redesigned dashboard.
• An event platform: an Android app, ticketing, workshop seat allocation, door check-in, 533 personal recap emails and 15 partner reports.
• A directory site, built from scratch: firm and location pages, logos for 3,555 firms, sign-in and paid accounts.
• 200 tax and legal explainers and four free tools for a finance product.

The agents also did most of the QA I used to do by hand: parity checks against the designs, golden tests on the data extractors, and a shadow run that caught two defects before a switch-over. What the logs can't tell me is which tokens produced which result, or what any of it is worth.

Lesson 1: an agent that can't finish will invent work

My clearest example is a small one: a Codex run in goal mode (the agent keeps going until a stop condition is met) on one of my open-source projects.

Its goal had two flaws. The stop condition needed a step only I could do, so the run could never end. And the rule between iterations was "take the next action that turns an open requirement into evidence". The cheapest evidence is more evidence, so the agent wrote schemas, histories and a 1.7 GB JSON schedule.

I rewrote the goal around working software, named the shortcut that didn't count, and added a three-strikes rule. The next session made 17 commits.

On a token dashboard, that run looks like four and a half days of steady work. Nothing in the count shows that nothing shipped. Write the goal so it names the product as the deliverable, says what doesn't count, and has a stop condition the agent can reach without you.

Lesson 2: measure one unit before you fan out

Fan-out multiplies whatever one unit costs, mistakes included.

Run one unit, read the token count, multiply, then decide.

Lesson 3: subagent routing, and why cheaper per token isn't cheaper per task

My rule is "plan with frontier models, execute with cheaper ones". When I checked my logs, I had mostly not been doing it.

In October, 97 to 98% of my subagent tokens ran on Opus. In late September and early October, 59 to 80% of my subagents named no model, and a subagent that names no model inherits its parent's.

The routing in my head never made it into the config. It only became real on 11 October, when worker sessions on the PC started running on GLM-5.3, a cheaper model from Z.ai. In the week that followed, cheaper models wrote 14% of all output tokens at about 5% of the total tokens.

Four more things I learned about cheap models:

• Cheaper per token isn't cheaper per task. In the directory project, a cheap model fallback made 84 calls for six cents and added seven wrong answers and no right ones. Now a fallback only gets switched on after a small set of cases with known answers shows that it helps.
• The saving is in the price per token. My Sonnet test used about as many tokens as Opus did.
• Switching model mid-session throws the cache away. In Claude Code each model has its own prompt cache, so the first request after a switch re-reads the whole conversation with no cache hits (Claude Code prompt caching docs). Spawn a subagent for the cheap part instead.
• Comparisons are easy to fake by accident. My first comparison said MiniMax used twice the tokens per session. 53 of its 56 sessions were in one project. On the one project both models had worked on, the result reversed, on too few sessions to mean anything either way. I had compared workloads, not models.

Name a model for every subagent. The default is a decision too. In Claude Code that is the model field in the subagent's definition: haiku, sonnet, opus, a full model ID, or inherit. To change the model for every subagent that doesn't name one, set CLAUDE_CODE_SUBAGENT_MODEL (subagent docs).

---
name: test-runner
description: Runs the test suite and reports only the failures
model: haiku
---

Lesson 4: usage limits, overloads and memory caps will hit mid-task

Running this many agents, I hit every one of these limits at least once.

The 30 agents came back because their state lived in files and a shared task list, not in the conversation. Each one resumed from its own transcript. Newer Claude Code versions can also wait for a usage limit to reset and continue the interrupted task on their own.

Lesson 5: verifying agent output is the best place to spend tokens

For a series of tax and legal explainers, writer agents checked their own claims and reported green. Fresh reviewers, told to open the primary source for every statement, still found corrections in every post they checked. In the three posts where I have the full count:

The checker needs checking too. In one experiment I labelled agent reports by whether I later questioned them, about 7% of them. An LLM judge that matched each claim against the agent's tool log did no better than chance at picking those out: it marked about 70% of all claims "no evidence", on every kind of report. A plain word-count classifier (TF-IDF) did better on the same labels. Neither was good enough to use, but the cheap baseline is what exposed the judge.

Try the cheap baseline before you pay for the judge.

Two smaller ones: rule decay and the 30-day log cleanup

Rules and long sessions decay. One shared rule file grew from 434 to 1,554 lines in a day, far too long for any agent to follow. My manager session ran for two weeks with 25 compactions, the points where Claude Code summarises a full context window. What survives a compaction is what is written to a file, so state goes in files. I wrote more about that in what belongs in an agent's context window, and what to evict.

Your logs are the asset, and they expire. Claude Code deletes transcripts after 30 days by default, so most of my history before September is gone. Adding up the per-machine reports would have counted 43.8 billion tokens twice, because transcripts had been copied between machines. And one config file named a model while the transcripts showed a different one had run 4,213 times. To know which model ran, check the transcripts.

The checklist

How I measured Claude Code token usage, and how to check yours

• To check your own: /usage in Claude Code shows the current session's input, output, cache reads and cache writes per model. For history, npx ccusage@latest daily adds up the transcripts on one machine.
• ccusage over every Claude Code transcript on the Mac and the PC, merged so each API response counts once (by message and request ID). A hand count of one day matched it within 0.3%.
• Agent-hours count the time each session or subagent was working: two responses in the same transcript at most 5 minutes apart count as work time. "Agents at once" is agent-hours divided by the hours in which at least one agent was running. The 30-day window had 3,268 agent-hours over 547 such hours.
• The 30-day window is 15 September to 14 October 2026, my busiest 30 days so far. September as a calendar month came to 151 billion; October is on pace for about 223 billion.
• Pull requests are the ones merged under my GitHub account in that window, counted with GitHub search. Agents open them under my account, so the count doesn't separate their work from mine.
• Codex added about a billion tokens at most in the same period. Cursor keeps no token counts, so it is not included.
• Dollar figures are list-price equivalents, not what I paid.
• My logs before September are incomplete because of the 30-day cleanup, so I don't compare against earlier months.

Written with AI assistance and human review. The numbers come from my own logs. Prices and limits are as documented in October 2026; check the current docs before relying on a specific figure.