Claude Opus vs Sonnet: which model to pick for your task in 2026

Anthropic ships three main Claude lines: Opus (flagship), Sonnet (balance), Haiku (speed). Above them sits the Fable top tier. The whole lineup refreshed in autumn 2026: Opus 5.5 landed on 22 September, Sonnet 5.5 on 28 September, Haiku 5.5 on 7 October, and Fable 5.1 sits alongside. Each model is tuned for its own class of work, and the choice between them comes down to the task, not to “which one is better.”

So here are the actual numbers: prices, thinking modes, the tokenizer, cost scenarios. Plus a decision framework at the end that answers the question in 30 seconds.

The Claude lineup in 2026: three models, three strategies

Haiku 5.5 has two rate tiers: $0.10/$0.50 for prompts up to 100,000 tokens and $0.50/$2.50 for longer ones. On Opus 5.5 and Sonnet 5.5 the 1M context comes at the standard price: a 900K request costs the same per token as a 9K one. Anthropic’s comparison table also includes Fable 5.1 ($10/$50, 1M context, 128K output), the model for demanding reasoning and long-horizon agentic work.

Anthropic’s documentation suggests starting evaluation with Opus 5.5 for most workloads, and reaching for Fable 5.1 if your evals on Opus 5.5 still fall short at higher effort. The same docs describe Sonnet 5.5 as the model “for everyday coding, agent, and enterprise workloads.” The two recommendations fit together: Opus 5.5 is the top point to test against, Sonnet 5.5 is where you step down to if you can’t see a difference on your task.

The previous models are still around. Opus 5, Opus 4.8, Sonnet 5, and Sonnet 4.6 are Active, and Anthropic commits to keeping them at least until: Opus 5, 24 July 2027; Sonnet 5, 30 June 2027; Opus 4.8, 28 May 2027; Sonnet 4.6, 17 February 2027. Haiku 4.5 is also Active, but its “not sooner than” date of 15 October 2026 has passed, so retirement can come at any time: don’t build anything new on it. Sonnet 4.5 is already deprecated and retires on 30 November 2026. New projects are better off starting on 5.5.

Model versioning

claude-opus-5-5     # Opus 5.5 (pinned snapshot)
claude-sonnet-5-5   # Sonnet 5.5 (pinned snapshot)
claude-haiku-5-5    # Haiku 5.5 (pinned snapshot)
claude-fable-5-1    # Fable 5.1, top tier

All current model IDs are pinned snapshots: there’s no date in the ID, but it isn’t an evergreen pointer, it’s the snapshot itself. Model behavior won’t shift when the line gets updated, which is convenient for production.

Claude Opus 5.5: when every point of accuracy matters

Opus 5.5 shipped on 22 September 2026 at $4/$20, 20% less than Opus 5 ($5/$25). Anthropic says the model performs at the level of Fable 5.1 on most work, and costs roughly 40% less to run than Opus 5 on typical workloads.

What Anthropic claims

Official benchmarks from the Opus 5.5 and Sonnet 5.5 announcements (conditions differ between rows, with effort and configuration given in the announcements’ footnotes, so treat this as a guide rather than a clean A/B):

What follows from this:

• Opus 5.5 is clearly stronger than Opus 5. The gain shows in every row, at a lower price.
• Sonnet 5.5 sits close to Opus 5.5 on these tests, and well ahead of Sonnet 5. Anthropic also states plainly that Opus 5.5 stays clearly stronger on complex, open-ended work that needs sustained judgment. Benchmarks don’t fully capture that kind of work.
• Read GDPval-AA with care. Anthropic notes that a pre-release Artificial Analysis bug may have understated Sonnet 5.5’s GDPval-AA results; it has since been fixed.

For exact numbers on other tests (SWE-bench, GPQA and the rest), check the announcements and the System Card on Anthropic’s site. Independent aggregators disagree on them.

Fast mode

Opus 5.5 has a fast mode: the same model with up to 2.5x higher output tokens per second, at $8/$40 per MTok. You switch it on with speed: "fast", and Opus 5.5 needs no beta header. Fast mode doesn’t work with the Batch API.

When to use Opus

1. Long-horizon agentic coding. Tasks that run dozens of steps with tools: migrations, multi-file features, large refactors. This is what Anthropic aims Opus 5.5 at: multi-hour autonomous coding agents, large-scale refactoring, complex systems engineering.

2. Architectural decisions. Trade-off analysis, weighing the long-term consequences of a stack choice, system design review. An architecture mistake costs weeks of rework, and next to that Opus tokens are cheap.

3. Complex multi-step reasoning. Holding several contexts at once: analyzing 10+ files, spotting non-obvious dependencies, tracing data flow across several services.

4. Critical code reviews. The final review before merging to main, security audits, race condition and edge case analysis.

5. Computer use and vision-heavy workflows. Anthropic lists both as typical Opus 5.5 work. Computer use needs the computer_toolset_20260801 toolset.

When Opus is overkill

• Simple CRUD operations, boilerplate code
• Classification and data extraction
• Summarization and reformatting
• Support chatbots
• Anything where Sonnet gives an acceptable result

Claude Sonnet 5.5: the workhorse

Sonnet 5.5 shipped on 28 September 2026 at the same price as Sonnet 5: $2/$10 per MTok. For Sonnet 5 that price started out as introductory and became permanent in August, so the planned rise to $3/$15 won’t happen. Only the cache read is cheaper on Sonnet 5.5, at $0.10 against $0.20 on Sonnet 5. Anthropic says it costs up to 30% less per task than its predecessor and generates output more than 30% faster.

What we know about quality

Anthropic’s official claims:

• On the benchmarks in the table above Sonnet 5.5 trails Opus 5.5 by a few points (GDPval-AA by two Elo points, CursorBench by 2.3 points: 55.5% vs 57.8%) and is far ahead of Sonnet 5.
• Against Sonnet 5: GDPval-AA is about 400 Elo points higher (1844 vs 1449).
• On cost: at low effort on CursorBench, Sonnet 5.5 beats Sonnet 5’s best score for less than a tenth of the cost per task.
• Opus 5.5, in Anthropic’s words, remains clearly stronger on complex, open-ended work requiring sustained judgment.

The generational pattern repeats: the middle model gets close to the flagship. For teams that means the gap between Sonnet and Opus on typical tasks needs measuring on your own data first.

Tokenizer: shared across the 5.5 lineup

Since Opus 4.7 Anthropic has used a new tokenizer, and the same text takes roughly 30% more tokens than on Sonnet 4.6 and earlier models. Of the current models, Opus 5.5, Sonnet 5.5 (same tokenizer as Sonnet 5), and Haiku 5.5 (about 30% more tokens than Haiku 4.5) all use it. The exact increase depends on the content: the Opus 5.5 migration docs put it at 1x to 1.35x. The API format didn’t change, but this hits money and limits directly:

• On paper the price dropped by a factor of 1.5 when moving from Sonnet 4.6 ($3/$15 → $2/$10). But the same volume of text burns more tokens, so the real saving lands between about 10% (at 1.35x) and 33% (at 1x), and around 13% at +30%.
• max_tokens budgets sized for Sonnet 4.6 or Haiku 4.5 will run short and answers will start getting truncated. Recalculate the limits with about 30% headroom. On the 5.5 models max_tokens also covers thinking, not just the answer text.
• Opus 5.5 and Sonnet 5.5 tokenize identically, so the gap on the price list is exactly 2x on both input and output.

None of this cancels out what the new lineup gives you. Just count the cost on actual tokens from your own traffic when you migrate, not on the price list.

When to use Sonnet

1. Everyday coding. Writing functions, components, tests. Refactoring. Migrations. Everything that doesn’t need Opus-grade long agent chains.

2. Interactive code generation. IDE scenarios, generation from a description, inline suggestions. Speed and price matter more here than the last few points of accuracy.

3. Content and copywriting. Articles, product descriptions, email campaigns, marketing copy.

4. Data analysis. Parsing data, generating SQL, building reports, summarization.

5. Chatbots and assistants. Customer-facing AI, where response speed and cost per session matter.

6. Agentic workflows. Sonnet as the main worker agent in a multi-agent system: smart enough for most steps, cheap enough for long chains.

Claude Haiku 5.5: speed and cost first

Haiku 5.5 shipped on 7 October 2026 with a 1M token context, 128K max output, and a price from $0.10/$0.50 per MTok, against $1/$5 for Haiku 4.5. Prompts over 100,000 tokens move to a higher rate: $0.50/$2.50. In Anthropic’s comparison table Haiku 5.5 has the lowest latency in the line. Version 4.5 stays available, but 5.5 is cheaper for the same jobs.

When to use Haiku

1. Classification and routing. Request type, ticket category, user intent, in fractions of a second at minimal cost.
2. Data extraction. Pulling structured data: names, dates, amounts, addresses.
3. Preprocessing in a pipeline. The first stage of a multi-agent system: Haiku classifies and routes to the right worker agent. Anthropic lists subagent tasks as a typical use.
4. High-throughput batch processing. Thousands of documents, emails, tickets: at $0.10/MTok input, 10,000 documents of 500 tokens each cost $0.50 for input alone (before output and thinking tokens).
5. Guardrails and moderation. Checking input/output for safety and format.

When to test Haiku separately

Anthropic doesn’t position Haiku for hard tasks, and there are no public comparisons on them. For complex coding (multi-file changes, architectural decisions), long reasoning, and generating long, high-quality text, run an eval on your own data first. Prompts over 100,000 tokens cost 5 times the base rate.

Pricing in detail

Base rates and multipliers

All prices are per million tokens (MTok). For Haiku 5.5 the table shows the rate for prompts up to 100,000 tokens:

New in this generation: a cache read on Opus 5.5 and Sonnet 5.5 costs 5% of the input price (it used to be 10%). The minimum cacheable prefix is 512 tokens on all three models (it was 1024 on Opus 4.8 and Sonnet 5), so short system prompts are cacheable now. Fast mode for Opus 5.5 costs $8/$40.

Prompt caching: how the savings work

Prompt caching stores part of the context (system prompt, docs, examples) and reuses it on later requests: a cache write costs 1.25x input (5-minute TTL) or 2x (hourly), a cache read costs 0.05x on Opus 5.5 and Sonnet 5.5.

An example with Sonnet 5.5. System prompt = 10,000 tokens, sent in each of 100 requests:

No cache:   10,000 × 100 × $2.00 / 1M = $2.00
Cached:     10,000 × $2.50 / 1M + 10,000 × 99 × $0.10 / 1M = $0.025 + $0.099 = $0.124
Savings:    ~94%

Caching pays for itself after the very first cache read.

Batch API: a 50% discount

The Batch API processes requests asynchronously within 24 hours at a 50% discount on input and output. It fits anything that doesn’t need a real-time answer: data processing, content generation, bulk migrations. The Batch and caching discounts combine.

Batch + caching is the maximum saving on Opus 5.5:

Standard input: $4.00/MTok
Batch + cache:  $4.00 × 0.5 × 0.05 = $0.10/MTok
Savings: 97.5%

Cost math for typical scenarios

Calculated from the price list above, without cache write costs or thinking tokens (those are billed as output, so real bills will be higher).

Scenario 1: one developer, 100 requests/day

Average request: 3K input + 1.5K output. 30 days.

Scenario 2: a SaaS product, 10,000 requests/day

Average request: 7K input (5K system prompt + 2K user) + 800 output. Cache on the system prompt.

Telling detail: on this profile Haiku 5.5 is about 20 times cheaper than Sonnet 5.5, while caching cuts the bill by “only” 1.7 to 1.8 times. Picking the model class saves an order of magnitude more than caching does, but only if Haiku can actually handle the task, and you check that on your own data.

Scenario 3: a multi-model architecture

10,000 requests/day: Haiku classifies everything, Sonnet handles 80%, Opus takes the hard 20%.

Haiku routing:  10,000 × (500 × $0.10 + 100 × $0.50) / 1M × 30 = $30/mo
Sonnet worker:  8,000 × (2000 × $2 + 800 × $10) / 1M × 30      = $2,880/mo
Opus worker:    2,000 × (3000 × $4 + 1500 × $20) / 1M × 30     = $2,520/mo
Total: $5,430/mo

vs the same requests with the same profiles entirely on Opus 5.5 (no router): $8,280/mo
Savings: ~34%

Caching the system prompts will bring the bill down further.

Adaptive thinking: what changed in the 5.5 lineup

Thinking used to require turning on explicitly. Now adaptive thinking is on by default: the model decides for itself whether to reason before answering and how many tokens to spend on it. Thinking tokens are billed as output, even when the thinking text isn’t returned to you.

Four practical consequences:

1. The budget_tokens parameter isn’t accepted. Code with classic extended thinking (thinking: {type: "enabled", budget_tokens: N}) returns a 400 error on Opus 5.5 and Sonnet 5.5. The docs mark extended thinking as deprecated on Opus 4.6 and Sonnet 4.6 and not accepted on later models.

2. Depth is controlled by effort level. The ladder is low / medium / high / xhigh / max. The default depends on the model: medium on Opus 5.5 (Opus 5 had high) and Haiku 5.5, high on Sonnet 5.5. Anthropic warns that effort levels on Sonnet 5.5 are recalibrated against Sonnet 5, so re-run your effort sweep rather than carrying a setting over.

3. Turning thinking off works differently per model. On Opus 5.5 adaptive thinking is always on: thinking: {type: "disabled"} and enabled are rejected. On Sonnet 5.5 disabled also returns a 400, and the replacement is thinking: {type: "between_tools"}, which turns off reasoning before the answer (the short notes between tool calls stay). between_tools is accepted at low, medium, and high effort; at xhigh and max it returns a 400.

4. A response can start with thinking blocks. By default thinking.display is "omitted": the blocks arrive with an empty thinking field. Code that reads content[0].text breaks. Pick blocks by type, and in tool-use loops pass the thinking blocks back to the API unmodified.

A practical rule: don’t try to switch thinking off without a measured reason. For latency-critical cases, lower the effort first, and on Sonnet 5.5 try between_tools. Check the latency win on your own traffic before you trade away quality.

Practical scenarios: which model for what

Code generation → Sonnet 5.5

Writing functions, components, API endpoints. Anthropic names this as the core job for Sonnet 5.5; speed and price matter more than the last few points.

# Typical request, Sonnet handles it
"Write a FastAPI endpoint for creating a user
 with Pydantic validation and a write to PostgreSQL"

Exception: hard algorithmic problems, concurrency, low-level optimization: test those on Opus.

Long-horizon agentic work → Opus 5.5

Migrations across dozens of files, features from spec to PR, long tool-use cycles. This is the class of work Anthropic lists for Opus 5.5. If even that isn’t enough for you, the next step up is Fable 5.1.

Architecture review → Opus 5.5

System design assessment, trade-off analysis, reviewing PRs with architectural changes. A mistake here is expensive, and a single Opus call costs cents or tens of cents.

Data extraction → Haiku 5.5

Pulling structured data, classification, intent detection. This is what Anthropic builds Haiku for; the price is 20 times below Sonnet 5.5 ($0.10/$0.50 vs $2/$10). Check the quality on your own sample.

Customer support → Sonnet or Haiku

• Tier 1 (FAQ, order status): Haiku, fast, cheap, usually good enough
• Tier 2 (technical support): Sonnet, you need context understanding
• Tier 3 (escalation, hard cases): Sonnet or Opus, depends on how critical it is

Multi-agent pipeline → Haiku + Sonnet + Opus

User request
    ↓
[Haiku] - Classification + Routing
    ↓
┌─ Simple   → [Haiku]  - direct answer
├─ Standard → [Sonnet] - generation
└─ Complex  → [Opus]   - deep analysis

Haiku as a router sends cheap requests to the cheap model (the math is in scenario 3).

Decision framework: how to choose in 30 seconds

Step 1: rate the task complexity

Step 2: check the constraints

Need context > 100K on Haiku?  → the price rises 5x; compare with Sonnet 5.5
Need output > 128K?            → Batch API with the output-300k-2026-03-24 beta header (up to 300K)
Latency-critical scenario?     → Haiku, Sonnet at low effort or with between_tools, fast mode on Opus 5.5
Need thinking off?             → Opus 5.5 can't; Sonnet 5.5 uses between_tools
Budget < $50/mo?               → Haiku or Sonnet with caching

Context (1M) and output (128K) are the same on all three models, so don’t use them to choose between the three.

Step 3: apply the split heuristic

This is the author’s rule of thumb, not an Anthropic recommendation. Tune the proportions to your own evals:

• ~80% of requests → Sonnet 5.5 (the main work)
• ~15% of requests → Haiku 5.5 (routing, classification, simple tasks)
• ~5% of requests → Opus 5.5 (critical decisions, long agent chains)

If your evals show Haiku handling part of the main work too, you can raise Haiku’s share: it’s 20 times cheaper than Sonnet.

Migrating to the 5.5 lineup

An API call looks the same for every Claude model, and only model changes. But the 5.5 models have requirements that break requests written for older versions:

1. Thinking. On Opus 5.5 remove thinking: {type: "disabled"} and enabled/budget_tokens, and set depth through effort. On Sonnet 5.5 replace disabled with between_tools (effort high or below).
2. Effort and max_tokens. Set effort explicitly: the defaults differ (medium on Opus 5.5, high on Sonnet 5.5). max_tokens covers thinking plus text; at xhigh and max Anthropic advises starting at 64K tokens. Coming from Sonnet 4.6 or Haiku 4.5, also recalculate limits for the tokenizer (~30% more tokens).
3. Sampling and tool_choice. temperature, top_p, and top_k return a 400, so remove them. Forced tool_choice (any or tool) does too: use auto plus strict tool use or structured outputs. Assistant prefill is rejected on Opus 5.5.
4. Response blocks. Read text by type, not by index. In tool-use loops, pass thinking blocks back unmodified. On Sonnet 5.5 keep the conversation history append-only: editing earlier history and then replaying a thinking block can return a 400.
5. Platform details. Priority Tier isn’t supported on Opus 5.5. Fast mode on Opus 4.8 is removed on 30 November 2026, after which it’s only on Opus 5.5.
6. A/B test on your own data, not on benchmarks. Send half your traffic to the new model, then compare quality and actual token cost. If the quality difference between Sonnet 5.5 and Opus 5.5 is invisible for your task, you just halved your bill.

# The call stays the same: model changes, and effort is best set explicitly
response = client.messages.create(
    model="claude-sonnet-5-5",  # ← was claude-sonnet-4-6
    max_tokens=8192,
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": prompt}],
)

# Find the answer text by block type: thinking blocks may come first
text = next(b.text for b in response.content if b.type == "text")

Bottom line

Three models, three strategies. The “best Claude model” is the one that fits the task in front of you.

Opus 5.5 is for when a mistake costs more than tokens. Long agentic work, architecture, final reviews. It costs 20% less than Opus 5 ($4/$20) and is clearly stronger in the official benchmarks. Only Fable 5.1 ($10/$50) sits above it.

Sonnet 5.5 is the default choice for typical work. Results in the official benchmarks are close to Opus 5.5, at half the price ($2/$10). The one caveat is the tokenizer: coming from Sonnet 4.6, the real saving is smaller than the nominal one, so count it on your own traffic.

Haiku 5.5 is speed and scale. Classification, routing, extraction, preprocessing. From $0.10/$0.50, with a 1M context.

Better yet, combine all three: Haiku routes, Sonnet processes, Opus decides the hard calls. Prompt caching cuts the price of re-read input to 5% on Opus 5.5 and Sonnet 5.5, and the Batch API takes another 50% off.

If you’re not sure where to start, don’t overcomplicate it. Run your evals on Sonnet 5.5, run the same set on Opus 5.5, and move up only if the difference shows. Measure. Optimize.