Why I don't use one Opus for everything — model tiering in a multi-agent system
Running the most powerful model on every task is wasteful and slow. Here is how I split work across Haiku, Sonnet, and Opus — and why it matters at scale.
When I built my 9-agent code review system, the obvious approach would have been simple: throw the most powerful model at every problem. One Opus, maximum intelligence, done.
I didn't do that. Here's why.
The question nobody asks
Most AI tooling discussions focus on which model is best. That's the wrong question. The right question is:
What kind of thinking does this task actually need?
After a week of building and tuning this system — writing nearly 2,900 lines of instructions across nine agents — I landed on a simple mental model:
| Thinking type | Model | When to use |
|---|---|---|
| Pattern matching | Haiku | Binary checks, convention enforcement, known anti-patterns |
| Reasoning | Sonnet | Context-dependent analysis, architectural decisions |
| Orchestration | Opus | Large context, synthesis across many inputs, coordination |
Haiku doesn't think — it matches
My TypeScript Standards agent runs on Haiku. Its job is straightforward: find
any, flag wrong import patterns, catch naming convention violations. I gave it
exactly the patterns to look for — nothing more.
That's the key insight: Haiku doesn't think, it matches. Give it a clear pattern and it's fast, cheap, and accurate. Ask it to reason about context and it struggles.
The same logic applies to my Styles & CSS and Storybook agents. "Does this component use a design token or a hardcoded value?" Binary question, binary answer. Haiku handles it well.
Does Haiku sometimes fail? Yes — occasionally it crashes and returns nothing. But the system is built for resilience. If one agent fails, the other seven continue. Partial results are always better than a blocked review.
Sonnet is where reasoning happens
Security, Algorithm & Performance, React architecture, Code Reuse — all Sonnet. Because these tasks can't be answered with pattern matching.
"Is this an XSS vector?" requires context. "Does this hook introduce unnecessary re-renders?" requires understanding component lifecycle. "Is this logic already implemented in shared utilities?" requires knowing the codebase.
That's reasoning. Haiku gets it wrong. Sonnet gets it right.
Opus is too expensive to waste on pattern matching
In real production systems, Opus should do what only Opus can do — consume large context, synthesize across many inputs, make high-level decisions. That's exactly what my Orchestrator does: fetch the diff, route files to the right agents, aggregate results, resolve conflicts, filter noise.
Running Opus on every agent would be like hiring a senior architect to check if your variable names follow conventions. Technically capable. Completely wasteful.
The economics compound fast
One full code review using Opus across all 8 agents consumes roughly 3x more tokens than my current Haiku/Sonnet split — for zero meaningful quality gain on pattern matching tasks.
At scale, that multiplier matters. Every review you run, every PR your team opens — the difference between "right model for the task" and "most powerful model for everything" adds up fast.
Model tiering isn't about cutting corners. It's about matching the cost of thinking to the complexity of the task.
What this looks like in practice
| Agent | Model | Why |
|---|---|---|
| React Agent | Sonnet | Component architecture requires reasoning |
| TypeScript Standards | Haiku | Pattern matching — find any, flag conventions |
| Security Agent | Sonnet | XSS and injection require context |
| Algorithm & Performance | Sonnet | Complexity analysis requires reasoning |
| Code Reuse | Sonnet | Requires knowing the full codebase |
| Styles & CSS | Haiku | Design token checks are binary |
| Storybook Agent | Haiku | Convention enforcement, no reasoning needed |
| UX/UI Design System | Sonnet | Atomic design hierarchy requires judgment |
What's next
I'm currently building an agent that enforces Storybook component conventions —
making sure developers use <Link> instead of <a>, <Button> instead of
<button>. Pattern matching at its purest. Haiku territory.
More on that soon.
Full architecture breakdown of the system: How I built an AI code review system with 8 agents
Was this helpful?