Claude Opus 5.5 vs Sonnet 5.5 for Coding

The short answer

Run Sonnet 5.5 as the default coding model and move up to Opus 5.5 when a task is long, ambiguous or expensive to get wrong. Sonnet 5.5 costs $2 per million input tokens and $10 per million output tokens; Opus 5.5 costs $4 and $20. On the coding benchmarks Anthropic published, Sonnet 5.5 lands within roughly two points of Opus 5.5 on CursorBench and ahead of it on one Terminal-Bench 4.0 row, but it trails by about eight points on FrontierCode when Sonnet runs at Max effort. Anthropic itself says Opus 5.5 “remains clearly stronger at complex, open-ended work requiring sustained judgment.”

The effort setting matters as much as the model. Both models accept five levels, low, medium, high, xhigh and max, and both vendors’ charts show cost per task rising steeply as you climb. A low-effort Sonnet 5.5 run and a max-effort Opus 5.5 run can differ by an order of magnitude in spend for the same prompt, so treating the model name as the only decision leaves most of the savings on the table. Opus 5.5 defaults to medium and Sonnet 5.5 defaults to high on the API, which means a request that sets no effort at all already puts the two models at different points on their own curves.

This article is built from Anthropic’s product pages, its API documentation and one independent source, the Artificial Analysis Intelligence Index v5. Every Anthropic benchmark below is vendor-reported. Where an independent number exists, it is labeled as such. Cost figures are arithmetic on the published price list, not measurements of any particular codebase, and the only thing in this guide that comes from running real workloads is the test plan at the end, which you would run yourself. If you want the earlier generation for context, the Sonnet 5 vs Opus 4.8 comparison covers how the previous pair split the work, and the Claude Fable 5.1 guide covers the tier above Opus.

What Anthropic posted

Anthropic announced Opus 5.5 on September 22, 2026 and Sonnet 5.5 six days later, on September 28. Both launch threads came from the @claudeai account, and between them they contain most of the framing used in the rest of this guide. The Opus lead post positions the model against the tier above it rather than against Sonnet.

Two details in that first post shape everything that follows. The comparison is to Fable 5.1 and Opus 5, not to Sonnet, and the 40 percent figure is a cost-to-run claim against the previous Opus. The follow-up post explains where the saving comes from: a lower serving cost passed on in the price list, plus fewer tokens per task. Anthropic describes the 40 percent as the result of its own tests at default settings on “typical workloads,” which is a vendor statement about a workload mix you cannot inspect.

The third Opus post is the one that matters for effort. It says that at its default effort setting Opus 5.5 delivers frontier results for a fraction of the cost per task, often beating other models running at their highest settings. It attaches four charts, one each for FrontierCode, AutomationBench, GDPval-AA and Terminal-Bench 4.0, each plotting score or pass rate against cost per task (cost per attempt on the Terminal-Bench chart) with the Opus 5.5 effort levels labeled. Those charts are reproduced below.

The Sonnet launch post makes a different pitch: a clear upgrade over Sonnet 5, more than 30 percent faster, and up to 30 percent cheaper for most work. It frames Sonnet 5.5 as the second model in the family rather than a Sonnet-versus-Opus decision.

One later post changes the price math. On October 7, Anthropic said it was halving the price of cache reads on Sonnet 5.5 to $0.10 per million tokens, which it described as making Sonnet 5.5 around 20 percent cheaper to run on most long-running work. The current pricing page and product page both show $0.10, so any cost table written from launch-week coverage may carry the older cache-read rate. The formulas later in this guide use the current figure.

Anthropic also published a launch video for each model on its Opus 5.5 and Sonnet 5.5 pages on the official Claude YouTube channel. Both are short product introductions; this guide takes its numbers from the written pages and docs, which carry the footnotes the videos omit.

The two models side by side

On paper the models are siblings. They share a 1M-token context window, a 128K maximum output, a June 2026 knowledge cutoff and adaptive thinking. The differences are in price, speed positioning, default effort and what the thinking system allows. Anthropic’s own model comparison table labels Opus 5.5 as moderate latency and Sonnet 5.5 as fast.

Two lines in that table deserve a closer look. First, every price in the Sonnet column is exactly half of the Opus column: input, output, cache read and cache write. That makes cost comparison unusually clean, because the ratio does not depend on the shape of your workload. If Sonnet 5.5 spends the same number of tokens as Opus 5.5 on a task, it costs half as much. If it spends twice as many, the bill is identical. Second, the default efforts differ in the opposite direction from what the price would suggest: the cheaper model defaults to the higher effort. A team that swaps the model ID and nothing else is therefore changing two variables at once.

Opus 5.5 also supports a fast mode that Anthropic says delivers up to 2.5 times the speed at $8 per million input tokens and $40 per million output tokens, double the standard Opus rate. The pricing page says fast mode is not available with the Batch API, and prompt caching multipliers apply on top of the fast-mode price. For latency-bound interactive work this is the only way to buy speed on Opus; Sonnet 5.5 is the cheaper route to a fast response, since Anthropic reports it generates output more than 30 percent faster than Sonnet 5.

Effort levels, exactly

Claude’s effort control is a request parameter, output_config.effort, and the documentation lists five values: low, medium, high, xhigh and max. Both Opus 5.5 and Sonnet 5.5 support all five. The docs describe effort as a behavioral signal rather than a strict token budget, and they say it affects every output token, including explanatory text, tool calls and function arguments, and thinking when it is active. Lower effort therefore also means fewer and terser tool calls, which matters for coding agents because tool calls are where a long session spends most of its time.

The phrase “opus 5 high” shows up in search because of a default that changed. On Opus 5 and earlier Opus models the default was high. On Opus 5.5 it is medium, and the docs state this directly: a request that omits effort now runs one level lower than it did on Opus 5. Setting effort to the model’s default produces exactly the same behavior as omitting it. If you carried an Opus 5 integration forward without setting effort, you are already running cheaper and, by Anthropic’s reporting, still near the top of its own benchmark curves, but your quality floor moved. Anthropic’s advice for both new models is to run a fresh effort sweep on your own evals rather than reusing a setting from an earlier model.

For Sonnet 5.5 the docs add specifics. The levels are recalibrated, so a level does not produce the same amount of thinking as it did on Sonnet 5. Anthropic’s guidance is to start with high unless the workload is agentic or latency-sensitive; for agentic coding and multistep tool use, start with medium for well-specified tasks and move to high for harder or longer ones; use xhigh or max only where your evals show a quality gain. For agentic coding it recommends setting max_tokens to 128,000, the model maximum, and streaming the response, because thinking counts toward max_tokens even when the thinking text is not returned. For Opus 5.5 the docs say to set a large max_tokens at higher levels for the same reason: it is a hard limit on thinking plus response text.

Both models also support per-message effort, which lets an agent loop change effort between turns while preserving the prompt cache. Per-message effort is listed as a beta feature. Sonnet 5.5 has one limit here: if you turned up-front thinking off with the between_tools setting, you cannot change effort mid-conversation, and a per-message effort that differs from the level in effect returns a 400 error. Opus 5.5 has no such mode because its thinking is always on.

Benchmarks, labeled

Anthropic published a benchmark table for each model. The Sonnet table includes Opus 5.5 as a column, so the head-to-head numbers below come from Anthropic’s Sonnet 5.5 page and the Opus 5.5 page. Every number here is vendor-reported, run by Anthropic or by the partner named in the footnote. The caveats attached to individual rows are not decoration; several of them change which model looks better.

The headline reading is straightforward. On five of the eight rows the gap between the models is under three points or under ten Elo, and on Terminal-Bench 4.0 the Sonnet number is higher. The row that separates them is FrontierCode, the benchmark built around whether a maintainer would merge the change. Anthropic’s Sonnet page reports 46.2 percent at Max effort and 52.1 percent at Xhigh against 54.4 percent for Opus 5.5, and the text of the Opus page adds that Opus 5.5 at default medium effort scores 54.6 percent. Those two Opus numbers are not the same configuration and Anthropic does not reconcile them in the text, so treat 54.4 and 54.6 as the same ballpark rather than a contradiction to resolve.

The footnote on the Sonnet FrontierCode row is the most useful single paragraph in either announcement for anyone running coding agents. Anthropic says Sonnet 5.5 scored lower at Max effort than at Xhigh because, at Max, it more often ran Claude Code’s code-review skill, which splits a review across many subagents. In two cases Cognition examined, that led to a timeout or to extra edits beyond the task’s scope, and FrontierCode penalizes out-of-scope changes even when they are helpful. The lesson is not that Max is bad. It is that more effort buys more activity, and activity is not the same as a smaller, mergeable diff.

The Terminal-Bench 4.0 row needs care in the other direction. A 70.6 versus 66.4 comparison looks like a Sonnet win, but the standard error Anthropic gives for Opus 5.5 is ±2.6 points, which covers most of the 4.2-point gap, the table does not state the effort level Sonnet ran at, and the Opus figure is explicitly its highest score at xhigh rather than a like-for-like setting. Sonnet 5.5 scoring at least level with Opus on terminal tasks is a fair reading. Sonnet 5.5 beating Opus 5.5 at terminal coding is not established by this table.

Anthropic’s cost-efficiency claims are where each model’s curve matters. For Opus 5.5 it says that at default effort on Terminal-Bench 4.0 it beats Opus 5 at max effort for about a fifth of the cost, and that on FrontierCode at default medium it beats GPT-6 Astra’s top score for about a fifth of the cost per task. For Sonnet 5.5 it says that on several benchmarks Sonnet at Low or Medium effort beats Sonnet 5’s best score for about a tenth of the cost per task, and that at High effort on FrontierCode it matches GPT-6 Sol’s best for about a fifth of the cost per task. It also says Sonnet 5.5 “complements Opus 5.5 best when running at lower effort settings, where it costs less per task,” and that at higher settings it can perform comparably at a similar cost. That last clause is the important one: Anthropic is telling you that at high effort the per-task cost gap between the two models narrows, because Sonnet spends more tokens.

Independent evidence

The independent source is Artificial Analysis, which published Intelligence Index v5 on October 27, 2026. Version 5 weights nine evaluations in four equal groups: Knowledge Work, Coding, Science and General, each 25 percent. The coding group is FrontierCode 2.0 at 15 percent and Terminal-Bench 4.0 at 10 percent. AA says 60 percent of the index now rests on private or held-out test sets, which reduces the chance that a vendor tuned to the questions.

Three results from that article bear on this comparison. Claude Opus 5.5 at max effort leads the whole index at 58, ahead of GPT-6 Astra at 57 and GPT-6.1 Sol at 55. On FrontierCode 2.0, a 132-task private benchmark from Cognition graded on whether a maintainer would merge the change, Opus 5.5 at max leads with 46 percent, and Claude Sonnet 5.5 at max sits at 42 percent alongside GPT-6 Astra and GPT-6.1 Terra. And on AA-Briefcase, Sonnet 5.5 leads all measured models with 1812 Elo. So the independent coding benchmark reproduces the direction of Anthropic’s own FrontierCode result: Opus ahead, Sonnet a few points behind at maximum effort. The independent knowledge-work benchmark reproduces the other direction: Sonnet at or above Opus.

Two cautions apply. AA reports the max-effort setting for these models, which is the expensive end of each curve, so these scores say nothing about the medium and low settings where Sonnet’s cost advantage is largest. AA also notes that cost per task varies by more than 13 times among the leading models, from $0.96 for the cheapest to $13.04 for Claude Fable 5.1 at max; that range is a reminder that effort and model choice both move cost more than any single price per token. I did not find an Artificial Analysis cost-per-task figure for Sonnet 5.5 or Opus 5.5 in the article text, so this guide does not quote one.

Opus 5 vs Sonnet 5: the gap that closed

Readers searching for the previous pair, Opus 5 vs Sonnet 5, usually want to know whether the 5.5 generation changed the relationship. It did, and the clearest evidence is on Anthropic’s own tables. Using the Sonnet 5 and Opus 5 columns that appear on the two announcement pages, Sonnet 5 scored 10.3 percent on Terminal-Bench 4.0 where Opus 5 scored 52.3 percent. On FrontierCode, Sonnet 5 scored 42.4 percent against 48.0 percent for Opus 5. On CursorBench, 34.1 percent against 46.6 percent. Those are cross-page comparisons of the same named benchmarks, not a single head-to-head run, but they describe a Sonnet that was far behind on agentic work.

Sonnet 5.5 closed most of that. Anthropic reports Sonnet 5.5 at 70.6 percent on Terminal-Bench 4.0 against Sonnet 5’s 10.3 percent, and 55.5 percent on CursorBench against 34.1 percent. It says that at High effort on FrontierCode Sonnet 5.5 scores 10 points above Sonnet 5 at the same setting for about one fifteenth of the cost per task. The price list did not move for Sonnet, still $2 and $10 apart from the cache-read halving, so the gain came from capability and token efficiency rather than from a discount. Opus 5 sat at $5 and $25 with $0.50 cache reads, and Opus 5.5 reduced those to $4, $20 and $0.20. If your mental model of Sonnet is the Sonnet 5 era, where Opus was the only serious choice for agentic coding, that model is out of date.

Cost per task, with formulas

A coding task is billed on four quantities: fresh input tokens, cache reads, cache writes and output tokens. Output includes thinking and tool-call arguments, which is why effort changes the bill. The general formula, with prices in dollars per million tokens, is:

cost = (U x p_in + R x p_cache_read + W x p_cache_write + O x p_out) / 1,000,000

Here U is uncached input tokens, R is cache-read tokens, W is cache-write tokens and O is output tokens. The prices are $4, $0.20, $5 and $20 for Opus 5.5 and $2, $0.10, $2.50 and $10 for Sonnet 5.5, all from the pricing page. The workload shapes below are illustrative; they are not measurements.

Work the middle row by hand to check it. For Opus 5.5: 150,000 x $4 = $0.60; 1,200,000 x $0.20 = $0.24; 100,000 x $5 = $0.50; 40,000 x $20 = $0.80. The sum is $2.14. Every Sonnet term is exactly half, so the total is $1.07. Because the ratio is a constant two, the only question that matters is the token multiplier. If Sonnet 5.5 needs 1.5 times the tokens to reach the same result, the task costs $1.61 against Opus’s $2.14, still a 25 percent saving. If it needs twice the tokens, both cost $2.14, and the cheaper model has no cost advantage. Break-even is a token multiplier of 2.0.

This is why the advice to use Sonnet at low and medium effort holds. Anthropic’s charts show that cost per task rises with effort on both models, and Sonnet at Low can land at roughly a tenth of Sonnet 5’s best-case cost. At xhigh or max, a model that thinks for much longer can erase the two-to-one price ratio, and Anthropic says as much in its own text. If your harness cannot measure tokens per accepted change, you cannot know which side of the break-even you sit on.

Two other levers are worth computing. The Batch API takes 50 percent off both input and output, and Anthropic says the discount stacks with caching. Opus 5.5 on the medium feature through the Batch API therefore costs $2.14 x 0.5 = $1.07, the same as Sonnet 5.5 at standard rates. For work that does not need an interactive answer, such as overnight test generation or migration sweeps, that makes Opus a candidate where the sticker price suggests it is not. And the 1M context window is billed at standard rates with no long-context surcharge for Opus 5.5 and Sonnet 5.5, so a 900,000-token request costs the same per token as a 9,000-token one. Large-repository work does not trigger a price jump on either model.

One cost the formula does not capture is retries. A model that gets 90 percent of tasks right on the first pass at $1.07 is cheaper per accepted change than one that gets 70 percent right at $0.80 once you count the review time and rerun for the failures. Anthropic’s partner quotes lean on this idea: Lovable reports finishing builds in a third to half fewer steps with Opus 5.5, and an AI-app-builder partner quoted on the Sonnet page reports Sonnet 5.5 needing 3.6 iterations per build where Opus 5 needed 7.7. Those are partner claims about their own harnesses, so use them as hypotheses to test, not as constants.

Job to model and effort

The table below converts the evidence into starting points. These are recommendations to test, not guarantees. The effort suggestions follow Anthropic’s documented guidance where it exists and are marked as my inference where the docs are silent.

Two rows are inference rather than documentation. The pairing of Opus with ambiguous design work extrapolates from Anthropic’s sentence about sustained judgment. The Batch API row is arithmetic, not a recommendation from Anthropic, and it holds only if your workload tolerates asynchronous latency.

Claim and evidence table

Migration and breaking changes

Searches for “sonnet 5.5 breaking changes” reflect a real problem: the model accepts the same ID pattern as its predecessor but rejects several request shapes that Sonnet 5 allowed. Anthropic’s what’s-new page lists five breaking changes for code already running on Sonnet 5, plus one change that alters the response without failing a request. The model ID changes from claude-sonnet-5 to claude-sonnet-5-5, and the tokenizer is the same as Sonnet 5’s, so token counts for identical text do not change.

The thinking-block rule has a direct consequence for people who mix models. Anthropic’s docs say Sonnet 5.5 reads thinking blocks from Sonnet 5, Opus 4.8, Haiku 4.5 and earlier, but not from Opus 5, Opus 5.5 or any Fable or Mythos model, while Opus 5.5 does read Sonnet 5.5 blocks on the Claude API. So a conversation that starts on Sonnet 5.5 and escalates to Opus 5.5 keeps its reasoning, and one that goes the other way runs the later turns without it. The dropped blocks are not billed and the request still succeeds, but the second model starts without the first model’s reasoning trail. Escalating upward is the cheaper handoff.

If you are moving from Opus 5 to Opus 5.5 rather than from Sonnet 5, the docs list four breaking changes: thinking can no longer be disabled, forced tool use returns an error, thinking blocks are tied to the model and conversation, and the older computer-use tool is rejected on the Claude API. The practical Opus 5.5 change is the first one. If your harness disabled thinking at high effort or below on Opus 5 to save cost, the replacement is lowering effort, not turning thinking off. A harness that selects response content blocks by position rather than by type will also break, because every Opus 5.5 response can begin with an empty thinking block at the default display setting.

A migration checklist follows from this. Grep for the thinking-type literal, for any tool_choice that forces a tool, for the old computer-use tool type, and for code that reads the first content block by index. Update the model ID, set effort explicitly instead of relying on a default that differs between the models, and run your own effort sweep. Anthropic’s Claude Code ships migration helpers, including a migrate skill for moving API code to a newer model, though the docs I read list it only by name and I did not test it.

Claude Code defaults

In Claude Code, model choice is a short alias. The Claude Code docs say sonnet selects the latest Sonnet for daily coding tasks and opus selects the latest Opus for complex reasoning, and on the Anthropic API those aliases resolve to Sonnet 5.5 and Opus 5.5. There is also an opusplan mode that uses Opus during plan mode and then switches to Sonnet for execution, which is the simplest built-in way to apply the split this guide recommends: judgment up front, volume afterward. Sonnet 5.5 requires Claude Code version 2.1.284 or later and Opus 5.5 requires 2.1.280 or later, so an older install fails the request.

On defaults, Anthropic’s Sonnet page states that in Claude Code and its apps the default effort is Medium, while the Claude Platform defaults to High. That is a vendor statement on the product page and it differs from the API docs’ wording for Sonnet 5, which said high on the API and in Claude Code. The Sonnet 5.5 effort docs say high is the default on the Claude API and do not state a separate Claude Code default, so the two pages are not strictly contradictory: one covers the API, the other the product. Treat the exact Claude Code default as something to confirm in your own session with the /effort command rather than assuming it from either page. The Claude Code model configuration docs also state that subagent frontmatter can set both a model and an effort (the skills docs now list optional model and effort fields for SKILL.md as well), and that the effort field overrides the session level but not the CLAUDE_CODE_EFFORT_LEVEL environment variable. For deeper workflow detail, see the Claude Code best-practice guide, and for tool comparisons beyond Claude, the best AI coding agents of 2026 list.

A test plan before you switch

Anthropic’s own docs tell you to run an effort sweep on your evals. Here is a version small enough to run in an afternoon. Pick 20 closed tickets from your repository with known good diffs, ten easy and ten hard. Run each on Sonnet 5.5 at low, medium and high, and on Opus 5.5 at low, medium and high, six configurations in all. Record four numbers per run: whether the result passed your tests, whether a reviewer would merge it without edits, total tokens by category, and wall-clock time. Then compute cost per accepted change with the formula above, not cost per attempt.

Add xhigh only for the ten hard tickets and only on the model that scored better at high. Add max only if xhigh showed a gain, since the Sonnet FrontierCode footnote is a warning about paying for more activity than the task needed. Set max_tokens generously and stream, as the docs advise, or runs will truncate and look like quality failures. Check out each ticket on a clean branch so a model cannot see its earlier attempt. If Sonnet at medium passes your merge test on the easy tickets at the same rate as Opus, route those to Sonnet. If Opus clears the hard tickets at a rate where its higher per-attempt cost is lower than Sonnet’s cost including reruns, route those to Opus. The split that falls out of your data is the one to trust over any published chart, including the ones in this guide.

Limitations

• Every Anthropic benchmark here is vendor-reported. Several partner benchmarks, including AutomationBench and CursorBench, were run by the partner, and Anthropic discloses that safeguards can lower Opus 5.5’s scores on some tasks.
• The two models’ scores in Anthropic’s tables are not always at the same effort level, and the Terminal-Bench 4.0 row does not state Sonnet’s effort. Differences of a few points sit inside the stated standard errors.
• Artificial Analysis scores for Sonnet 5.5 on GDPval-AA and AA-Briefcase came from a pre-release deployment with a structured-output bug that Anthropic says has been fixed and expects to understate performance.
• Cost-per-task tables in this guide are arithmetic on illustrative token mixes. Real task token counts vary widely by harness, repository and effort.
• The Claude Code default effort for Sonnet 5.5 is stated differently on two Anthropic pages. I did not test it.
• Anthropic’s 40 percent and 30 percent cost claims come from its own “typical workload” tests and cannot be reproduced from the published material.
• The effort-by-model charts are reproduced as images from Anthropic’s posts. I read axes and labels from them but do not quote exact points off the curves.

Verdict

If you want one rule, it is this: start every coding workload on Sonnet 5.5 at medium effort, measure cost per accepted change, and escalate the specific workloads that fail to Opus 5.5 at medium or high. The reasons are on the page. Sonnet 5.5 costs half as much per token on every line, ties Opus within about two points on CursorBench, scores at or above Opus on the Terminal-Bench row, and carries the same context window. Opus 5.5 earns its premium on long-horizon, ambiguous and migration-scale work, where Anthropic and an independent benchmark both place it ahead on FrontierCode, and where Anthropic reports it using fewer tokens than the previous Opus to get there.

Treat max effort as a special case on both models, not a default. Treat the sticker price as half the story, since a two-to-one price ratio disappears the moment the cheaper model needs twice as many tokens. And before you upgrade anything, check the five Sonnet 5.5 breaking changes against your integration, because the failures are 400 errors and a silent loss of streamed progress text, not gradual degradation. The model you pick will matter less than whether you measured.

FAQ

Sources

Sources checked October 28, 2026.

• Introducing Claude Opus 5.5 — Anthropic (benchmarks, pricing, effort charts, partner quotes)
• Introducing Claude Sonnet 5.5 — Anthropic (benchmark table with Opus column, footnotes, pricing, effort defaults)
• Claude API pricing (all price lines, batch, fast mode, long context)
• Claude Opus 5.5 model overview (context, output limit, default effort, availability)
• What’s new in Claude Opus 5.5 and What’s new in Claude Sonnet 5.5 (breaking changes, migration)
• Effort parameter docs (five levels, per-model guidance)
• Claude Code model configuration (aliases, opusplan, minimum versions)
• Artificial Analysis Intelligence Index v5 (independent index, FrontierCode 2.0, AA-Briefcase)
• X posts from @claudeai: Opus 5.5 launch, pricing, effort charts, Sonnet 5.5 launch, cache-read price cut
• Official Claude YouTube launch videos: Introducing Claude Opus 5.5 and Introducing Claude Sonnet 5.5

Related reading: Claude Sonnet 5 vs Opus 4.8, Claude Fable 5.1 complete guide, best AI coding agents of 2026, Claude Code best-practice guide, and GPT-6.1 Sol guide.