Raise effort before switching Claude models, Anthropic says

Anthropic published a model-selection guide on the Claude developer blog on November 10. It starts most coding and knowledge work on Opus 5.5 at its default medium effort and tells developers to add a self-check or raise effort before reaching for a bigger model. If your outputs can be checked automatically, the cheapest route the guide describes is to run everything at low effort and re-run only the failures at high. On a SWE-bench Pro subset, Opus 5.5 run that way passed about 97% of tasks for about $0.17 each, against 95.3% for $0.29 with every task at high.

The guide covers the four generally available models: Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.2. Mythos 5.2, which Anthropic calls its most capable model for cybersecurity and life sciences research, is available only through its verification programs. Opus 5.5 is already the Claude Code default on Pro, Max, Ultra, Team, Enterprise and the Anthropic API.

Before you switch models

When a model falls short, the guide gives three steps in order. First, make sure the model can verify its own work, with a test, a build or a script that calls the endpoint. Then raise effort one level. Only after that, move to the next model up and start it at a lower effort than you used on the smaller one. Effort sets how long the model thinks, how many tools it calls and how much it checks itself. It adds latency, and it won’t give a model knowledge or skill it doesn’t have.

The returns thin out near the top. On SWE-bench Pro, Opus 5.5 at medium scored about 2.5 points below its high setting for about 70% of the cost, and at low about 8 points below for about a third of the cost. Going up to xhigh bought about 1.4 points for 2.5 times the cost of high. Past high, the guide warns, one more effort level can cost as much as a bigger model.

At that point Fable 5.2 is the alternative to test. On Anthropic’s FrontierCode 2.0 runs, Fable 5.2 at high scored 45.3% against 45.5% for Opus 5.5 at max, for roughly half the cost per task. So before raising Opus 5.5 past high on a hard task, the guide says to try Fable 5.2. A generation earlier the gap ran the other way: on Anthropic’s Terminal-Bench 3.0 runs, Fable 5.1 at max scored 58.0%, while Opus 5.5 at high scored 58.9% with half the tokens.

When you compare two models, price your hardest tasks as well as the typical ones. On one 20-problem search benchmark, two problems carried 43% of the spend.

Which model for which job

• Opus 5.5, $4 / $20 per million input and output tokens: everyday engineering and debugging, multi-PR feature work, computer use and vision-heavy workflows. Start at medium, then go to high.
• Sonnet 5.5, $2 / $10: well-scoped coding such as bug fixes and spec-driven features, chat, documents, slides and spreadsheets, and repeated agent tasks like review or drafting. A clear spec alone doesn’t qualify a task. A migration or a performance optimization can have one and still need Opus 5.5, or Fable 5.2 for a major one.
• Haiku 5.5, $0.10 / $0.50 for prompts up to 100K tokens and $0.50 / $2.50 above that: classification, routing, tagging and extraction at volume, plus subagents that search files, read logs or summarize.
• Fable 5.2, $8 / $40: major refactors and migrations, architecture planning, leading many subagents, deep research and quantitative analysis, long unattended runs, and cases where Opus 5.5 at high still falls short.

All four have a 1M-token context window and 128K tokens of maximum output. Default effort differs by model. On the API it is medium for Haiku 5.5 and Opus 5.5 and high for Sonnet 5.5 and Fable 5.2, which both drop to medium in Claude Code, where /effort shows the current setting.

Cache pricing changes the comparison on long runs, where most input bills as cache reads. Fable 5.2 charges the same $0.20 per million cached tokens as Opus 5.5, against $0.10 for Sonnet 5.5. On a cache-heavy run, the gap between Fable and Opus therefore comes down to uncached input and output, where Fable costs twice as much per token. Haiku 5.5 is the one model whose price depends on prompt length. On short prompts its input costs a twentieth of Sonnet 5.5’s, and its long-prompt tier still costs a quarter of Sonnet’s per-token price. If every call needs a long prompt, the guide says to compare the two on cost per finished task.

For replies a person waits on, the guide starts with Sonnet 5.5 at low or medium effort. Opus 5.5 and Fable 5.2 also offer a fast mode on the Claude API, with higher output speed at premium pricing.

Subagents and the haiku alias

A subagent bills at the rates of the model it runs on. In Claude Code you set that model with model: haiku or model: sonnet in the subagent’s definition, and CLAUDE_CODE_SUBAGENT_MODEL sets the default for subagents that don’t name one. The guide keeps small models on work where a mistake is cheap to spot, such as finding files, running tests and reading logs. Code edits and judgment calls stay on the main model.

Two details change the costs here. The built-in Explore subagent now runs on your session’s model rather than always on Haiku, and on the Claude API that model is capped at Opus. To keep exploration cheap, define your own subagent named Explore with model: haiku. The haiku alias itself now resolves to Haiku 5.5 on the Anthropic API, which needs Claude Code v2.1.293 or later. On Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS it still resolves to Haiku 4.5. ANTHROPIC_DEFAULT_HAIKU_MODEL pins it.

The opusplan alias does the reverse of the guide’s advice. It plans with Opus and carries out the plan with Sonnet, which puts your code edits on Sonnet, so the guide suggests measuring it on your own tasks before making it the default.

For work bigger than one context window, the guide cites an internal defect-search benchmark over about 22 million tokens of source code. There, an Opus 5.5 lead running up to 25 Sonnet 5.5 workers at a time cost about a third less than Opus 5.5 alone at default effort and scored about the same. The guide says to skip this pattern for a chain of dependent steps or work that fits in one context window. The advisor tool, in beta, pairs a cheaper executor with a stronger advisor and shows thinner gains. An Opus 5.5 executor at high with a Fable 5.1 advisor scored 90.1% at $2.92 per attempt. That is 1.7 points over Opus 5.5 alone at high for about 2.1 times the money, and the guide places it at the edge of run-to-run noise.

What breaks when you switch

• The prompt cache belongs to the model that wrote it, so the first turn on a new model pays the cache-write price on the whole conversation. Run /compact first in Claude Code, or open the new model’s conversation on the API with a summary of the work so far.
• A model never reads thinking blocks from a model above it. The API drops unreadable blocks and the request still succeeds, so a move from Fable 5.2 to any other generally available model loses its reasoning without warning.
• Fable 5.2 extends preserved thinking to every API account. A request returns a 400 error if anything before a Fable 5.2 thinking block has changed, including the system prompt, the tools or an earlier message, unless you opt in to dropping the affected thinking. Claude Code, the Claude Agent SDK and Claude Managed Agents need no changes. Code that edits history should be append-only.
• Opus 5.5 and Fable 5.2 always think, and a request that turns thinking off returns an error. On every model, read content blocks by type, because a response can begin with a thinking block.
• A tool_choice of any or tool returns a 400 error on Sonnet 5.5, Opus 5.5 and Fable 5.2. Send auto, mark the tool strict: true and say in the prompt when to use it.
• Moving from Haiku 4.5 to Haiku 5.5 means replacing budget_tokens with an effort level. Non-default temperature, top_p and top_k values return a 400 error, and so does a final assistant turn left for the model to continue.
• In Claude Code, a request that the safety classifiers flag can re-run on an older model, and a notice in the transcript names it. Flagged cybersecurity requests go to Opus 4.8 and flagged biology requests to Opus 5.

Before committing to a setup, the guide recommends testing on your own work. Take a sample of real tasks, write an outcome check for each, and run every candidate at two or three effort levels in separate sessions. Then plot score against spend. A multi-model setup stays only if it beats every single-model point on that chart. For a quick version in Claude Code, run one task from your backlog on two models with /model and compare what /usage reports.