Parallelization Patterns
What this gives you: The ability to run 5-10 tasks simultaneously instead of one at a time. Research competitors, build a landing page, and review code all at once. The same work that takes a day gets done in an hour.
Running tasks one at a time is the slowest, most expensive way to use AI. Running them in parallel - with the right pattern - gets you better results in less time at a fraction of the cost.
Why Parallel Beats Serial
Most people use Claude Code like a conversation: ask a question, wait for the answer, ask the next question. This is fine for simple, sequential tasks. It is terrible for research, analysis, quality assurance, and anything that benefits from multiple perspectives.
The problem with serial execution is threefold. First, it is slow - tasks that could run simultaneously are blocked behind each other. Second, it is expensive in terms of your time because you are the bottleneck between each step. Third, and most importantly, it produces worse results because a single agent builds up context bias - it gets attached to its initial approach and stops questioning its own assumptions.
Parallelization solves all three problems. Multiple agents working simultaneously finish faster, you are freed from babysitting each step, and independent agents with no shared context produce genuinely diverse outputs that you can synthesise into a higher-quality result.
The three patterns below cover 90% of use cases. Learn these and your effective output quality will jump substantially.
Pattern 1: Fan Out / Fan In
The core idea: split a research or analysis task across multiple cheap agents simultaneously, then have one higher-quality agent synthesise the results.
Why this works on cost: Sonnet costs $3 per million input tokens. Opus costs $15 per million. By using Sonnet for the research phase (which is mostly reading and summarising) and Opus only for the synthesis (which requires higher reasoning), you pay $3/MTok for 80% of the work instead of $15/MTok for 100%.
On a task with five research agents each processing 10,000 tokens, and one synthesis agent processing 50,000 tokens:
- All Opus: (5 x 10k + 50k) x $15 = $1.50
- Fan Out/Fan In: (5 x 10k x $3) + (50k x $15) = $0.15 + $0.75 = $0.90
40% cheaper, faster because the research runs in parallel, and often better because each research agent goes deeper on its specific sub-topic.
Real-World Example: Competitor Analysis
Pattern 2: Developer + QA
Build with one agent. Review with a completely fresh agent that has never seen the code.
This pattern exploits a well-known problem in software development: you cannot QA your own work effectively. Not because you are bad at testing, but because you wrote the code with specific assumptions baked in. You test the paths you intended to build, not the paths a user will actually take. A fresh reviewer, with no context about what you were trying to do, tests without those assumptions.
The key requirement: the QA agent must have zero context from the build session. It should not know what you were trying to achieve, what trade-offs you made, or what you considered and rejected. This bias-free perspective is what makes it valuable.
Real-World Example: Cold Email Campaign
Pattern 3: Stochastic Consensus
For high-stakes decisions where you genuinely do not know the right answer, spawn 5-10 agents with slightly different framings of the same question. The answers that appear across multiple independent agents represent high confidence. Answers that only appear once represent genuine uncertainty.
The magic of this pattern is in the contradictions. When two agents with different framings reach the same conclusion, you can be confident. When they contradict each other, you have found a real trade-off that deserves deliberate choice rather than being papered over by a single agent's bias.
Real-World Application: Building a Landing Page
Combining all three patterns for a single deliverable:
- Fan Out research: 3 Sonnet agents each research 5 competitors' landing pages - headline structure, offer framing, proof elements, CTA design
- Opus synthesis: One Opus agent turns the research into a landing page brief with the strongest elements from each competitor
- Developer agent: Builds the page from the brief
- QA agent (fresh): Reviews the page for conversion issues, mobile problems, load speed, clarity of value proposition
- Stochastic consensus on headline: 5 agents each write 3 headline options with different framings, pick whichever appears most consistently
This sounds like a lot of steps. In practice, steps 1-3 run in the background while you do other work. Steps 4-5 take 10 minutes. Total time investment from you: 30 minutes. Total quality: significantly higher than any single-agent approach could produce.
Token Conservation Rules
Parallelization increases quality but can increase cost if not managed. These rules keep spending in check:
| Rule | Why It Saves Tokens |
|---|---|
| Sonnet for research, Opus for synthesis only | Never use Opus for tasks that are primarily reading and summarising. Reserve it for high-reasoning synthesis work. |
| One Write over many Edits | When rewriting a large file, do it in one operation. Multiple small edits each start a new context, wasting tokens on preamble. |
| Store API docs locally | If you use an API repeatedly, download the docs and reference them from disk. Re-fetching the same documentation on every session is pure waste. |
| Scope your sub-agents tightly | A sub-agent with a narrow task processes fewer tokens and produces better output. "Research competitor pricing" beats "Research everything about this competitor." |
| Use -p for disposable tasks | The claude -p flag runs a one-shot query without maintaining a session. No session overhead, no accumulated context cost. |
When NOT to Parallelize
Parallelization has overhead. There is coordination cost, synthesis time, and the complexity of managing multiple outputs. Do not apply it to:
| Scenario | Why Parallel Doesn't Help |
|---|---|
| Simple, well-defined tasks | "Write me a git commit message for these changes" does not benefit from 5 agents. One is fine. |
| Sequential dependencies | If task B requires the output of task A, you cannot run them in parallel. Build step 2 genuinely needs the code from step 1. |
| Conversational tasks | Debugging a specific error interactively is a back-and-forth dialogue. Parallelization does not help here. |
| Small decisions | Not every choice warrants consensus. Reserve stochastic consensus for decisions that will compound over time. |