I built an orchestration skill for Claude Code that delegated everything to subagents.
It worked.
It also cost somewhere on the order of 1-2 million Opus tokens per task - including tasks whose final diff was a handful of lines.
Nothing was broken.
Every individual decision was defensible.
Three modest multipliers stacked, and then the whole stack ran on every single request.
This is the postmortem, the redesign, and the enforcement layer I should have written first. v1: pure delegation The design goal was context hygiene.
The main session gets polluted fast - it accumulates file contents, tool output, and dead ends, and its judgment degrades as the window fills.
So: don't let it do any work.
Make it a coordinator, and give every unit of real work a fresh context.
That produced four rules: A hard gate.
The main session was forbidden from reading, editing, or running anything itself.
Every action went through a subagent.
A fixed 5-phase pipeline on every task: Plan → Approve → Execute → Review → Report.
Fresh subagents per phase.
No reuse.
Each phase got clean context by construction.
Mandated reviewers with "loop until clean." A review phase that re-ran until it found nothing.
And the trigger was broad - essentially any actionable request. "do this," "implement," "fix," "build," "change." Read those four rules again with a cost lens instead of a correctness lens.
That is the whole postmortem.
The three multipliers
1.
The dispatch schema made optional The subagent dispatch tool takes a parameter.
My skill never set it.
Omitted, it inherits from the parent session - which was Opus 4.8.
So every subagent, including the ones whose entire job was "read this file and summarize it," ran on the most expensive tier available.
Here's what that actually costs at list prices: Model Input $/MTok Output $/MTok vs.
Opus Claude Opus 4.8 () $5.00 $25.00 1× Claude Sonnet 4.6 () $3.00 $15.00 0.6× Claude Haiku 4.5 () $1.00 $5.00 0.2× I want to flag something here, because I got it wrong in my own first write-up of this incident: Opus is not 5× Sonnet.
It's about 1.7×.
It is exactly 5× Haiku.
If you're building a tiering story, the Opus→Sonnet move is a 40% cut, and the Opus→Haiku move on genuinely trivial work is an 80% cut.
Which means the model tax was the smallest of my three multipliers.
I'd been blaming it for the whole bill.
It wasn't even close.
- "Include ALL context" plus zero memory = a cold cache, every time This is the expensive one, and it took me longest to see because the symptom ("agents re-read the repo") sounds like a token-count problem when it's actually a cache-prefix problem.
Prompt caching is a prefix match.
The cache key comes from the exact bytes of the rendered prompt, in the order → → , up to each breakpoint.
One byte different at position N and everything from N onward is a miss.
The economics of that: Cache read: ~0.1× base input price.
Cache write: 1.25× base input price (5-minute TTL; 2× for the 1-hour TTL).
So a cached read is a 90% discount, and a cold write carries a 25% premium.
The gap between best case and worst case on the same tokens is roughly 12×.
Now put a fresh subagent in that picture.
A fresh subagent is a new prefix.
It does not inherit the parent's cached prompt unless its , , and are byte-identical to the parent's - and mine weren't, because each phase got its own tailored instructions.
Every subagent I spawned paid a cold write on the entire repo context it had been told to "include ALL" of.
It gets worse when you parallelize.
A cache entry only becomes readable once the first response starts streaming.
Fire five subagents simultaneously with identical prefixes and all five pay full freight - none of them can read what the others are still writing.
My design had a rule that guaranteed maximum context per agent, a rule that guaranteed a fresh prefix per agent, and a fan-out pattern that guaranteed simultaneous cold writes.
Three rules, one bill.
3.
Fan-out multiplied by an unbounded loop Five-plus