Anthropic's Claude Model Selection Guide: The Core Advice Is to Hold Off on Switching Models

Anthropic's developer account published a Claude model selection guide, written by Addy Osmani. It opens with the conclusion: most work should start with Opus 5.5 at the default medium effort. There's a reason Claude Code uses it by default: its input and output prices are half those of Fable 5.2.

But the part of this guide really worth reading is the discussion of effort levels and model pairing.

Four Models, Prices Differ by a Factor of Eight

The current Claude product line has four generally available models: Haiku 5.5, Sonnet 5.5, Opus 5.5, and Fable 5.2. Mythos 5.2 is a specialized model for cybersecurity and life sciences, available through a validated-project application process.

The price gap is large. At API list prices, per million tokens for input and output:

All four models have a 1M-token context window and a maximum output of 128K. Haiku 5.5 is the only one priced in tiers by prompt length; prompts over 100K tokens cost five times as much per unit. So its most cost-effective use case is short prompts with high-frequency calls.

FIG A shows the same alley photo rendered by four models, each writing Python code to call a drawing engine. From the first layer to the finished result, the differences in detail are visible to the naked eye. But Addy doesn't judge which is better in the article; he simply leaves them there.

Effort Levels Are More Granular Than Switching Models

One point the guide repeatedly emphasizes: before switching models, try adjusting effort first.

Effort is a finer-grained knob than model choice, and it affects both cost and capability. Above high, going up another level can cost as much as switching to a larger model. Conversely, going down a level may still deliver the result you need at a lower price.

Here are some concrete numbers: on SWE-bench Pro, Opus 5.5 at medium scores about 2.5 points lower than at high, but costs only about 70% as much. low scores about 8 points lower than high and costs about one-third as much. xhigh scores about 1.4 points higher than high but costs 2.5 times as much.

So the rough approach is: first make sure the model can verify its own work, with tests, build scripts, or API calls; if not, raise effort by one level; if that still doesn't work, switch to a larger model, but start at a lower effort level.

If task results can be checked automatically, the official recommendation is to run everything at low effort and rerun only the failures at high effort. Numbers on a SWE-bench Pro subset: Opus 5.5 at low plus rerunning failed items has a pass rate of about 97% at $0.17 per task; all at high is 95.3% at $0.29 per task.

FIG B shows four models each building a portfolio website, displayed side by side; FIG C shows Fable 5.2 rendering a game-engine world in sixteen styles, from wireframe to ray tracing. These images in the article are more intuitive than looking at benchmark percentages alone.

An Easily Overlooked Cost Item: Cache and Context

Every conversation turn resends the context, but in long-running tasks most input is billed as cache reads. Opus 5.5 cache reads cost $0.20 per million tokens, Sonnet 5.5 is $0.10, and Fable 5.2 is $0.20, the same as Opus.

This suggests one thing: the larger the main model, the leaner the main context should be. Leave decisions to the expensive model, and let cheaper subagents read logs, search files, and write summaries.

Haiku 5.5 has a natural advantage here. With short prompts, its input price is one-twentieth that of Sonnet 5.5. But if every call carries a long prompt, you have to compare cost per completed task, not just list prices.

FIG D shows how four models divide work in one project: Fable 5.2 migrates an online store from JavaScript to TypeScript, Opus 5.5 builds monthly subscriptions, Sonnet 5.5 writes product pages, and Haiku 5.5 classifies customer messages.

Subagents Should Get Small Models, but There's a Catch

The guide recommends running subagents on Haiku 5.5 or Sonnet 5.5, doing only work where mistakes are easy to spot: finding files, running tests, reading logs. Leave code editing and judgment to the main model.

In Claude Code, you can write model: haiku in the subagent definition, or set the default with the CLAUDE_CODE_SUBAGENT_MODEL environment variable.

But there is a change worth noting. A commenter in the replies pointed out that in the current version of Claude Code, the built-in Explore subagent runs on the session model and is no longer hard-wired to Haiku. If you want to save money, you can define your own subagent named Explore and lock it to model: haiku.

FIG E is a map demo: Opus 5.5 does the planning, and multiple Haiku 5.5 subagents draw layers in parallel, including elevation, bike lanes, fog, and temperature. Temperature is illustrative, and fog is impressionistic rather than a forecast.

Check Compatibility Before Switching Models

Model selection isn't always just a matter of changing a name. The guide lists several points to test when migrating.

Fable 5.2 extends preserved thinking to all API accounts. If anything before a thinking block changes—including the system prompt, tools, or earlier messages—the API returns a 400 error unless you choose to discard the affected thinking.

Forced tool calls have also changed. Setting tool_choice to any or tool returns a 400 on Sonnet 5.5, Opus 5.5, and Fable 5.2. You have to change it to auto, mark tools as strict: true, and make it clear in the prompt when to use them.

There is also the issue of thinking-block compatibility. Different models can read different thinking blocks. Opus 5.5 can read Sonnet and Haiku blocks, while Fable 5.2 can read Opus, Sonnet, and Haiku blocks. If you switch down a tier, previous reasoning blocks are lost.

If a system runs multiple models, the guide recommends constructing every request according to the strictest model: keep history append-only, use tool_choice set to auto with strict tools, and read content blocks by type. That way, switching models up or down doesn't require code changes.

Test on Your Own Tasks, Don't Just Look at Benchmarks

The guide ends with a measurement process: sample from real tasks, write a result check for each task, run each candidate model at two or three effort levels, run each in an independent session to avoid shared cache, record the cost per completed task, and plot score versus spend. A multi-model setup is worth keeping only if it beats every single-model point on that plot.

There's a quick way in Claude Code: use /model to run the same task with two models and compare the numbers from /usage.

A few comments are worth including here. One commenter said model capabilities keep changing, so it's hard to say whether this guide will hold up for a month. Another mentioned that the effort section is the one to read first, since many cost complaints come from running everyday tasks at Max effort. Someone else joked about using Fable 5.2 to change a button color.

The original guide is at claude.dev, by Addy Osmani. It also links to separate guides for Sonnet 5.5 and Opus 5.5, as well as documentation on effort and subagents.