Claude Sonnet 5.5 or Opus 5.5? A guide for everyday work

Short answer: try Claude Sonnet 5.5 first for well-scoped coding, bug fixes, documents, slides, and spreadsheet work. Move to Opus 5.5 when the scope is unclear, the decision crosses systems, or sustained judgment matters more than iteration speed. Anthropic released Sonnet 5.5 on September 28, 2026 under the `claude-sonnet-5-5` model ID, with a one-million-token context window, a standard 128,000-token output limit, and list prices of $2 per million input tokens and $10 per million output tokens.[1][3]

This is not an independent model test. The speed, task-cost, benchmark, and safety figures come from Anthropic's announcement and technical documentation. I have not compared both models on the same task suite. The useful job here is to turn vendor claims into a routing rule you can measure, not to repeat them as buying advice.

The shortest decision

• Sonnet 5.5: a bounded feature, bug fix, tests, reversible refactor, document, spreadsheet analysis, or fast iteration.
• Opus 5.5: ambiguous root-cause work, architecture, cross-service changes, long audits, or open-ended work where a wrong decision is expensive.
• If unsure, start Sonnet 5.5 at `medium`; fix the task definition first if it fails, then try `high` or Opus 5.5.
• Judge the result by tests, diff quality, output quality, elapsed time, and repair turns rather than the model's explanation.

This split is not a quality guarantee. Anthropic says Sonnet 5.5 complements Opus best at lower effort settings, while their task costs can converge at higher settings.[1] The model name alone does not make the decision. Model tier and effort need to be routed together.

What changed with Sonnet 5.5?

Anthropic says Sonnet 5.5 generates output more than 30% faster than Sonnet 5 and costs up to 30% less per task for most work. Token prices did not fall: input is $2, output is $10, and cache reads are $0.20 per million tokens. The company attributes the lower task cost to completing the same work with fewer tokens and fewer tool steps.[1]

"Up to 30% less per task" is not a rate-card discount. It depends on Anthropic's tests and its definition of most work. Your result will change with longer prompts, slower tools, or more repair turns. Use the list price for budgeting, then test the efficiency claim on your own workload.

The model ID is `claude-sonnet-5-5`. Default effort is `high` on the Claude API and `medium` in Claude apps and Claude Code. Adaptive thinking is on. Integrations that need to turn off up-front thinking must replace the old `disabled` setting with `between_tools`.[1][2]

That default difference can spoil a comparison. A Sonnet `medium` run in Claude Code against an API run at `high` changes two variables at once. Hold the starting state, prompt, tools, effort, and acceptance check constant before calling one model better.

Why start everyday coding on Sonnet 5.5?

The attraction is the feedback loop, not a peak benchmark score. Faster output may shorten review on an endpoint, a patterned test, a reversible multi-file refactor, or a bug with a clear reproduction. When the wrong result is exposed quickly by a test, buying the more expensive reasoning tier at the start may add little.

Anthropic reports 70.6% for Sonnet 5.5 on Terminal-Bench 4.0, 46.2% on the FrontierCode 1.1 main set, and 55.5% on CursorBench 4.0. It says the CursorBench result is about two points behind Opus 5.5.[1] These are vendor-selected and vendor-published evaluations. They do not represent the dependencies, test quality, or local rules in a particular repository.

A more useful warning sits in Anthropic's FrontierCode footnote: Sonnet 5.5 scored lower at `max` than at `xhigh`. The company says extra code-review subagents caused a timeout or out-of-scope edits in some runs.[1] More thinking and more agents do not automatically produce a better patch.

Use this sequence for everyday work:

1. Bound the task with one deliverable and an acceptance check.
2. Run Sonnet 5.5 at `medium`.
3. Read the changed-file list and diff; run tests, lint, and build.
4. Try `high` if the same gap appears twice.
5. Move to Opus 5.5 if the problem is reasoning depth rather than an unclear task boundary.

The earlier Claude Sonnet 5 solo-builder guide covered the default-model idea for the previous generation. Sonnet 5.5 changes the routing question by combining a claimed capability gain with faster output and lower task cost. This guide narrows the decision to the new Sonnet-to-Opus threshold rather than repeating the earlier article.

When does Opus 5.5 make more sense?

Choose Opus because uncertainty and failure cost rise, not because the task looks large. An unknown production failure, an architecture boundary in a legacy system, a migration with data-loss risk, or a long synthesis across conflicting evidence all fit.

Anthropic says Sonnet 5.5 approaches Opus on some evaluations, but it also says Opus 5.5 remains clearly stronger on complex, open-ended work that needs sustained judgment.[1] That qualification matters. A close benchmark result does not mean the models handle the same task with the same reliability.

The rate-card gap is simple. Sonnet 5.5 costs $2/$10 per million input/output tokens, while Opus 5.5 costs $4/$20. Cache reads are $0.20 on both; a five-minute cache write is $2.50 on Sonnet and $5 on Opus.[1][3] Sonnet is cheaper at the same token count. The economics can reverse if a cheaper run needs three repair passes and Opus clears the acceptance check once.

Effort matters on the Opus side too. The Opus 5.5 effort guide routes `low`, `medium`, `high`, `xhigh`, and `max` by task risk. Instead of comparing Sonnet directly with Opus at `max`, begin with Sonnet `medium`, Sonnet `high`, and Opus `medium` against the same check.

Choosing for knowledge work, documents, and slides

A well-specified report, support response, working note, spreadsheet analysis, or deck built from an existing template is a reasonable Sonnet 5.5 task. Anthropic's announcement includes early-customer reports of faster processing, fewer output tokens, and fewer tool calls. These are selected customer statements from Slack, Zendesk, Box, Lovable, and others, not independent research.[1]

Sonnet 5.5 appears close to Opus 5.5 in Anthropic's GDPval-AA and AA-Briefcase tables. The same page notes that the prerelease deployment used for those evaluations had a structured-output bug and says Anthropic expects any effect to be small.[1] Do not turn the score into the decision. Check the work shape instead: are the sources known, is the template fixed, and can the output be reviewed cheaply? If yes, Sonnet is the sensible first candidate.

Better reasons to move to Opus 5.5 include:

• Reconciling many conflicting sources.
• Producing several viable strategies from incomplete evidence.
• Carrying earlier decisions consistently through a long job.
• Separating assumptions in advice with management, legal, or financial impact.
• Building an open-ended synthesis whose first draft is expensive to verify.

A document is not complete because it looks ready. Trace figures back to sources, check formulas, inspect template overflow, and reread the decision sentences yourself.

Measure task cost instead of benchmark rank

Pick the same three jobs for each model: a small code fix, an ordinary multi-file feature, and an ambiguous investigation. Hold the starting commit, prompt, tool permissions, time limit, and acceptance checks constant.

Record these for every run:

• Did it pass the acceptance checks on the first attempt?
• How many minutes did it take?
• What were the input, output, cache-read, and cache-write costs?
• How many tool calls and repair turns were needed?
• How many out-of-scope files changed?
• How long did human review take?

If Sonnet 5.5 at `medium` passes with a smaller diff and less time, it is the daily default for that task class. If Sonnet at `high` misses the same dependency twice and Opus at `medium` builds the correct plan on the first run, route that class upward. Five to ten representative jobs are safer than one polished demo.

For a wider model queue, the GPT-5.6 Sol–Terra–Luna pillar guide covers the speed, balance, and depth split. This article does not duplicate that search intent; it focuses on the escalation threshold between Sonnet 5.5 and Opus 5.5 inside Claude.

Migration points that can break

Changing the model name may not be enough for a Sonnet 5 integration. Anthropic's migration guide says `thinking: disabled`, forced `tool_choice` values of `any` and `tool`, some older computer-use tools, and some advisor pairings can return 400 errors on Sonnet 5.5.[2][4]

An application also needs to pass thinking blocks back unchanged in tool loops and keep the conversation history append-only where possible. Sonnet 5.5 cannot read thinking blocks from Opus 5 or Opus 5.5, and no other model reads Sonnet 5.5 thinking blocks.[2] Add this behavior to error and cost tests if an agent switches models mid-session.

On safety, Anthropic says Sonnet 5.5 matched or improved on Sonnet 5 across most measures in an automated audit of roughly 1,850 scenarios. The company also says no evaluation set catches every failure. Sonnet 5.5 launches with new cyber and reasoning-extraction safeguards; some high-risk requests may be refused or routed to Sonnet 5.[1]

Those are vendor assessments and product controls, not a safety guarantee. Use human approval for production changes, deletion, payments, personal data, or broad system access regardless of model. The coding-agent output verification checklist turns diff, test, and behavior checks into a separate gate after model selection.

Final choice

Sonnet 5.5 is the better first trial for everyday coding and well-scoped knowledge work. Its list price is half of Opus, and Anthropic claims faster output and lower task cost. Keep Opus 5.5 for open-ended problems, expensive failure, and sustained judgment.[1][3]

Making Sonnet the default does not mean never using Opus. Start with the faster, cheaper model; move up when the same measurable check fails; test again. Routing saves money only when the escalation and downgrade rules are both explicit.