The Orchestrator-Worker Cost Multiplier: ~15x Tokens for a Real Quality Gain

A Manager/Subagent Hierarchy Has a Concrete, Quotable Cost

A manager/Subagent architecture -- a lead agent that decomposes a task and delegates pieces to several subagents running in parallel -- is a legitimate design choice covered elsewhere in this course from the architectural angle (when a hierarchy is the right shape for a task). This concept is about the other half of that decision: what a hierarchy actually costs in tokens, which is the number that turns "should we use subagents" from a vibes-based call into a measurable tradeoff.

The number itself comes from Anthropic's own multi-agent research group, who benchmarked an orchestrator-worker setup -- Opus running the lead role, Sonnet running each Subagent -- against a plain single-Opus baseline on an internal research task. The multi-agent version pulled ahead by a real, non-trivial margin in quality. The catch is what that margin cost: the multi-agent version consumed on the order of 15 times the tokens a single ordinary chat turn would use.

Putting Numbers to the Ratio

Here's a concrete illustration. Say answering a research question solo -- pulling in sources, working through them, writing up a response, all in one context -- runs to roughly 10,000 tokens.

Now put the identical question through an orchestrator-worker setup instead: one lead directing four subagents, five separate contexts running in total, since the lead itself spends tokens both planning the work and stitching the final answer together at the end. Each of the four subagents processes its own slice of material and writes its own output; the lead reads all four and produces the combined answer. At Anthropic's reported multiplier for this shape -- about 15x -- that same question now costs in the neighborhood of 150,000 tokens:

And this multiplier isn't confined to what goes in -- it hits output equally, since each of the five separate contexts writes its own complete response independently, with no sharing or reuse of work across any of them.

Where the Multiplier Pays Off -- and Where It Doesn't

The 15x multiplier is not inherently good or bad; it is a cost that has to be earned by the task's shape. It pays off specifically when the task decomposes into genuinely independent subtasks that benefit from being explored in parallel -- research across several unrelated sources being the canonical example, since each Subagent's slice of work doesn't depend on what any other Subagent finds.

The multiplier is markedly less effective for tightly-coupled tasks, and coding is the textbook case: when each step depends on the previous step's output, there is nothing genuinely parallel to fan out across, so subagents mostly end up waiting on each other's results while each still burns its own full context. Paying the 15x multiplier on a task that doesn't actually decompose in parallel means paying for capacity the task never uses.

A Mitigation: Cheap Subagents Under an Expensive Lead

One concrete lever softens the multiplier without abandoning the architecture: use a more capable (and more expensive) model only for the lead agent -- the one doing planning and final synthesis -- and route the subagents to a cheaper model tier. The lead's coordination quality matters most; the subagents are often doing more mechanical, bounded work (reading a slice of sources, extracting relevant facts) that a cheaper tier handles adequately. This doesn't eliminate the ~15x token-count multiplier itself, but it reduces the multiplier's effect on total spend, since four-fifths of the contexts (the subagents) are now billed at a lower per-token rate than the lead.

How This Connects to Domain 1's Manager/Subagent Lesson

Domain 1's lesson on manager/Subagent hierarchies covers the qualitative side of this decision: coordination overhead, when a hierarchy architecture fits a task, and the general caution that it multiplies token usage. This concept is the concrete, quotable number behind that caution -- the ~15x figure, the worked 10,000-to-150,000-token example, and the specific mitigation (cheap subagents, expensive lead) that a cost-focused answer on this exam should reach for.

Common exam traps

• Treating "use subagents, it improves quality" as free advice -- the quality gain Anthropic reported came with a real ~15x token cost, not at no cost.
• Applying an orchestrator-worker pattern to a tightly-coupled task like coding, where steps depend on each other and there's no genuine parallel decomposition to fan out across -- the multiplier pays for nothing there.
• Assuming the 15x multiplier is a fixed, universal law rather than a reported internal-eval figure for one specific architecture (Opus lead, Sonnet workers) and task type (research) -- the number is the illustrative order of magnitude to reason with, not a guarantee for every hierarchy.
• Missing the mitigation lever: using the same expensive model tier for both the lead and every Subagent, when routing subagents to a cheaper tier reduces total cost while preserving the lead's coordination quality.