This is an English version of an article I originally published (in Japanese) on Zenn.
"Split the work across role-specific agents and both quality and cost will improve" — that was the assumption behind the automated tech-blog pipeline I built. The measurements said the opposite. When I cut subagents from 11 to zero, total token usage actually went up 27.7%, yet the cost of producing one article dropped 87.7%. This is a hands-on record of a person who writes no code building this pipeline with nothing but Claude Code prompts, and then flipping the design based on measured numbers.
The problem: I assumed more agents was better
This pipeline is an in-house system I built — purely with Claude Code prompts — to generate multiple blogs unattended. Not a single line was written by a programmer. I build reservation systems, games, and menu-bar apps the same way.
The first version of the tech-blog pipeline was a 7-agent setup: a chief coordinating a set of specialists.
- chief (orchestration)
- keyword (topic selection)
- research (primary-source research)
- outline (structure)
- writer (drafting)
- publish (formatting for submission)
- qa (scoring — an independent process)
It felt natural. Human teams get more specialized when they divide roles; surely splitting "topic picker" and "writer" lets each focus on its job. That was the theory.
The measurement: where the $41.7 per article was actually going
I counted the token breakdown of one article that actually ran to completion under this 7-agent setup (a hands-on piece about local image generation, ~4,000 characters of body, 2 diagrams, published 2026-07-14). Here is what came out.
| Segment | Tokens |
|---|---|
| Parent session | 737,594 |
| 11 subagents (total) | 6,216,660 |
| Total | 6,954,254 |
The final output (the article body) was only about 4,000 tokens. In other words, total tokens were roughly 1,738× the deliverable. And breaking it down further, 79% of the billed tokens (5,455,523) were "cache re-reads" — the same shared context (system prompt, skill definitions, role definitions) being re-read every time execution crossed an agent boundary.
The decisive thing was a design premise. Each stage ran "one at a time, in order." In other words, there was no parallel debate and no cross-checking. Splitting into 7 bodies didn't change the fact that the same model was making the calls on the same source material. The split produced cost and nothing else; it contributed nothing to the quality of the judgment.
The result: tokens up 27.7%, yet cost down 87.7%
So I scrapped the 7-agent setup (the sister pipeline used 9 agents) and consolidated the six stages — ① topic → ② primary sources → ③ outline → ④ drafting → ⑤ QA → ⑥ submission — into a single session that executes them top-to-bottom as "steps." Only QA stayed a separate process (more on that below). The chart below is the measured comparison of the same article run to completion under the old vs. new design.
One article, completed-run vs. completed-run (from an internal measurement record, 2026-07-17).
At a glance the numbers look contradictory. Total tokens went 6,954,254 → 8,880,984, up 27.7%. Cache reads also went 5,455,523 → 8,457,896, up 55.0% (with the whole workflow's context riding in one session, reads actually accumulate). And yet cost went $41.68 → $5.12, down 87.7%.
The reason is the price gap between cache "writes" and cache "reads." Every time execution crosses an agent boundary, a fresh context re-prefill (a cache write) occurs — and that went 1,402,348 → 334,689 tokens, down 76.1%. From our internal operational logs, a write worked out to be roughly 12.5× more expensive than a re-read ($3.75/M vs $0.30/M — an internal estimate, not Anthropic's official price table). No matter how much reads increase, if writes drop 76%, the net comes out ahead.
Why is a "write" so expensive? Prompt caching prefills the shared preamble (system prompt, skill definitions, role definitions) once, loads it into the KV cache, and from then on only "reads" it. A read is cheap because it reuses an already-cached prefix. But when you spawn a subagent, the parent's KV cache is not inherited as-is. The child has to load that same shared preamble again and "write" it back into the cache — that is the re-prefill, and it's why cache writes are billed at a premium. The high re-write piled up once per agent boundary. Consolidation cuts the number of those re-writes directly.
That said, to be honest, not all of that cost gap is the effect of consolidation. Our internal read is that consolidation itself accounted for about 40%, and the remaining ~60% was model choice (Opus → Sonnet). This isn't "delete the agents and it magically got cheap"; it's a combination of "cut the re-prefill cost at agent boundaries, and also revisit the model."
The one thing I kept split anyway
QA is the one stage I did not consolidate; I kept it as a separate process (independent scoring by a cheap model). The reason is simple: when you let the generating model score its own output, the evaluation gets pulled toward the convenience of generation. It's the question of whether you can honestly give your own article a 75. I treat this as one of the few exceptions worth the cost of splitting.
The general rule you can extract from this comes down to one sentence: "Is this stage genuinely debating and cross-checking in parallel, or is it just going around one at a time?" If the latter, the agent boundary is decoration that only generates prefill cost. If the former (a stage that needs an independent set of eyes), it's worth paying the cost to split.
A reproducible takeaway
If your pipeline "splits agents by role," first check whether that stage really makes parallel, independent judgments. If it doesn't, the agent boundary is just an expensive file hand-off that generates a context re-prefill. In a design where each stage runs serially, waiting its turn, splitting is nothing but cost.
Sort each stage with these two questions and the call comes fast:
- Does this stage race multiple candidates in parallel? — If No, the split isn't producing parallelism; only the boundary's re-prefill cost remains. Consolidate it.
- Does this stage need an independent verifier (a set of eyes whose interests differ from the generator's)? — If Yes, it's worth paying the cost to split, like QA.
Stages that are No on both: consolidate. Only stages that are Yes on either one keep a boundary. Conversely, if stages genuinely run concurrently and branch dynamically on each other's intermediate results — racing multiple candidates at once, switching the next stage based on partial results — then the boundary is doing more than prefill work. Consolidate stages that merely hand off one at a time, and split only the stages that truly need concurrency, independence, or dynamic branching. That's where the line is.
In fact, this very article is a record of that initial intuition — "more agents makes it smarter" — being overturned by measurement. Splitting is not free.
Top comments (0)