Claude’s 5.5 family breaks the simple model ladder: Sonnet can beat Opus without replacing it

A model family is easy to misunderstand when the product names suggest a staircase. Anthropic’s own Sonnet 5.5 release reports a higher Terminal-Bench 4.0 score for Sonnet than for Opus 5.5, while still recommending Opus for the most demanding open-ended work. Those statements are compatible. The benchmark and the recommendation describe different things.[1]

The 7 October arrival of Haiku 5.5 makes that distinction more useful. There is now a fresh low-cost member alongside the September Sonnet and Opus releases. This article examines the current family as of 8 October, rather than treating one model’s launch table as a permanent league table.[3][2]

Three prices do not establish three levels of usefulness

The Sonnet cached-input figure deserves attention because it changed after launch. Anthropic’s Haiku announcement halves that charge from $0.20 to $0.10 per million tokens. A comparison copied from Sonnet’s September launch without checking the subsequent announcement would overstate that part of the current bill. Haiku itself moves to higher rates beyond its 100K-input band.[3]

For a buyer, this creates two separate research tasks. One is to establish current terms. The other is to measure the work produced under them. Neither can substitute for the other. A discounted cache cannot make the wrong answer correct, but an outdated cache price can make a good candidate appear unnecessarily expensive.

Why Sonnet can win a test and Opus can remain the better choice

In Anthropic’s Sonnet announcement, Terminal-Bench 4.0 is reported at 70.6% for Sonnet and 66.4% for Opus, whose result is explicitly labelled Xhigh effort. The FrontierCode 1.1 Main table gives Sonnet 46.2% at Max and 52.1% at Xhigh, versus 54.4% for Opus. Anthropic says Sonnet’s extra review work at Max sometimes led to a timeout or out-of-scope edits. These results show why both the task and the effort setting belong beside a score; more reasoning was not uniformly better in this evaluation.[1]

A terminal-oriented evaluation can reward efficient execution in a bounded environment. A harder coding task may place different demands on architecture, exploration or revision. Even before considering sampling variability, changing the distribution of tasks can change which model is preferable. The useful question is which evaluation resembles the expensive failures in your own work.

Anthropic’s Opus release describes a model intended for demanding coding and professional workflows. It also distinguishes standard service from a higher-priced fast mode. A developer comparing two screenshots without recording processing mode could accidentally compare a model-quality difference with an infrastructure-speed difference.[2]

Our proposed comparison would include three deliberately different jobs: repair a small regression with a known failing test, reconcile conflicting product requirements, and design a change touching several components. The first rewards precise execution. The second requires interpretation. The third requires keeping decisions consistent over a longer task. One average score would conceal which problem is driving the result.

Keep the acceptance criteria fixed before seeing the responses. For the regression, the original failure must disappear without breaking adjacent behaviour. For the requirements review, the model must identify the contradiction rather than silently choose a side. For the architectural change, reviewers should be able to trace each altered component to a requirement.

Effort is part of the model configuration

The model documentation separates available reasoning controls and model identifiers. Product defaults should not be assumed identical across an API, a chat application and a coding client. A fair comparison records the actual request settings and the service used, rather than merely copying the name displayed above a conversation.[5]

This matters particularly when a team changes providers through a compatibility layer. A label such as high may be passed through, mapped to another level, ignored or rejected. Our practical recommendation is to log the setting that was actually accepted and retain the response’s usage information. Otherwise a perceived model regression can be an integration regression.

Fable and Mythos are not extra rungs on the same staircase

Anthropic’s separate Fable and Mythos 5.1 release describes models sharing a base but deployed with different safeguards and access conditions. Fable is the broadly available member; Mythos is provided through controlled access. The release lists Fable at $10 per million input tokens and $50 per million output tokens. Access policy belongs alongside capability in any family map.[4]

That does not mean a restricted model is the default answer to every difficult task. A consumer writing a report, a software team fixing its own application and an authorised security organisation do not have identical requirements. A technically stronger result on one narrow class of work does not resolve deployment eligibility, service terms or practical suitability.

The constructive reading of the 5.5 family is a portfolio, not a podium. Use the cheapest member that demonstrably meets a job’s quality threshold, but keep examples of failures that justify moving up. Re-evaluate those examples after a release rather than assuming that yesterday’s division of labour remains optimal. Most importantly, allow a cheaper model to win without claiming it has made every more capable system obsolete.

Report an error or suggest a correction