Most teams pick a model and use it for everything. The best model available, usually. The reasoning is intuitive: more capable model, better results.
The problem is that “capability” is multidimensional, and different tasks need different things. Using Claude Opus to format a PR description is like hiring a senior architect to write meeting notes. The notes will be excellent. The cost makes no sense.
In our 15-agent system — an LLM agent architecture where every tier is matched to a model that fits the job — model selection is an intentional design decision for each agent tier. Here’s the framework.
What different tasks actually need
Deep reasoning tasks need a model that can hold complex context, reason about ambiguity, and make judgment calls under uncertainty. Requirements analysis. Architecture decisions. Feature scoping. These tasks have high stakes and low frequency — you run them occasionally, and getting them wrong is expensive.
Code generation tasks need speed, reliability, and domain knowledge. These tasks run frequently — every story, every PR — and produce large outputs. A slower, more expensive model doesn’t improve correctness enough to justify the cost at this volume.
Deterministic formatting tasks barely need a model at all. PR description templates. Structured ADO updates. Markdown formatting. These are pattern-matching operations with a known template. A smaller, faster, cheaper model handles them just as well as a frontier model.
How we mapped this in practice
| Agent tier | Task type | Model | Reasoning |
|---|---|---|---|
@feature, @story, @requirements, @plan |
Orchestration, analysis, planning | Claude Opus | High stakes, needs deep reasoning, low frequency |
@code-backend, @code-frontend, @test-api, @test-e2e |
Implementation | Claude Sonnet | High frequency, speed matters, correctness verified by reviewers |
@author-req, @author-code, @author-tests |
Quality gate review | Claude Sonnet | Pattern-matching against known criteria, volume is high |
@code-review |
Security and pattern review | Claude Opus | Nuanced judgment, finding non-obvious issues |
@pr-create |
PR formatting | GPT-5.4 mini | Deterministic template, no reasoning needed |
The cost story
The model distribution matters because frequency and cost compound differently across tiers.
Orchestrators run once per story. If that’s expensive, it’s a one-time cost for work that determines all downstream output. Worth it.
Implementers run multiple times per story — one for backend, one for frontend, potentially retries with author agents. Volume is high. Using an Opus-class model here doesn’t improve correctness enough to justify 5–10x the cost at this frequency.
PR formatting runs for every PR. It’s structured. It’s templated. There is no scenario where a frontier reasoning model adds value here over a fast, cheap completion model.
The principle
Model selection should follow the same logic as any resource allocation decision:
- What does this task actually need? Reasoning, speed, throughput, or structured output?
- How often does it run? The more frequent, the more the per-call cost compounds.
- What’s the cost of a wrong output? High-stakes outputs justify expensive models. Low-stakes, reviewable outputs don’t.
The answer isn’t always “use the cheapest model.” It’s “match the model to what the task needs, and don’t pay for capability you’re not using.”
A well-designed agent pipeline is one where every model is doing exactly what it’s good at, at the right price point. That’s not cost-cutting. That’s architecture.