My rule for coding agents is "plan with the expensive model, execute with cheaper ones". Then I added up every Claude Code token from my busiest 30 days, 15 September to 14 October: 225.1 billion tokens over 736,633 API responses. Opus models ran 94% of them. In two of those weeks, most of my subagents never named a model, so they inherited Opus from their parent session and I didn't notice.
It was just me with a Mac, a home PC and, on a heavy day, ten or more agents working at the same time. If you run one or two agents, the parts that still apply are /clear between unrelated tasks, naming a model for every subagent, and raising cleanupPeriodDays so your logs survive.
97.9% of it was the model re-reading its context
Others have found the same 97 to 98% on much smaller logs (AgentsRoom counted 3.8 billion). The model is stateless, so 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 hasn't 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.
On Claude Opus 5.5, which did 73% of my tokens, a cache read costs 5% of the input price (pricing). At list prices my month comes to about $97,000; without the cache it would be roughly ten times that. I'm on multiple coding plans with flat fees, so that figure is only a yardstick.
Re-reads still count on a flat plan. In the words of Claude Code's 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, it pays to keep context small, with /clear between unrelated tasks and with verbose work like test runs, logs and doc lookups pushed into a subagent, so only a summary comes back.
More agents, running more hours
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 average number of agents running at once went from 2.0 to 6.9, and the hours with at least one agent running went from 38 a week to 145. That's 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.
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. McKinsey's version runs from three to five direct reports for complex, varied work to more than 15 for routine, standardised work. I see the same with agents. 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 runs on the home PC, keeps the board of who is doing what, and only brings me the decisions that need me. 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 it built
Tokens and agent-hours are both inputs. In the same 30 days my agents and I merged 1,029 pull requests across 21 repositories: 406 features and 293 fixes, at about three agent-hours per merged pull request. 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.
4.5 days, 40.8 million tokens, zero commits
One Codex run in goal mode (the agent keeps going until a stop condition is met), on one of my open-source projects, ran for 4.5 days, used 40.8 million tokens and produced zero commits and no product code, plus about 2 GB of artifacts. On a token dashboard, that looks like four and a half days of steady work.
The goal had two flaws. Its 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.
One recap email cost 340,000 tokens
I had agents write and verify a personal recap email for each of 534 event attendees (533 went out; one person had never been scanned at the door). Each person's email cost about 340,000 tokens, which projected to 180 million for the list. I paused after about 55 million, tested a cheaper model on five emails with planted errors, and finished the rest on it for about 53 million: about 110 million in total, at a lower price per token.
For a directory, I needed a logo for each of 4,255 firms. Sending every homepage to a model would have cost about 85 million tokens. Plain code settled 2,003 of them and sent the 1,603 unclear ones to small Haiku reviewers, which picked a logo for 1,552. And a Codex smoke test of two items, on default settings, picked the most capable model at its highest effort and used up a whole five-hour usage window.
Subagents that never named a model
When I checked my logs against my own rule, I had mostly not been following 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.
Cheap models brought their own problems. 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. My Sonnet test used about as many tokens as Opus did, so any saving comes from the price per token.
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 (prompt caching docs). Spawn a subagent for the cheap part instead.
My first model comparison fooled me. It said MiniMax used twice the tokens per session, but 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 been comparing workloads.
In Claude Code, the model 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
---
Limits I hit mid-task
Running this many agents, I hit every one of these at least once:
| What ran out | What happened | What I do now |
|---|---|---|
| Usage limit | An overnight limit stopped 30 agents mid-task from 04:20 to 08:20. All of them resumed with no lost work. | That run now allows two live agents, and I check what each agent committed before I resume it |
| API capacity | Starting eight Opus agents at once returned 529 Overloaded. Waves of three failed too. |
Fewer Opus agents at once; if a retry wave fails too, I finish the work in the foreground |
| Mac memory | Swap was full (29.3 of 30.7 GB) while free RAM looked fine, so halving the build heap changed nothing. | Measure swap, not free RAM |
| Sleep | The Mac went to sleep across a limit reset, and the run sat waiting for Enter. |
caffeinate -s for every overnight run |
The 30 agents came back because their state lived in files and a shared task list, not in the conversation. Claude Code also caps a session at 20 running subagents by default (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS changes it), and newer versions can wait for a usage limit to reset and continue the interrupted task on their own.
Fresh reviewers, and a judge that scored 0.48
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, they corrected 11 of 64, 11 of 44 and 17 of 26 statements.
I also tested a checker. 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 (AUROC 0.48): it marked about 70% of all claims "no evidence", on every kind of report. A plain word-count classifier (TF-IDF) scored 0.65 on the same labels. Neither was good enough to use, but the cheap baseline beat the judge.
How I measured, and how to check yours
- To check your own:
/usagein Claude Code shows the current session's input, output, cache reads and cache writes per model. For history,npx ccusage@latest dailyadds up the transcripts on one machine. - I ran ccusage over every Claude Code transcript on the Mac and the PC, merged so each API response counts once. Adding up the per-machine reports would have counted 43.8 billion tokens twice, because transcripts had been copied between machines. A hand count of one day matched 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. "Agents at once" is agent-hours divided by the hours in which at least one agent was running: 3,268 agent-hours over 547 hours in the 30 days.
- Pull requests are the ones merged under my GitHub account in that window. Agents open them under my account, so the count doesn't separate their work from mine.
- Dollar figures are list-price equivalents, not what I paid. Codex added about a billion tokens at most; Cursor keeps no token counts.
- Claude Code deletes transcripts after 30 days by default, so most of my history before September is gone. And one config file named a model while the transcripts showed a different one had run 4,213 times.
I first published this, with all ten charts, on jacksonly.xyz. Written with AI assistance and human review; the numbers come from my own logs. Prices and limits are as documented in October 2026.
Top comments (1)
How did you confirm which subagents had inherited Opus, from the parent session ID in the logs or from a missing model field on each response? The second one would be the easier check to add to a dashboard while agents are still running.