Which Claude model to use: Sonnet, Opus or Haiku

In 2026, picking between Claude Sonnet, Opus and Haiku by asking "which model is smartest" makes little sense: all three are strong enough to ship. The questions that matter are different. Which one fits the shape of your task? How much reasoning depth do you actually need? How much context will you have to feed in? How soon must the user see the first token? How many of these calls per second will you make at peak?

This guide helps you make that call. By the end you should be able to take any task in your stack and say with confidence whose it is: Haiku, Sonnet 4.6 or Opus 4.8. You will also know when it should not be a Claude call at all.

The 2026 lineup at a glance

Anthropic's family is deliberately split into three cost shapes:

• Claude Haiku 4.5: the fast, cheap workhorse. Built for high-volume classification, data extraction, routing and short chats. It answers in a fraction of a second and costs so little that you can put it behind every page of your product.
• Claude Sonnet 4.6: the balanced default. It reasons well, holds a long context and works with tools and code. The price is roughly 5× Haiku's, and on most production workloads the quality sits so close to Opus that you rarely feel the gap.
• Claude Opus 4.8: the frontier tier for reasoning. Keep it for hard multi-step problems, agentic planning, deep research and decisions where a mistake is costly. One Opus call there replaces half a dozen Sonnet retries.

A handy mental model: Haiku indexes, Sonnet serves, Opus reasons. Most production systems use all three. Sonnet does the bulk of the work, and the other two join in only when the task profile calls for it.

Pricing per 1M tokens

Price works like gravity and bends every architectural decision. Here are the 2026 rates on codexkey, which match Anthropic's direct rates:

Take two things from the table. First, output tokens cost roughly 5× input tokens at every tier, so capping max_tokens and stopping streams early matters more than choosing a cheaper model. Second, Opus is exactly 5× Sonnet, which is exactly 5× Haiku. That is no accident: it is Anthropic's hint about when escalation pays. Moving from Sonnet to Opus only makes economic sense if Opus replaces at least five Sonnet calls or brings in revenue that Sonnet cannot.

For the economics of caching in detail, see Claude API pricing in 2026.

Decision matrix by task type

The cleanest way to assign tasks to models is to look at what kind of mental work the task actually needs.

Use Haiku when the task is shallow and high-volume

Haiku is the right answer whenever the model matches patterns instead of reasoning. Concretely:

• Classification: intent, sentiment, language and toxicity detection, ticket routing.
• Extraction: pull structured fields out of emails, invoices, resumes or chat logs and lay them into a JSON schema.
• Reranking and filtering: score retrieved chunks in a RAG pipeline, decide which messages need a human, screen out inputs that deserve a Sonnet call.
• Short autocomplete and suggestions: inline replies, search query expansion, tag suggestions.

If a task has a small, well-defined space of answers and you can fit its rubric on one page, Haiku handles it at a fraction of the cost, and its latency lets you put it straight into an interactive interface.

Use Sonnet for ordinary production work

Sonnet 5 remains the default for almost everything the user sees:

• Support agents that need to read the history, pull from a knowledge base and write a coherent reply.
• RAG assistants answering over your documentation, where the model has to combine information from several chunks instead of quoting one.
• Coding agents in everyday work: reading files, planning edits, calling tools, writing tests. Sonnet 4.6 is specifically tuned for code and tool use.
• Content generation at the level of a competent writer: marketing copy, summaries, drafts, translations.
• Workflow automation where the agent has to plan a few steps, call APIs and recover from an error.

The honest reason to default to Sonnet: it is good enough that you stop doubting the model and get on with the product. Opus is stronger, but rarely 5× stronger at the jobs Sonnet gets hired for.

Use Opus when the task is hard, rare or costly to get wrong

Opus 4.8 earns its price on a narrow band of work:

• Deep research: multi-source synthesis, literature reviews, competitive analysis, due diligence. Opus keeps more threads in working memory and argues noticeably more rigorously.
• Multi-step reasoning and planning: long agentic tasks where the model must break a goal into a tree of subtasks and recover after individual steps fail. Sonnet copes here too, but Opus needs fewer retries.
• Hard code: architectural design, debugging across many files, non-trivial migrations, performance work.
• High-stakes decisions: medical triage support, legal analysis, financial review, compliance. Anywhere one wrong answer costs more than five right ones.
• Evaluation and oversight: a smarter model judges the output of a cheaper one in a critic loop.

A reliable rule: if a task fails on Sonnet more than once in five tries, or if one wrong answer costs more than a hundred Opus calls, escalate.

Context window: what to look at

All three Claude models in 2026 support large context windows, but the shape of your context should still steer the choice.

Haiku copes fine with long documents for extraction and classification. Its weakness is not finding the right spot but reasoning over what it found. Stuff 80k tokens into Haiku and ask "what changed between versions 3 and 7 of this contract, and what are the legal implications", and the answer will be confident, fluent and partly wrong.

Sonnet is the right home for long-context RAG. It fits a whole codebase or a thick PDF and reasons coherently over it. Paired with prompt caching, the cost stays sensible even on large prompts.

You turn to Opus when the context is long and also internally contradictory or sparse, and the model has to reconcile sources actively instead of retelling them. The quality gain is real but shows only on hard inputs.

Latency: the trade-offs

Latency is the second axis after price. Approximate time to first token in 2026:

• Haiku: around 250 ms TTFT
• Sonnet 4.6: around 380 ms TTFT
• Opus 4.8: around 700 ms TTFT

In a streaming chat interface users perceive Haiku and Sonnet as "instant" and Opus as "thinking". A synchronous API call returning a 200-token JSON object takes Haiku about half of Sonnet's time and a third of Opus's. For a background job latency does not matter, so pick on price and quality.

A practical rule: anything on the user's critical path (typeahead, inline suggestions, real-time validation) goes to Haiku, unless you have measured that Sonnet's extra 130 ms is invisible to your users.

The routing pattern: start cheap, escalate on uncertainty

The most profitable architectural pattern on the 2026 lineup is tiered routing. Call the cheap model first, ask it to return a structured answer along with a confidence score, and move to a more expensive one only when confidence drops below a threshold.

import os
from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["CODEXKEY_API_KEY"],
    base_url="https://api.codexkey.online/v1",
)

SCHEMA_PROMPT = """
Classify the user's message into one of:
billing, technical, sales, abuse, other.

Reply with strict JSON:
{"label": "...", "confidence": 0.0 to 1.0, "reason": "..."}
"""

def classify(message: str, threshold: float = 0.75) -> dict:
    cheap = client.messages.create(
        model="claude-haiku-4",
        max_tokens=200,
        system=SCHEMA_PROMPT,
        messages=[{"role": "user", "content": message}],
    )
    result = parse_json(cheap.content[0].text)

    if result["confidence"] >= threshold:
        return {**result, "tier": "haiku"}

    # Escalate to Sonnet for uncertain cases.
    strong = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=400,
        system=SCHEMA_PROMPT,
        messages=[{"role": "user", "content": message}],
    )
    return {**parse_json(strong.content[0].text), "tier": "sonnet"}

In production this usually puts 80-95% of traffic on Haiku at Haiku prices, while Sonnet (or Opus, in a deeper pipeline) picks up the hard tail. The same pattern works for coding agents: let Haiku sketch a draft plan, let Sonnet execute it, and call Opus only if the plan reviewer reports low confidence.

For long-running agents, add a third tier: if Sonnet makes no progress on the same subgoal twice in a row, swap in model="claude-opus-4.8" for the next attempt. One Opus call beats five Sonnet retries on cost, latency and outcome.

When GPT-4o (or something else) still beats all three

Let us be honest about the edges of the Claude family. In 2026 it is worth looking outside it for:

• Real-time voice: if you need speech-to-speech under 200 ms with interruption handling, GPT-4o's realtime API fits better for now.
• Image generation: Claude reads images well but does not draw them. Put a dedicated image model next to it.
• Fine-tuning on your private data: if you need a model that absorbs closed domain data and behaves predictably on it, the fine-tunable models from other vendors fill that niche.
• On-device inference: Claude runs only in the cloud. For private or offline scenarios the honest answer is a local model.

For everything else (reasoning, code, long-context Q&A, agentic workflows, structured extraction) the 2026 Claude lineup is the default we recommend.

Bottom line

Default to Claude Sonnet 4.6 for production workloads. Move shallow, high-volume tasks to Haiku 4 as soon as you can write a rubric for them. Keep Opus 4.8 for the small set of problems where one right answer is worth more than five Sonnet attempts. Tie the tiers together with confidence-based routing and you get most of Opus's quality at most of Haiku's cost.

That is the whole game in 2026: the bottleneck is no longer the model, it is the routing.