225 Billion Tokens Measured: The Truth About Claude Code Costs and Multi-Agent Workflows

One Developer's 30-Day Claude Code Ledger: The Truth Behind 225.1 Billion Tokens

A developer tallied all of his Claude Code sessions during his busiest 30 days (September 15 to October 14) and arrived at a striking figure: 225.1 billion tokens from 736,633 API responses, 94% of which were consumed by the Opus model. He used one Mac and one home PC, running more than 10 agents simultaneously at peak — not an enterprise deployment, but one person's daily development.

The value of this data lies not in the numbers themselves, but in what it reveals about the overlooked cost structure and collaboration patterns of coding agents. Combined with the full charts and logs published on his blog, we can see how AI coding tools actually behave under real, high-intensity use.

97.9% of Tokens Go to "Re-Reading Context"

The most counterintuitive finding: 97.9% of token consumption comes from cache reads, cache writes account for 1.75%, output only 0.34%, and entirely new input just 0.01%. Each response reads an average of about 305,000 tokens of context, of which 299,000 come from cache, while the actual written content is only about 1,000 tokens.

In other words, for every 1 token the model writes, it re-reads 291 tokens.

This is not an isolated case. According to AgentsRoom's analysis of a smaller 3.8 billion token log, the same 97% to 98% cache-read share was observed, and cross-validation from two independent sources makes this conclusion more convincing.

The reason is that models are stateless: every turn of conversation must resend the system prompt, tool definitions, files already read, and the full message history. Prompt caching only handles the unchanged portion — and that portion is nearly everything. Opus 5.5's cache-read price is 5% of the input price; at list prices this month works out to about $97,000, and without caching it would be close to ten times that.

This leads to a key practice: even if you're on a monthly subscription plan, re-reads still count toward usage. Claude Code's official documentation explicitly states that "asking a one-line question in a session that has been open all day is still billed as the entire conversation." Therefore, running /clear between unrelated tasks and delegating test runs and documentation lookups to subagents that return only summaries are the top priorities for controlling costs.

Prompt Caching is a mechanism that reuses repeated prefixes at the API level. Because large models are stateless, every request must resend the full context — system prompt, tool definitions, message history — to the model; the server stores the intermediate state of the already-processed prefix, and if the next request has an identical prefix, it hits the cache directly without recomputation. The hit portion is typically priced at 5% to 10% of the standard input price, while writing to the cache may incur an additional fee. The economics of caching are therefore straightforward: the longer and more stable the context, the greater the caching benefit — but each hit is still billed and counts toward usage quotas. This also explains a common misconception: a monthly subscription does not mean free re-reads; as long as a request carries a long context, cache reads incur costs as usual, just at a lower unit price.

Agent Count and Online Hours Are the Real Drivers of Total Volume Growth

In the week of August 31, his agents consumed 4 billion tokens; four weeks later, weekly usage reached 60.8 billion. But the hourly workload per agent barely changed, consistently staying between 52 million and 80 million tokens.

What changed was two things: the average number of simultaneously running agents rose from 2.0 to 6.9, and the number of hours per week with at least one agent running rose from 38 to 145 — close to 21 hours a day, with agents still working while he slept.

The multiplicative relationship is clear: 2.0 agents × 38 hours × 52 million ≈ 4 billion; 6.9 × 145 × 60 million ≈ 60 billion.

He attributes the shift in bottlenecks to an expanding span of control. McKinsey's recommended management span for complex work is 3 to 5 direct reports, while standardized work can exceed 15. He observed that agents follow the same rule: ambiguous tasks require intervention every few minutes, while tasks with written briefs, predefined "done" criteria, and shared task lists can run autonomously for an hour.

To this end he did three things: write a task brief for each agent, write state to files, and set up a "manager agent" that maintains a dashboard and only escalates items requiring human decisions. He does admit, however, that he cannot separate the effect from two other variables: the release of Opus 5.5 (September 23) and the home PC starting to take on work (September 28).

Subagent is an independent context instance spawned on demand by the main session, with its own system prompt and toolset; after completing a subtask it returns only a summary of results to the main session, avoiding stuffing a large amount of intermediate process back into the main context. This mechanism has a major impact on cost structure: subagent tokens are metered separately, and their model can be specified via the model field in the definition or the environment variable CLAUDE_CODE_SUBAGENT_MODEL. If unspecified, the subagent inherits the parent session's model — which is exactly why a large number of subagents in this article ran on Opus by default. In addition, each model has its own prompt cache, so running cheap work in a separate subagent is more cost-effective than switching models mid-session in the main conversation.

What Was Produced: 1,029 Merged PRs and One Failed 4.5 Days

Over the same 30 days, he and his agents merged 1,029 pull requests across 21 codebases — 406 features and 293 fixes, averaging about 3 agent-hours per merged PR. Almost all were customer-facing:

• A complete rebuild of a production-grade SaaS product: new login, team workspaces, a public API with webhooks, an MCP server for AI assistants to call, a billing system based on a proprietary credit ledger, rebuilt change monitoring and alerting, and a redesigned dashboard.
• An events platform: an Android app, ticketing, workshop seat allocation, on-site check-in, 533 personalized recap emails, and 15 partner reports.
• A directory website built from scratch: company and location pages, logos for 3,555 companies, login and paid accounts.
• 200 tax and legal explainers and four free tools for a financial product.

But not all tokens turned into results. One Codex goal-mode run lasted 4.5 days, consumed 40.8 million tokens, and produced zero commits, leaving behind about 2 GB of artifact files. The problem lay in the goal definition: the stopping condition included a step only a human could complete, so the run could never end; the iteration rule was "take the next action that turns an open requirement into evidence," and the cheapest "evidence" was more evidence — the agent kept writing schemas, history records, and a 1.7 GB JSON scheduling table. It was not until he rewrote the goal around working software, explicitly excluded shortcuts, and added a "three strikes" rule that the next session produced 17 commits.

Unnamed Subagents: Missing Configuration Derails the Cost-Saving Plan

His principle was "plan with an expensive model, execute with a cheap one." But the logs show that 97% to 98% of subagent tokens in October ran on Opus; from late September to early October, 59% to 80% of subagents did not specify a model at all, and subagents without a specified model inherit the parent session's model.

"The routing in my head never made it into the config file." This honest problem is common in multi-agent workflows. It was not until October 11 that the work sessions on the PC switched to Z.ai's GLM-5.3, and in the following week cheap models contributed 14% of output tokens while accounting for only about 5% of total tokens.

Cheap models have their own pitfalls. In the directory website project, a cheap-model fallback made 84 calls and cost six cents, adding seven wrong answers and zero correct ones. His current approach: only enable a fallback after it has been validated on a small set of known-answer cases.

A more memorable technical detail: switching models mid-session discards the cache. In Claude Code, each model has its own prompt cache; after switching, the first request re-reads the entire conversation with zero cache hits. The right approach is to start a separate subagent for the cheap portion rather than switching models in the main session.

AUROC (Area Under the ROC Curve) is a common metric for measuring a binary classifier's discriminative ability: random guessing has an expected value of 0.5, 1.0 means perfect discrimination, and below 0.5 means the judgment direction is even opposite to the true labels. The author used this metric to evaluate an LLM judge's ability to identify "suspicious reports" and got 0.48, meaning the judge's scores had almost no correlation with the ground truth — even slightly worse than a coin flip; while a simple TF-IDF word-frequency classifier reached 0.65, showing that on this type of task, surface lexical features are actually more reliable than the large model's overall judgment. Note that AUROC only reflects ranking discrimination, not directly the accuracy or recall at a specific threshold, and it fluctuates more with small sample sizes.

Three Actionable Recommendations for Practical Users

If you run only one or two agents, the 97.9% cache-read ratio still applies. The author's minimal action list is:

1. Run /clear between unrelated tasks — asking a one-line question in an all-day session is still billed as the entire conversation.
2. Explicitly name the model for each subagent — the model field in a subagent's definition accepts haiku, sonnet, opus, a full model ID, or inherit; to uniformly change the model of unnamed subagents, set the environment variable CLAUDE_CODE_SUBAGENT_MODEL.
3. Increase cleanupPeriodDays — Claude Code deletes conversation records after 30 days by default, which is why most of his history before September was lost.

In addition, he compiled a resource-exhaustion reference table: usage limits caused 30 agents to be interrupted from 04:20 to 08:20 (all recovered without loss); starting 8 Opus agents simultaneously returned 529 Overloaded; when the Mac's swap space was full at 29.3/30.7 GB, looking at free memory was meaningless; overnight runs must add caffeinate -s to prevent sleep.

For quality verification, he offers a sobering data point: an LLM judge that matched every claim against agent tool logs performed no better than random at identifying suspicious reports (AUROC 0.48), while a simple TF-IDF word-frequency classifier scored 0.65. But more effective than an automated judge is a "fresh reviewer" — one asked to open primary sources and verify every statement — which corrected 11 of 64, 11 of 44, and 17 of 26 statements in three articles with complete counts, respectively.

Conclusion: What the Token Logs Can't Tell

The author closes by listing the honest limits of his measurements: the dollar figures are list-price equivalents, not actual spend; PR counts cannot distinguish agent from human contributions; the config file specified one model while the transcript logs showed another model actually ran 4,213 times. The key sentence is: the logs cannot tell me which tokens produced which outcome, nor how much those outcomes were worth.

The value of this ledger lies precisely in its honesty. It doesn't sell a "AI does everything for you" narrative; it provides reproducible numbers, actionable configurations, and avoidable pitfalls. For anyone working in Claude Code every day, checking whether your subagents have a named model may save more money than upgrading to a stronger model.