How this calculator works
A single accumulating conversation handling N tasks resends its full history every turn: task i's input is base context + (i-1) × previous-output-tokens. Summed across N tasks, that history term grows like N × (N-1) / 2 — quadratic in N — even though each task's own work is identical in size. Fan-out to isolated subagents gives every task a fresh context: base context + task, plus a fixed orchestrator dispatch prompt to launch it and the subagent's output read back as orchestrator input. That overhead is per-task, not cumulative, so fan-out's total scales linearly in N, plus one final synthesis step.
At the defaults (20 tasks, 4,000 base context tokens, 1,200 output tokens/task, 300-token dispatch, Sonnet-class pricing), the single-thread history term alone adds roughly 19×20/2 = 190 extra "previous output" blocks of 1,200 tokens to later tasks' input — a cost single-thread pays that fan-out simply never accumulates. Small N favors single-thread since it avoids the dispatch/ingest overhead; the sweep table shows exactly where your workload's crossover sits.
Frequently asked questions
Why does a single long conversation get more expensive per task as it goes?
Because most chat-completion APIs are stateless — every turn resends the full conversation history as input tokens. Task 1 sends just the base context. Task 20 sends the base context plus the output of tasks 1-19. That history term grows with every task, so total input tokens across N tasks scale like N*(N-1)/2 — quadratic in N — even though each individual task's own work is the same size.
Why does fan-out to isolated subagents avoid that growth?
Each subagent gets a fresh context window — its own base context plus its one task, nothing from the other N-1 tasks. The orchestrator only pays for a short dispatch prompt to launch each subagent and a short summary to read each result back. That overhead is fixed per task, so total cost scales linearly with N instead of quadratically. The trade-off is the orchestrator dispatch/ingest overhead itself, which is why fan-out isn't automatically cheaper at very small N.
At what task count does fan-out start winning?
It depends on how large your per-task output is relative to the orchestrator's dispatch/ingest overhead — larger outputs make the single-thread history term balloon faster, pulling the crossover point down to a smaller N. Use the sweep table below with your own base context, output size and orchestrator overhead to find your exact crossover instead of relying on a rule of thumb.
Does this apply to Claude Code subagents, LangGraph, or CrewAI the same way?
The underlying math is the same for any framework where an orchestrator dispatches isolated-context workers and collects short results back — Claude Code subagents, LangGraph subgraphs, CrewAI crews, or a hand-rolled fan-out loop. What differs between frameworks is the exact dispatch and ingest overhead per subagent, which is why those are separate inputs here rather than hardcoded.