Stop paying Opus rates for Haiku subagent work
Claude Code lets you set a model per subagent. Send mechanical work to Haiku, keep judgment on Sonnet or Opus, and stop paying premium rates for grep and test runs.
Claude Code lets you set the model per subagent with a single model field in the agent's frontmatter. Most people never touch it, so every subagent runs on the same top model as the main thread — and they pay premium rates for work a smaller, faster model does just as well. The routing rule is simple: mechanical, well-scoped tasks (search, formatting, running tests, boilerplate) go to Haiku; judgment-heavy tasks (architecture, subtle debugging, security review) stay on Sonnet or Opus. This guide covers the model field, what each tier is good enough for, the rough cost math, and a sane default routing.
If you are still deciding whether a subagent is even the right primitive for the job, start with skills vs subagents vs commands. This guide assumes you have decided to delegate and now want to delegate cheaply.
The per-agent model field
A subagent is a Markdown file with YAML frontmatter — name, description, optional tools — and a system prompt. Add one more line, model, and that subagent runs on the model you name, regardless of what the main session is using.
---
name: test-runner
description: Runs the test suite and reports failures. Use after code changes.
tools: Bash, Read, Grep
model: haiku
---
Run the project's tests, read the failures, and report the failing test names
and the error lines. Do not attempt fixes — produce a short, clean report.The model field accepts an alias — haiku, sonnet, or opus — or inherit to use whatever the main session is on. Leave it out and the subagent falls back to the configured default. That one line is the whole mechanism, documented in the Claude Code subagents reference and popularised by a widely-shared 10x Playbooks post. The skill is not the syntax; it is knowing which alias to write.
Reach for inherit when a subagent should track the main session — a reviewer you sometimes run under Opus for a high-stakes change and under Sonnet for a routine one. Pin an explicit haiku or sonnet when the task's difficulty is fixed regardless of what the main thread is doing, which is most of the time. A test runner does not get harder because you happened to open the session in Opus, so pin it to Haiku and leave it there.
What each tier is actually good enough for
Pick the smallest model that reliably completes the task. Overspending on a mechanical task buys you nothing. Underspending on a judgment task costs you rework — which is far more expensive than the token difference you were trying to save.
| Tier | Good enough for | Do not use it for |
|---|---|---|
| Haiku | File search, grep and glob, running tests, formatting, renaming, mechanical extraction, log triage | Design decisions, subtle debugging |
| Sonnet | Most coding, refactors, code review, writing tests, routine debugging | It is the workhorse — few tasks are beyond it |
| Opus | Hard architecture, gnarly multi-file debugging, security-critical review | Bulk mechanical work — you are overpaying |
The boundaries move as models change; the principle does not, so re-check the table when a new model ships. Sonnet is the sensible default for the main thread. The wins come from pushing narrow, high-volume subagent work down to Haiku and reserving Opus for the genuinely hard calls.
The cost math (approximate)
Exact pricing changes and depends on your plan — a Pro or Max subscription meters usage differently from pay-as-you-go API billing, and Anthropic updates its rates. Treat the following as an order-of-magnitude illustration, not a quote. A third-party price tracker, benchlm.ai, lists approximate API rates per million tokens roughly in the range of Opus $5 in / $25 out, Sonnet $3 in / $15 out, and Haiku $1 in / $5 out. These are not official figures — confirm Anthropic's current pricing before you budget against them.
What matters for routing is the ratio, and the ratio is stable even when the exact numbers are not: on those figures, Haiku output costs roughly a fifth of Opus and a third of Sonnet. So a subagent that reads logs, runs tests, or greps a large repo — high token volume, low judgment — is precisely the work you do not want billed at Opus rates. Move it to Haiku and you change nothing about the result and a great deal about the bill.
Make it concrete with the ratio alone, no invented totals needed. A codebase-exploration subagent that chews through a few hundred thousand tokens of reading in a session is almost all input tokens and almost no judgment. On the ratio above, running it on Haiku instead of Opus cuts that subagent's cost by roughly four-fifths for identical output — and you will fire it dozens of times a week. The savings are not in any single call; they are in the volume of cheap, mechanical calls you stop overpaying for.
A sane default routing
Here is a routing that holds up in practice and is the kind of default a curated kit should ship — conservative, adjustable, and biased toward the cheapest model that reliably does the job.
| Subagent kind | Model | Reason |
|---|---|---|
| Search / codebase explorer | Haiku | High volume, mechanical, no hard judgment |
| Test runner / linter | Haiku | Run and report, do not decide |
| Formatter / renamer / codemod | Haiku | Deterministic edits |
| General coder / refactorer | Sonnet | The everyday workhorse |
| Code reviewer | Sonnet | Good judgment at reasonable cost |
| Architecture / hard debugging | Opus | Worth the premium when rework is costly |
| Security review | Sonnet or Opus | Do not cheap out where a miss is expensive |
Two guardrails on this. First, the main thread is not a subagent — keep it on Sonnet (or Opus for a hard session) so the orchestration stays sharp, and push the delegated, narrow work down. Second, when a Haiku subagent produces sloppy output, the fix is usually a tighter description and a smaller scope, not a bigger model: a well-scoped Haiku task beats a vaguely-scoped Sonnet one. If your subagent is not running at all, that is a different problem — see why your subagent is not being called.
The mistake to avoid
The mistake is setting model: opus everywhere 'to be safe', or never setting model at all and letting every throwaway search burn premium tokens. Both pay top rates for bottom-tier work. Do the opposite: default subagents to Haiku, promote to Sonnet when quality slips, and reserve Opus for the handful of tasks where a wrong answer costs more than the model does. Set the field once per agent, keep the routing in version control, and revisit it when a new model ships. The same instinct — do not pay for capacity you are not using — is why a lean set of MCP servers beats a crowded one. Capacity you are not using is not safety; it is waste, whether the unit is a model tier, a server, or an agent you never call.