A set of data from an Anthropic guide offers a clear conclusion: on tasks whose results can be judged automatically, Opus 5.5 at the low effort tier achieved a pass rate of about 97% when failed tasks were rerun at the high tier, at a cost of about $0.17 per task. That compares favorably with running every task at high effort, which produced a 95.3% pass rate at a cost of $0.29.
What this is
Anthropic’s “Which Claude model should you build with?” covers Haiku 5.5, Sonnet 5.5, Opus 5.5, and Fable 5.2, while comparing different effort tiers. Effort is the working tier in which a model spends more reasoning resources: the higher the tier, the slower and more expensive the run generally becomes.
The key is not simply to “reduce model configuration,” but to establish a tiered processing chain: let a cheaper tier complete verifiable tasks, then hand only the small number of failed tasks to a higher tier. This works when results can be judged automatically—for example, through passing tests, successful builds, or script validation. If every task requires manual review, the model costs saved may be offset by the time spent on verification.
The guide also stresses that increasing effort does not add knowledge or capabilities the model itself lacks. When a task hits the model’s capability ceiling, the sequence should be to add automated checks first, raise the effort tier second, and consider switching to a larger model last, starting tests from a lower tier.
Industry view
We believe this guide is more valuable than another “which model is strongest” comparison because it turns model selection from a fixed price-list decision into a task-scheduling problem. Although Fable 5.2’s unit price is roughly twice that of Opus 5.5, the two scored similarly on FrontierCode 2.0’s hardest problems, while Fable 5.2’s cost per task was about half as much. A higher price does not necessarily mean higher total spending: unit price matters, but so do the tokens consumed to complete a task.
That said, these findings should not be packaged as a universal cost-reduction formula. The 97% figure comes from specific benchmarks such as SWE-bench Pro and particular models, effort tiers, and configurations. Real-world operations also involve long-context inputs, tool calls, data quality, failed retries, and other variables. Some comparisons in the guide rely on a single test run without an error range, so a 0.2-point difference is not enough to establish that one model is stronger.
Dynamic routing also depends on reliable acceptance checks. If the tests are incomplete, a model may “pass” in the wrong way; if incorrect tasks reach the expensive tier, costs can still get out of control. Companies need to monitor pass rates, retry rates, acceptance accuracy, and the share of total cost attributable to the hardest tasks—not just the unit price of each call.
Impact on regular people
For enterprise IT: when procuring models, teams can encode the relationship among task difficulty, acceptance method, and model tier in their routing rules. This can reduce the cost of sending every request to the highest configuration while preserving quality on complex tasks.
For individual professionals: when using tools such as Claude Code, the default medium setting is usually the best balance. Raising effort for the small number of difficult problems often saves both time and money compared with running the highest tier throughout.
For the consumer market: if companies can cut inference costs by roughly 40%, more products are likely to expand free allowances, shorten wait times, or turn complex features that were once too expensive into standard offerings.