In May I wrote that Superpowers is the token-efficient way to work with Claude Code, and I put it in one line: "Planning is cheap; doing is expensive."
I never measured it. Now I have, for the part of Superpowers that does the most work: subagent-driven development, the skill that hands every task in a plan to a fresh subagent and has another one review it.
The doing was cheap. Every line of code, every report and every review together came to 0.06% of the tokens. The rest was models reading their own context again, turn after turn. And the fresh subagent that makes the method attractive only stayed cheap while its task stayed small.
What subagent-driven development does
You give the skill an implementation plan. The session you started becomes the controller. For each task it writes a brief, dispatches an implementer subagent, has a task reviewer check the result against the spec and for quality, and runs a fix loop of at most five rounds with a scoped re-review after each. When every task is done, one more reviewer looks at the whole branch on the most capable model.
The skill sums itself up as "Fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration".
The case for it
The design is sound. An implementer never sees the session's history, only its brief, so it cannot drift on something you said two hours ago. Every task gets reviewed while the diff is still small. And a ledger file records which tasks are done, so a controller that loses its place can pick up again.
The skill is also candid about where tokens go. It warns that whatever you paste into a dispatch, and whatever a subagent prints back, "stays resident in your context for the rest of the session and is re-read on every later turn." And it says plainly: "Wall-clock and context cost scale with how many turns a subagent takes". Both sentences turned out to be the whole story.
How I counted
Claude Code writes every session to a JSONL transcript, and every model call in it carries its token usage. Subagents keep their own transcripts next to it.
I took every call to the skill between 15 September and 15 October: eleven plans across six of my own repositories, on Claude Code 2.1.272 to 2.1.300 and Superpowers 6.3.0 and 6.4.1. Only model calls made while a plan was running count, in the controller and in the subagents. A plan starts at the skill call and ends at the next workflow step, such as finishing the branch or a new brainstorm. Where a session had no such step, I ended the plan at its final review by hand.
One plan was forked into three branches, and forks copy their history, so I counted every model call once, by its message id. The same trap caught me in the auto mode count.
The plan window took two attempts, and a fresh agent checking my numbers caught both mistakes. My first count booked everything after the skill call to the plan, and my second still ran each plan to the end of its session. Both missed that a session outlives its plan. On 2 October I kept going for another day after the final review, sending "rounds" of improvements to Opus subagents, and that alone was 1.6 billion tokens that belonged to no plan.
Writing is a rounding error
The eleven plans dispatched 407 subagents and used 3.3 billion tokens.
Output, everything any model wrote, was 2.1 million of those: 0.06%. The rest was input, and almost all of that input was cache reads. Every turn, a model reads its entire context again: the instructions, every file it opened, every tool result, every word it wrote earlier. A context of 400,000 tokens read over 300 turns is 120 million tokens, whatever the model writes in between.
So on a subscription, where tokens are what your usage limits are made of, the question is how big each context gets and how many turns read it.
The controller takes a third
The controller writes no code, and took 35% of the tokens: 1.18 billion. It also wrote more than three times as much output as all 407 subagents together, 1.7 million against 0.5 million.
| Start | Dispatches | Controller | Subagents | Controller share |
|---|---|---|---|---|
| 15 Sep | 45 | 111M | 162M | 41% |
| 18 Sep | 36 | 101M | 69M | 59% |
| 19 Sep | 29 | 151M | 69M | 69% |
| 21 Sep | 35 | 42M | 107M | 28% |
| 25 Sep | 22 | 68M | 123M | 35% |
| 2 Oct | 38 | 80M | 93M | 46% |
| 4 Oct | 46 | 66M | 270M | 20% |
| 6 Oct | 18 | 29M | 19M | 60% |
| 7 Oct | 101 | 426M | 1,158M | 27% |
| 11 Oct | 19 | 44M | 65M | 40% |
| 12 Oct | 18 | 65M | 25M | 72% |
Of the controller's tokens, 98.9% are cache reads. Its context holds the plan, every brief it wrote, every report that came back and every review verdict, and per plan the median controller turn read between roughly 250,000 and 625,000 tokens.
It reads that about six times for every subagent it sends out, the median over the plans. Each dispatch means preparing a brief or a diff, sending it, and reading what comes back, with the ledger updated along the way.
A fresh subagent is cheap while its task is small
The other 65% went to the subagents, and it is not spread evenly. Across the 366 subagent transcripts that used tokens inside a plan's window, the median subagent ran 19 turns and used 1.4 million tokens.
| Turns | Subagents | Share of subagent tokens | Median tokens | Median peak context |
|---|---|---|---|---|
| under 50 | 280, 77% | 17% | 0.8M | 78k |
| 50 to 150 | 70, 19% | 39% | 9.7M | 179k |
| 150+ | 16, 4% | 44% | 50M | 395k |
Four percent of the subagents used 44% of the tokens. The ten largest alone used 34%.
The pattern is arithmetic. A long-running subagent's context grows with every turn, and every turn reads all of it again, so tokens grow far faster than the work. A subagent at 365 turns becomes a second controller, and the largest one in my data read 147 million tokens on its own, more than the entire controller of nine of the eleven plans.
I know where the big ones came from: each of them carried more than one task. The largest was "implementing PR 1 (Tasks 1 and 2) of the Phase 4 workers plan". Another took six tasks of a remediation phase in one go, "Batch 3 (Tasks 7-9 ...) and Batch 4 (Tasks 10-12 ...)", because my controller had bundled them into one pull request. Each of those ran on Opus 5.5 for 200 to 365 turns, and fifteen of the sixteen subagents over 150 turns were Opus 5.5.
One confound I cannot separate: the skill tells the controller to give harder tasks a more capable model, so big tasks and Opus arrive together. The turn count is what drives the tokens, and in these plans the turn count follows how much work one dispatch was given.
What I learned from this
- Cut plans into tasks a subagent can finish in a few dozen turns. In my data that is where the fresh subagent lives up to its promise: a median of 0.8 million tokens per dispatch. A dispatch that carries "Tasks 7-9" and "Tasks 10-12" is a session in disguise.
- Batch only the trivial ones. The skill says to send several small same-shape edits to one subagent rather than one each, and that holds: a dispatch costs the controller about six turns at a few hundred thousand tokens each, more than a small task costs on its own. Bundling real tasks is the opposite case.
- End the session when the plan ends. The final review is a good moment to stop. Whatever you start afterwards inherits the controller's full context on every turn.
- Start the plan in a fresh session, and restart the controller when its context gets big. A new session that calls the skill on the same plan resumes at the first task without a completion line in the ledger. That is cheaper than carrying half a million tokens into every turn, and it is the same reasoning as knowing when to
/clear.
This is the same pattern I found when I timed these transcripts: the expensive part is rarely the thing the model is visibly doing.
So I correct my own line from May. Planning is cheap, and doing turned out to be cheap too. What costs tokens is reading, and a fresh context only stays fresh for as long as you keep the job small.