Since Claude Opus 5 landed on July 24 at $5/$25 per million tokens — half the flagship price of its predecessor — Claude Code has added a feature that matters more than the price cut itself: subagents can now declare their own model and effort in frontmatter, independent of the session default. The effort field runs low → medium → high → xhigh → max, and it “overrides the session effort level” per subagent.

I’ve spent the last few weeks running a multi-agent Claude Code setup (a fan-out of specialized subagents for research, code review, and verification) and rewiring it around this. The result is a genuinely different cost profile, not just a discount. Here’s what I learned wiring it up.

The core idea: effort is not the same knob as model choice

It’s tempting to treat “which model” and “how hard should it think” as the same lever — pick a cheaper model for cheap tasks. But Opus 5’s effort parameter is a second, orthogonal axis: it controls token spend per request within the same model, not which model runs. That means you get finer-grained control than model-switching alone, and it composes with model choice rather than replacing it.

A workable default map, based on task shape rather than vague “importance”:

Task shapeEffortWhy
Classification, extraction, routing, high-volume well-scoped jobslowAnthropic explicitly names this as the fit
Narrow sub-tasks inside a larger planlowThe planning agent already did the hard reasoning
General agentic work, knowledge tasksmediumDefault for “normal” subagent work
Difficult coding, nuanced analysishighThe default tier for most coding subagents
Long-horizon coding, repeated tool calling, deep explorationxhighReserved for genuinely hard, multi-step problems
Rare frontier problemsmaxUsed sparingly — this is the expensive tier

What this looks like in a subagent definition

---
name: pr-triage
description: Classify incoming PRs by risk and route to the right reviewer subagent
model: claude-opus-5
effort: low
---
---
name: architecture-reviewer
description: Deep review of cross-cutting architectural changes before merge
model: claude-opus-5
effort: xhigh
---

Two subagents, same model, wildly different cost per invocation, because the task shapes are different. Before this shipped, the only lever was swapping models entirely — which meant either overpaying for triage or underpowering the architecture review.

The mistake I made first: setting effort by agent role, not by task shape

My first pass mapped effort to agent identity — the “research agent” always ran medium, the “code review agent” always ran high. That’s the wrong axis. A code review agent triaging a one-line typo fix doesn’t need high effort any more than a research agent doing deep multi-source synthesis needs to stay at medium. The fix was routing effort dynamically based on the task’s shape, evaluated per invocation, not baked into the subagent’s static frontmatter:

function selectEffort(task: SubagentTask): EffortLevel {
  if (task.isHighVolume && task.isWellScoped) return "low";
  if (task.isPartOfLargerPlan && task.scopeIsNarrow) return "low";
  if (task.isArchitectural || task.isLongHorizon) return "xhigh";
  if (task.requiresDeepAnalysis) return "high";
  return "medium";
}

This means the frontmatter effort: value is really a default, and the actual value gets set per-call when your orchestration layer has more context than the subagent’s static definition can encode. Static frontmatter is fine for single-purpose subagents (like the PR triage example above, where every invocation genuinely is low-effort). It breaks down for subagents that get reused across a wide spread of task difficulty.

Where the savings actually showed up

Running this on a real fan-out workflow (structured review across four dimensions, each spawning verification subagents) for two weeks:

  • Triage and routing subagents dropped from medium to low — no measurable quality regression, since these tasks are genuinely mechanical.
  • Verification subagents (the ones re-checking another agent’s finding) stayed at high, because a cheap verifier that rubber-stamps findings defeats the point of adversarial verification.
  • The one subagent I bumped up, to xhigh — a long-horizon codebase migration planner — actually got measurably better plans, catching cross-file breakage that high effort missed twice in a row.

Net effect: total token spend per full review cycle went down, because the volume-heavy triage layer got cheaper, while the accuracy-critical layer got more expensive but ran far less often. That’s the shape you want — cost tracks task shape, not agent count.

The takeaway for a multi-agent estate

If you’re running Claude Code with any kind of subagent fan-out, treat effort as a routing decision you make per task, the same way you’d route between model tiers. The temptation is to set it once per subagent and move on — but the subagents that get reused across varied task difficulty are exactly the ones where a static effort level either overpays on the easy cases or underdelivers on the hard ones. The dial is only worth the plumbing if you actually wire it to task shape, not agent identity.

Sources: Claude Platform Docs — Prompting Claude Opus 5, Claude Opus 5 effort levels: cut token spend, Claude Code Model Selection Guide

Export for reading

Comments