Multi-Model Orchestration: Fable 5.1, Opus 5.5, Sonnet 5

Making a coding agent run every task on the same model is now both expensive and slow: according to Anthropic's official pricing page, input cost varies by up to 5x between Sonnet 5, Opus 5.5, and Fable 5.1. In this article I walk through multi-model orchestration for coding agents — based on official documentation — covering which task goes to which model, how to keep delegation explicit, and how to measure the cost.

💡 Pro Tip: Never leave the model field empty in a subagent call; an empty call falls through, in order, to the definition's frontmatter, then the CLAUDE_CODE_SUBAGENT_MODEL variable, and finally the main conversation's model — exploration work that should be cheap can silently drift onto the expensive model.

Table of Contents

• The Single-Model Era Is Over: The Cost-Capability Curve by Task Type
• Model Roles: Exploration/Mechanical, Specified Code, Hard Verification
• Official Positioning and Pricing Table (Fable 5.1 / Opus 5.5 / Sonnet 5)
• The Delegation Rule: Give Every Subagent an Explicit Model
• Context and Cache Economics (The $0.25/MTok Cache-Read Effect)
• Writer ≠ Verifier: Cross-Checking in a Fresh Context
• Measuring the Orchestration Setup in Your Own Project
• Steps to Set This Up in Your Own Project
• FAQ
• Which Claude model should I use for which task?
• What's the difference between Fable 5.1 and Opus 5.5?
• How do I reduce model cost in a coding agent?
• How do you delegate work to subagents?
• Is Opus 5 still available?
• Conclusion
• Sources

The Single-Model Era Is Over: The Cost-Capability Curve by Task Type

Doing everything with a single model loses both ways: either you run the most expensive model for a basic file scan, or you hand a critical architectural decision to the cheap model and raise the risk of error. Anthropic's official pricing page draws a clear line between three tiers: Sonnet 5 at $2 input / $10 output per MTok, Opus 5.5 at $4 / $20, and Fable 5.1 at $10 / $50 — a full 5x jump in input cost from Sonnet to Fable.

The official subagents documentation describes this cost-capability tradeoff directly: "Control costs by routing tasks to faster, cheaper models like Haiku." The same logic applies to the three-tier Sonnet/Opus/Fable setup — the more mechanical and repetitive the task, the cheaper the model should be; the more a task involves a hard-to-reverse decision, the more expensive the model should be.

In practice: finding a function in a file, searching for a pattern across many files, or summarizing an API response finish on the cheap/fast model. Designing a new auth flow, changing a database schema, or touching payment logic go to the more expensive, more capable model instead.

Ignoring this curve has two typical outcomes. First, routing every call to the most expensive model (Fable 5.1): even a file search runs on the most expensive model with its 1M context window, at five times Sonnet's per-turn input cost, a payoff that doesn't cover the gap when the task was already within the cheap model's scope. Second, the opposite: handing a critical code path (auth, payments, data integrity) to the cheapest model looks like savings at first, but a misread spec or a missed edge case — with its fix cost of a second delegation round, manual review, or a possible production bug — erases those savings many times over. The right setup isn't a choice between the two — it's moving between the three tiers according to the nature of the task.

Model Roles: Exploration/Mechanical, Specified Code, Hard Verification

The official model-config documentation maps model aliases directly to role definitions: sonnet is recommended for "daily coding tasks," opus for "complex reasoning tasks," and fable for "your hardest and longest-running tasks." This three-way split isn't arbitrary — Explore, one of Claude Code's own built-in subagents, is a live example of it.

Per the official sub-agents documentation, Explore's model "inherits from the main conversation, capped at Opus on the Claude API, so Explore never runs on a more expensive model than the one you already chose for the session, unless you set CLAUDE_CODE_SUBAGENT_MODEL and force it onto every subagent." So exploration work by default never runs more expensively than the session's main model — behavior in place since v2.1.198 (before that, Explore always ran on Haiku).

The three roles break down in practice like this:

• Exploration/mechanical: File search, log scanning, repetitive translation, summarizing existing code — Sonnet 5.
• Specified code: Writing a new feature against a defined interface/spec, refactoring, a migration script — Opus 5.5.
• Hard verification / long-horizon agentic work: Multi-step planning, end-to-end verification of a critical code path, cases where Opus falls short even at high effort — Fable 5.1.

The critical point is that these roles aren't static. The same task type (e.g. "write a migration script") can fall into a different bucket depending on the project: adding a single column stays in specified-code, while a hard-to-reverse migration touching multiple tables at once belongs in hard-verification. What decides it isn't the task's name — it's how hard to reverse it is and how many steps of independent reasoning it needs.

Official Positioning and Pricing Table (Fable 5.1 / Opus 5.5 / Sonnet 5)

A current note: Claude Code v2.1.280 (released September 22, 2026) made Opus 5.5 the default Opus model, and opus now resolves to Opus 5.5 — in earlier versions (v2.1.219 through v2.1.280) the same alias pointed to Opus 5. The official model comparison page sums it up this way: "start with Claude Opus 5.5 for most workloads. Use Claude Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Claude Opus 5.5 at higher effort still fall short."

Opus 5 hasn't been retired; it's priced and accessible in the API, but as of September 22, 2026 it's no longer the recommended first choice. A config that still hardcodes claude-opus-5 keeps working, but it's no longer the model behind the default alias.

The Delegation Rule: Give Every Subagent an Explicit Model

Where does a subagent call land with no model specified? The official documentation chain defines four steps: (1) the model parameter at call time, (2) the definition's model frontmatter — inherit selects the main conversation's model here, (3) the CLAUDE_CODE_SUBAGENT_MODEL variable, (4) the main conversation's model. There's no cap at the last step; "capped at Opus on the Claude API" only applies to the built-in Explore entry. Step 1 moved to the front in v2.1.251: "Before v2.1.251, CLAUDE_CODE_SUBAGENT_MODEL came first in this order and overrode both the per-invocation parameter and the frontmatter." So the call itself is the most reliable control point; leaving it unspecified doesn't mean "it runs cheap."

CLAUDE_CODE_SUBAGENT_MODEL_FORCE, introduced in v2.1.257, removes this chain entirely: it "apply[ies] CLAUDE_CODE_SUBAGENT_MODEL (or the main model) to every subagent, ignoring per-spawn and agent-definition model overrides" — so you can override even per-call model parameters when forcing a single model project-wide.

1# Global delegation default: every call without a specified model falls to Sonnet
2# (excludes built-in Explore and Plan - _FORCE is needed to apply to them)
3export CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-5
4 
5# Force mode: even per-call model overrides are ignored
6export CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1

In daily practice the rule is simple: for exploration and mechanical work, explicitly write sonnet in the model field; for specified critical code, explicitly write opus; for risky/long-horizon verification, explicitly write fable. Leaving it empty isn't a shortcut — it's a gamble.

Context and Cache Economics (The $0.25/MTok Cache-Read Effect)

The orchestrator model (Fable 5.1) re-reads the same system prompt, CLAUDE.md file, and conversation history on every turn — this makes up the bulk of input cost in long sessions. The official pricing page defines a special cache-read multiplier for Fable 5.1 and Mythos 5.1: "Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price" — meaning the $10/MTok base input price drops to $0.25/MTok for tokens read from cache. Opus 5.5's multiplier is 0.05x ($4 → $0.20/MTok).

Let's work out the practical effect with a real formula: assume a fixed 50,000-token system prompt (CLAUDE.md + tool schemas) is resent every turn, over a 20-turn session.

1Fable 5.1 — base $10/MTok, 5-min cache write $12.50/MTok, cache-read $0.25/MTok (0.025x)
250,000 tokens = 0.05 MTok
3 
4WITHOUT cache (full price every turn):
5  20 turns × 0.05 MTok × $10/MTok = $10.00
6 
7WITH cache (1st turn cache WRITE, next 19 turns cache-read):
8  1 turn  write → 0.05 × $12.50 = $0.625
9  19 turns cache → 0.05 × $0.25  = $0.0125/turn × 19 = $0.2375
10  Total: $0.625 + $0.2375 = $0.8625   (→ 91.4% savings)

Running the same math for Opus 5.5 (base $4/MTok, 5-min cache write $5/MTok, cache-read $0.20/MTok, 0.05x multiplier): without cache, 20 × 0.05 × $4 = $4.00; with cache, 1 write turn (0.05 × $5 = $0.25) + 19 × 0.05 × $0.20 = $0.19 → total $0.44 (89.0% savings). Both models save at a similar order of magnitude — Fable's lower multiplier offsets its higher base price, so the absolute gap still favors Opus ($0.8625 > $0.44), but the proportional savings are close.

The calculation above only covers the fixed input part — newly generated output tokens and the changing conversation history aren't included in this formula; that part is billed at full price every turn. This is the economic rationale behind the rule "exploration doesn't enter the main context, the subagent returns only a summary": the smaller the main orchestrator's context is kept, the smaller the baseline cost stacked on top of the fixed system prompt.

Writer ≠ Verifier: Cross-Checking in a Fresh Context

What makes this pattern possible is the subagent architecture: per the official documentation, each subagent "runs in its own context window with a custom system prompt, specific tool access, and independent permissions" and returns "only the summary" to the main conversation. This isolation lets code a model wrote be re-read in a fresh context (a separate subagent call), rather than "approved" by the same model in the same context.

In practice: specified code is written by one Opus 5.5 call; the same diff then goes to a separate Opus 5.5 call (or Fable 5.1 for critical work) with the prompt "review this diff against the spec." The second call never sees the first call's reasoning trail — only the code and the spec. That raises the odds the same model catches its own mistake by reading it fresh rather than "remembering" it.

Measuring the Orchestration Setup in Your Own Project

You can see what this setup gains you in your own project by tracking three variables:

• Session token total: /cost (an alias for /usage in the official command list) gives the session total broken down by model: input, output, cache-read, and cache-write. The cache share shows up in a separate "Prompt cache (main)" line, but the official documentation explicitly scopes that line: main conversation only, not subagents. Subagents' share is only listed as a percentage in the plan usage breakdown.
• Wall-clock time: the real elapsed time from the start of the task to its finish — wave length if a parallel wave was used, total wait time if sequential delegation was used.
• Characters entering the main context: the amount of text that enters the orchestrator's own context — the shorter the subagent report (as a rule, ≤1,500 characters), the lower this number stays, and the lower the baseline cost of subsequent turns.

Record all three, before and after, on the same unit of work, and you'll see what the setup gains you in your own numbers.

Steps to Set This Up in Your Own Project

1. Read the alias table in the official model-config documentation and verify, per provider, which alias resolves to which model — on the Anthropic API, opus now resolves to Opus 5.5, and the same holds on Bedrock and Google Cloud, but on Microsoft Foundry opus still resolves to Opus 4.6.
2. Explicitly specify the model field in every Agent/subagent call; treat sending any call with an empty model field as out of bounds.
3. As a guard against global leakage, bind the CLAUDE_CODE_SUBAGENT_MODEL variable in the project or user environment to a cheap-model default; add CLAUDE_CODE_SUBAGENT_MODEL_FORCE if you want full enforcement.
4. Split task types into three buckets: exploration/mechanical → Sonnet 5, specified code → Opus 5.5, risky/long-horizon verification → Fable 5.1.
5. For critical code paths, set up the writer-agent/verifier-agent split with separate context windows; give the verifier agent only the final diff and the spec, not the writer agent's reasoning trail.
6. Track the session total and model breakdown with /cost, and read the cache share from the "Prompt cache (main)" line — this line covers only the main conversation, not subagents. Fable 5.1's 0.025x multiplier becomes more critical as the fixed system prompt grows.

Treat these six steps as a recurring habit, not a one-time setup: as a project grows, CLAUDE.md and tool schemas grow with it, so fixed input cost grows too; re-checking alias resolution and the pricing table with every new model release (as with a future Fable or Opus version after Fable 5.1) keeps the delegation setup from quietly going stale.

The persistent form of model selection is the subagent definition file's frontmatter. The example definition in the official sub-agents documentation carries the model field like this; this field is step 2 of the chain, and the model given at call time overrides it too:

1---
2name: code-reviewer
3description: Reviews code for quality and best practices
4tools: Read, Glob, Grep
5model: sonnet
6---

1Verify which model the subagent ran on within the session:
2 
3  /tasks    Prints the model name on the running subagent's line (v2.1.242+).
4 
5  /model    Selects and shows the main session's model; since it's step 4
6            of the chain, it's the last stop subagents fall to.

FAQ

Which Claude model should I use for which task?

According to the official model comparison documentation, it's recommended you start with Claude Opus 5.5 for most workloads; you're advised to move to Claude Fable 5.1 for demanding reasoning and long-horizon agentic work where Opus 5.5 falls short even at high effort. Sonnet 5, meanwhile, is positioned for daily coding tasks where the balance of speed and intelligence matters most.

What's the difference between Fable 5.1 and Opus 5.5?

Both carry a 1M token context window, but Fable 5.1 runs at high effort by default while Opus 5.5 starts at medium effort. The price gap is significant: Fable 5.1 is $10 input / $50 output, Opus 5.5 is $4 / $20 (per MTok). The official documentation describes Fable as being for "demanding reasoning and long-horizon agentic work," and Opus 5.5 as the first choice for most workloads.

How do I reduce model cost in a coding agent?

Per the official subagents documentation, the way to control cost is to route tasks to faster, cheaper models. In practice, this means handing exploration and mechanical work to Sonnet 5, and reserving Opus 5.5 or Fable 5.1 only for specified critical code. Also, since Fable 5.1's cache-read price is 0.025x the base price, keeping the fixed system prompt as small as possible also reduces cost.

How do you delegate work to subagents?

Per the official sub-agents documentation, the model resolves in four steps: the model parameter in the call, the definition's model frontmatter, the CLAUDE_CODE_SUBAGENT_MODEL variable, and finally the main conversation's model. There's no cap at the last step; the "capped at Opus on the Claude API" note only applies to the built-in Explore. That's why explicitly giving the model field on every delegation call is the only reliable way to guarantee which task runs on which model.

Is Opus 5 still available?

Yes. Opus 5 remains accessible and priced in the API (5 dollars input / 25 dollars output per MTok) even after Claude Code v2.1.280 made Opus 5.5 the default on September 22, 2026. It hasn't been retired, but it's no longer the default model behind the opus alias.

Conclusion

Multi-model orchestration means giving up the search for a single "best model" and splitting work by task type instead: exploration and mechanical work to the cheap model, specified code to the mid-priced model, risky and long-horizon verification to the most expensive model. I go deeper on this split in Claude Code Subagent Model Assignment and Orchestration Cost; for parallel delegation, see Claude Code Multi-Agent Teams.

Find the changes Fable 5.1 brought (including the cache price) in Claude Fable 5.1: Cache 75% Cheaper. For an older but still valid framework on when to prefer Opus, see When to Use Claude Opus 4.7; for cache economics fundamentals, see Claude Prompt Caching: Cut Cost 10x. To apply this setup to a real vibe coding project, The Guide to Moving a Vibe Coding MVP to Production is a good next step.

Sources

• Claude Code v2.1.257 release notes — Fable 5.1 becoming the default model, cache pricing, and CLAUDE_CODE_SUBAGENT_MODEL_FORCE.
• Claude Code v2.1.280 release notes — Opus 5.5 becoming the default Opus model and the opus alias change.
• Claude models overview — official positioning text, price/feature table, context window.
• Claude pricing — Fable 5.1 and Opus 5.5 cache-read multipliers, Opus 5's current price.
• Claude Code sub-agents documentation — model inheritance rule, cost-routing advice, Explore subagent behavior.
• Claude Code model-config documentation — alias table and the opus alias's resolution change to Opus 5.5.