Why expensive models make terrible execution subagents

Reasoning training buys capability and sells instruction following#

Start with the thing nobody in this conversation cites. ReasonIF, from Together AI and Stanford, measured how often a reasoning model actually obeys an instruction inside its own reasoning trace rather than in its final answer. The gap is not subtle.

Averaged across six models, instructions were followed 15.6% of the time in the trace against 57.3% in the response. Tell the model to emit JSON and apply that constraint to its thinking, and compliance goes to zero. Every model tested, no exceptions.

The best responder in the study makes the point sharpest. Qwen3 235B Thinking tops the table at 78.7% response compliance and still only manages 25.0% inside its own trace. Capability and obedience came apart.

The inferential step matters here. ReasonIF measured six open-source reasoning models, not the closed frontier models you are probably running. That makes it the strongest available prior rather than a proof about Opus or GPT.

Now look at what an execution subagent actually is. A narrow task, a fixed output shape, a boundary you wrote down. You are buying the one capability that measurably degrades the behaviour you need.

The capable executor does more than you asked#

Read Anthropic's own Opus 5 prompting guidance and it reads like a bug report filed against the model. It expands task scope. It over-verifies when told to verify. It writes longer files, narrates more, and delegates to subagents more readily than the models before it.

The page then ships prompt text to suppress each behaviour. That is the vendor of the most expensive model telling you, in writing, that it does more than you asked on narrow work.

The newest model does not fix this. Anthropic's Fable 5 page says that on routine work at higher effort the model can gather context and deliberate beyond what the task needs. Same concession, one generation later.

UnderSpecBench put numbers on the behaviour by measuring how often an agent acts outside a stated boundary. The configuration running the cheapest model scored the lowest over-scope rate at 24.9%. The most eagerly-acting configuration hit 44.4%.

That comparison varies harness and model together, so it is not a clean model-tier ablation. It points the same way as everything else here, and it is directional support rather than proof.

The cost of over-scoping is not the tokens. It is that every line beyond the boundary arrives unrequested and therefore unreviewed, in a diff you were skimming because you thought you knew its size.

When the worker verifies itself and spawns its own workers#

Claude Code v2.1.172 let subagents spawn their own subagents, five levels deep. Combine that with a model documented as delegating more readily than its predecessors and you get a failure mode that is not merely expensive.

Issue #68110 is the clearest write-up. One delegation, phrased as research a payment integration, fanned into 48 or more concurrent agents burning roughly 1.5 million tokens. The reporter's own summary is the part worth keeping.

The useful research was complete within the first three or four agents. The remaining 44 added no new information.

Issue #77414 documents the blast radius. Three incidents expanded into roughly 380 to 583 agent records, saturated a 16 core machine at 100%, and forced a hardware restart. Stop did not stop it, and around 256 further nested calls happened after the stop was issued.

The reporter's diagnosis is the sentence to remember. Recursive depth is capped. Breadth is not.

You see this in the logs before you see it on the bill. Three strings worth grepping for.

• No task found with ID: <id>, an orphaned grandchild that still shows as running and cannot be stopped.
• Agent terminated early due to an API error: is what a drained plan looks like from inside a fan out, on v2.1.199 and later.
• No-op while waiting for background agents, a parent burning turns while its own children work.

This is not one vendor's bug either. The opencode tracker carries the same unbounded-recursion report against its own task tool.

What a wide fan out multiplies#

Five children per agent, five levels deep, is 3,125 agents alive at the documented cap.

That curve is a projection rather than a measurement, which is why the observed 380 to 583 matters more. Real incidents landed two orders of magnitude above what anyone intended and one order below the theoretical ceiling.

There is no clean token multiplier to put here. Every fan-out cost figure in circulation traces back to a vendor blog or a restatement of one, which is why this section counts agents instead of dollars.

So the number to reason about is breadth, not a multiplier. Depth has a cap you can point at. Breadth is bounded by whatever your workers decide, which is exactly the thing an eager model is documented as getting wrong.

The two dials you already have#

Most write-ups on this stop at pinning a cheaper model. There are two fields, both per subagent, both in the Claude Code subagent docs supported-fields table as of v2.1.216.

---
name: executor
description: Applies one scoped change. Does not explore.
model: haiku
effort: low
---

The effort field is the one nobody mentions. It overrides the session effort level for that subagent, and Anthropic's effort docs name subagents as the canonical case for low effort in the model-agnostic table.

Effort does more than shorten thinking. At low effort the model combines operations into fewer tool calls and proceeds to action without preamble, which is tool-call spend and not just token spend.

The default is the trap. An unset subagent inherits your session's effort, and the session itself runs at high unless you changed it. Setting effort to high behaves identically to omitting it, so the quiet path lands on the expensive setting.

One version-specific fact is worth more than the rest of this section combined. As of v2.1.198 the built-in Explore subagent stopped defaulting to Haiku and now inherits your main conversation's model. Your exploration worker got quietly more expensive, and every article recommending Haiku for it predates the change.

---
name: Explore
model: haiku
---

Defining a subagent named Explore overrides the built-in and keeps its own model field. That is the whole fix. This is the same failure mode as skills that quietly age past their model, and it is why anything you read on this topic needs a version stamp attached.

Codex has the same two dials under different names. A custom agent file takes model and model_reasoning_effort, with gpt-5.6-terra named in the docs as the lower-cost option for lighter subagent work. Verified 2026-07-28, since that page carries no version.

name = "reviewer"
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

One trap to know before you tune this. Changing the effort value between requests invalidates prompt caching, so vary effort across workloads rather than inside a conversation that depends on cache hits.

There is a good reason to configure this per role rather than trust a default, and it is that the defaults move. Anthropic's Opus 5 page tells you to strip verification instructions and stop delegating small work. Its Fable 5 page tells you to use subagents frequently and says fresh-context verifier subagents tend to outperform self-critique.

Both pages are current. Both are official. The guidance reversed inside one model generation, which is the argument for pinning your own config rather than inheriting whatever this month's default happens to be.

When splitting the work is itself the mistake#

The strongest objection to everything above is not that you should use a big executor. It is that you should not be splitting at all.

Fabio Akita benchmarked mixed-model combinations across three rounds and a solo frontier model in a mature harness won. Tier A quality at 97 out of 100, 18 minutes, about four dollars. No multi-agent combination beat it on quality, and none was cheaper at the same time.

That is one engineer on one task family rather than a peer-reviewed multi-task result, and it deserves that label. It also points the same way as a 2026 paper arguing that reported multi-agent advantages are better explained by unaccounted computation and context effects than by architecture.

The mechanism is worth understanding because it decides when splitting pays. Edits are a small fraction of what an agent spends. Most of the bill is reading, so a planner that reads everything at frontier prices and then hands a worker a task that makes it read again has duplicated the expensive part instead of moving it.

Splitting wins when the workers do genuinely independent reading that the planner never has to hold. It loses when the split is cosmetic and the same context gets paid for twice.

The claim has a hard limit. Nobody has published a head-to-head showing an expensive model in an execution subagent produces worse code than a cheap one on the same constrained coding subtask. The nearest result is a code review study where Haiku 4.5 beat Sonnet 4.6 on F1 at 3.2 times lower cost, and review is judgement rather than execution.

So the defensible claim is the four-part one. An expensive reasoning model in an execution slot costs more, runs slower, over-scopes more, and complies with your spec less. Whether it also writes worse code is unmeasured.

The decision rule falls out cleanly enough, and it fits on three lines.

• Spend reasoning where the problem is still open, which is usually the plan.
• Pin it low where you already closed the problem yourself, which is every worker you wrote a spec for.
• Treat an unconfigured subagent as a bill you never agreed to, because that is what the default makes it.

The expensive model is not bad at this work. It is expensive at ignoring the constraints you spent tokens writing down, and you are the one paying for the ambiguity you already removed.