Which Model to Use for Subagents: A Decision Rule

The moment you actually hit this question

You're writing a Claude Code subagent, or adding a helper to a Forkbench squad, and you reach the line that asks for a model. The options are sonnet, opus, haiku, fable, a full model id, or inherit. Setting everything to the strongest one available feels like the safe choice, and it costs nothing to type.

It isn't the safe choice. It's the expensive one, and it's expensive before a single subagent has done any work. A lead agent deciding how to break a job into pieces and a subagent running one of those pieces are not doing the same kind of task, even though both get called agents in the same sentence. The question worth asking isn't which model is best. It's what this particular piece of work actually needs.

• The frontmatter options are sonnet, opus, haiku, fable, a full model id, or inherit.
• A lead splitting up a job and a subagent running one piece of it are different kinds of work.

Which model a subagent actually uses: the four-step order

Claude Code does not pick a subagent's model by guessing. It resolves it in a fixed order, and whichever step sets a value first wins. Every step after that one is ignored.

The order, from the top:

• First, a per-invocation parameter. If whatever starts the subagent names a model directly in that call, that value wins outright, no matter what else is configured.
• Second, the model field in the subagent's own frontmatter. This is where most people set it: sonnet, opus, haiku, fable, a full model id, or inherit, which tells the subagent to run whatever the main conversation is running.
• Third, the CLAUDE_CODE_SUBAGENT_MODEL environment variable, a session or machine-wide default for any subagent that hasn't set its own field.
• Fourth, with none of the first three set, the subagent inherits the main conversation's own model.

Anthropic's own system: a strong lead, cheaper workers

Anthropic didn't just recommend this split, it built its own multi-agent research system on it and published the result: a lead agent on Claude Opus 4 plans the investigation, and the subagents it calls to gather information run on Claude Sonnet 4. In Anthropic's internal research evals, that orchestrator-worker system beat a single Opus 4 agent working alone by 90.2%.

The split matches what each role does. Deciding what to investigate and how to divide it among subagents is a judgment call with no single right answer, the kind of task that benefits most from the strongest model available. Searching for a fact once someone has decided what to look for is bounded and checkable, work a faster model can do plenty of in parallel without wasting the extra strength.

Anthropic is specific about where this does not fit, too: domains needing shared context across the whole task, or with a lot of dependencies between agents, are, in Anthropic's own words, not a good fit for the pattern, strong lead or not.

• Lead agent Claude Opus 4 plans; subagents on Claude Sonnet 4 gather information.
• Stated limit: domains needing shared context, or with many dependencies between agents, are not a good fit for the pattern.

A rule of thumb you can copy

Here's the rule in one line: give the strongest model to whatever has to decide, and give a cheaper, faster model to whatever has a clear, checkable finish line.

Point the lead's strength at breaking a job into tasks nobody has broken down yet, any call where getting it wrong wastes work downstream, talking to you when something is ambiguous or missing, and deciding when a piece of work is actually finished.

Point a cheaper, faster model at running a search across a codebase or a pile of documents, formatting or extracting data into a shape you've already specified, applying a fix or a diff that's already been decided, and writing a test against a spec that's already written.

Haiku vs Sonnet for subagents isn't a single answer; it depends which bucket the task is in. A subagent that greps a codebase for every call site of a renamed function sits squarely in the bounded-work bucket. One that has to decide whether a tradeoff is acceptable does not, no matter how small the diff looks. That's the shape behind Opus for orchestrator, Sonnet for workers: the orchestrator spends its strength deciding, the workers spend theirs doing.

• Lead: breaks the job into tasks, owns the plan, makes the judgment calls, talks to you when something's ambiguous.
• Worker: runs a bounded search, applies a decided fix, formats output, writes a test against a spec you already wrote.

Where a weak model actually costs you: the lead, not the worker

Most of the worry about model choice goes toward the subagent, and that's backwards. Anthropic's own numbers put the weight on the other side: token usage alone explained about 80% of the difference in performance across their tests, and a multi-agent system already spends roughly 15 times the tokens of a single chat turn, against roughly 4 times for one agent alone. A lead that misjudges what to build doesn't pay for that once, it pays across every subagent it then calls, in early testing enough to spawn 50 subagents for a query that needed a handful.

There's a second cost that isn't about model strength at all. Anthropic's own writeup calls synchronous execution a bottleneck, because the lead has to wait for an entire batch of subagents to finish before it can decide what happens next. A weaker model in that seat doesn't just make worse calls, it makes them slower, since every wrong call means another full round trip before anyone notices.

None of this argues for the strongest model on every worker instead. A cheap model handed a genuinely ambiguous task still burns through retries and lands somewhere wrong, just more slowly. The saving only shows up when the task was actually bounded to start with.

• Token usage alone explained about 80 percent of the difference in performance in Anthropic's own tests, against a roughly 15x token cost for a multi-agent system versus a single chat turn.
• Synchronous execution is a bottleneck by itself, since the lead waits for a whole batch of subagents before deciding what's next.

The same split, and its edges, show up at every vendor

Claude Code's subagents aren't its only answer to this. Agent Teams puts a lead session and teammate sessions on one shared task list that they can message each other through, with each teammate keeping its own context window. It's experimental, off by default, and like subagents, it lives entirely inside a single Claude Code session.

Codex ships the same underlying idea under a different name: subagent workflows run by default through an agents table in config.toml, follow delegation instructions written in AGENTS.md, and spawn in parallel. Codex's own docs recommend subagents specifically for read-heavy work, to avoid what they call context pollution and context rot, and warn that parallel write-heavy work can create conflicts, the same bounded-work split as the rule of thumb above, in a second vendor's own words.

Google shipped an equivalent for Gemini CLI, an isolated context window, curated tools and a custom system prompt per subagent, before retiring the CLI in June 2026. Cursor publishes no recommended agent count and is explicit that reviewing the output, not computing it, is the practical limit, which has nothing to do with model tier.

Not everyone thinks the split should exist at all. Cognition's public case for a single, linear agent is that every action carries an implicit decision, and agents that can't see each other's context end up making conflicting ones. That's a real constraint on any lead-and-workers pattern, and why the rule of thumb above draws its line at a genuinely bounded task: hand out work that isn't, and the same problem shows up anyway, with extra model tiers on top.

• Codex: subagents run by default through an agents table in config.toml, recommended for read-heavy work to avoid context pollution and context rot.
• Cursor publishes no recommended number of concurrent agents; reviewing the output is the stated practical limit, not model tier.

Forkbench's part in this: coordination, not model routing

A Forkbench squad looks like it might make this decision for you, so it's worth being precise about where it does and doesn't. A helper in a squad is a name, a command, and a one-line description the other agents see. Forkbench ships ready-made helpers for exactly this split: one named Claude Opus runs claude --model opus, described to the lead as strong, the usual choice for real work; one named Claude Sonnet runs claude --model sonnet, described as faster and cheaper, good for well-scoped mechanical tasks. Codex, Cursor, Antigravity and Gemini ship as helpers too, each on its own default model, and you can add more.

So inside a squad, the rule of thumb above becomes a question of which helper the lead calls for a given task, and the one-line description is how it knows which one fits. That's coordination, not routing: a person wrote the command behind each helper before any task was assigned. Forkbench doesn't read what a task needs and swap the model underneath it. Each helper still starts as its own session with a clean context, a lead can suggest a helper it wants but nothing is added until a person approves it, and a helper reporting a task finished only moves it to awaiting acceptance, a human still has to accept it before it counts as done.

• A helper named Claude Opus runs claude --model opus, described to the lead as strong, the usual choice for real work; a helper named Claude Sonnet runs claude --model sonnet, described as faster and cheaper, good for well-scoped mechanical tasks.
• Each helper still starts as its own session with a clean context, and a human has to accept a finished task before it counts as done.