Haiku vs Sonnet vs Opus vs Fable: which Claude model should you use?

A practical decision guide to Claude's four model tiers in August 2026 - cost per task, latency, context, reasoning depth, and a routing strategy that mixes them.

As of August 2026 there are four Claude models you can call. Start with Sonnet 5 at $2/$10 per million tokens. Route high-volume, well-defined work down to Haiku 4.5 at $1/$5. Escalate to Opus 5 at $5/$25 for complex agentic coding, and to Fable 5 at $10/$50 only when a task failure costs more than the tokens.

That is the short answer. The rest of this page is the reasoning: which model wins which task, what a thousand requests actually cost on each, and how to build a routing layer so you are not choosing one model for everything.

#The specification differences that change your decision

Four rows in this table do real work: context, knowledge cutoff, reasoning mode and price. The rest is detail.

Two of these surprise people. Knowledge cutoffs are not in version order: Opus 5 knows the world to May 2026 while Fable 5 - the more expensive, more capable model - stops in January. If recency is what your task needs, the answer is Opus 5, not the tier above it. And the tokenizer differs across the line-up: Sonnet 5, Opus 5 and Fable 5 use the tokenizer introduced with Opus 4.7, which counts roughly 30% more tokens for the same text than Haiku 4.5's. Every cross-tier price comparison involving Haiku understates Haiku's advantage by about that much. Full specifications for every model, current and retired, are on the model index.

#Which Claude model for which task

Pick by task shape, not by benchmark. Here is where each tier earns its price.

#What 1,000 requests actually cost

Prices per million tokens are hard to reason about. Here is the same workload on all four models, at a stated assumption: 1,000 requests, each with 4,000 input tokens and 500 output tokens as counted by that model's own tokenizer. The cached column assumes 3,000 of the 4,000 input tokens are a stable prefix served from cache at 0.1× base input.

Three caveats, all of which matter more than the table:

• These figures exclude thinking tokens. Adaptive thinking is on by default on Sonnet 5, Opus 5 and Fable 5, and thinking tokens bill at the output rate. A request that returns a 500-token answer after 3,000 tokens of reasoning costs seven times the output line shown here. Setting effort deliberately is the single biggest cost decision on the newer models - how the effort ladder works covers it.
• Haiku's real advantage is larger than shown. Because the columns are per-model tokenizer counts, the same source text produces roughly 30% fewer tokens on Haiku. Adjusted for equal text, the Haiku-to-Sonnet gap is nearer 2.6× than 2×.
• Caching and batching stack. They are independent multipliers. Batch plus caching takes Sonnet 5 from $13 to $3.80 per 1,000 requests - a bigger saving than dropping a tier. Details on both are on the Claude API page.

#Model routing: cheap first, escalate on low confidence

Choosing one model for a whole product is the expensive mistake. Real traffic is not uniform: most requests are easy and a minority are hard, and a routing layer lets you pay accordingly. The pattern is simple - run the cheap model, get a confidence signal alongside the answer, and re-run on a bigger model only when confidence is low.

The trick is making confidence a structured output rather than a number the model writes in prose. A forced tool call does that:

from anthropic import Anthropic

client = Anthropic()

LADDER = ["claude-haiku-4-5", "claude-sonnet-5", "claude-opus-5"]

ANSWER_TOOL = {
    "name": "submit_answer",
    "description": "Submit the answer and how confident you are in it.",
    "input_schema": {
        "type": "object",
        "properties": {
            "answer":     {"type": "string"},
            "confidence": {"type": "number", "description": "0.0 to 1.0"},
            "reason":     {"type": "string", "description": "Why confidence is low, if it is."},
        },
        "required": ["answer", "confidence"],
    },
}

def ask(question: str, threshold: float = 0.75, system: str = "") -> dict:
    for model in LADDER:
        msg = client.messages.create(
            model=model,
            max_tokens=2048,
            system=system,
            tools=[ANSWER_TOOL],
            tool_choice={"type": "tool", "name": "submit_answer"},
            messages=[{"role": "user", "content": question}],
        )
        result = next(b.input for b in msg.content if b.type == "tool_use")
        if result["confidence"] >= threshold:
            return {"model": model, **result}
    return {"model": LADDER[-1], **result}   # top of ladder wins by default

Four things to get right when you productionise this:

• Calibrate the threshold against labelled data, not intuition. Self-reported confidence is a useful signal but it is not a probability. Run a few hundred known-answer cases, plot escalation rate against accuracy, and pick the knee.
• Cache the shared prefix at every tier. The system prompt is identical across models, and each model caches independently. Note the differing minimums: 512 tokens on Opus 5 and Fable 5, 1,024 on Sonnet 5 and Haiku 4.5.
• Budget the escalation. A ladder that escalates 40% of traffic to Opus 5 costs more than sending everything to Sonnet 5. Log the escalation rate as a first-class metric; if it drifts above roughly a fifth, the cheap tier is the wrong choice for that workload.
• Do not pass temperature, top_p or top_k. They return a 400 error on Sonnet 5 and on Opus 4.7 and later. Shape behaviour through prompting instead - see prompt engineering.

Two variants are worth knowing. A triage router puts a tiny Haiku call in front that classifies difficulty and picks the model, which is cheaper than a failed attempt when your traffic splits cleanly. A decomposition router keeps an expensive model as the orchestrator and hands mechanical sub-tasks to Haiku subagents - the pattern Anthropic points to when it describes Haiku 4.5 as suited to sub-agent tasks. Both are covered in more depth under automation patterns.

#A decision list

Work down it and stop at the first match.

1. Is the task classification, extraction, routing, tagging or moderation, at volume? → Haiku 4.5. Cache the rubric, batch it if it is not interactive.
2. Does it need facts from 2026? → Not Haiku 4.5, whose training data stops in July 2025. If recency is the whole point, Opus 5 has the newest cutoff at May 2026.
3. Is the input larger than about 150,000 tokens? → Sonnet 5, Opus 5 or Fable 5. Haiku's window is 200k and you need headroom for output.
4. Is it complex agentic coding, or a multi-hour autonomous run? → Opus 5.
5. Has Opus 5 measurably failed the task on your own evaluation set? → Fable 5, accepting double the price, slower generation and tighter rate limits.
6. None of the above? → Sonnet 5. This is most traffic.

#What about the older models?

Sonnet 4.6, Sonnet 4.5, Opus 4.5, Opus 4.6, Opus 4.7 and Opus 4.8 all still work, but there is rarely a reason to start a new project on one. Sonnet 4.6 costs $3/$15 against Sonnet 5's $2/$10 and is worse; the only genuine argument for staying is that it uses the older tokenizer, which narrows the real gap. The Sonnet 4.6 page has the migration detail.

Several models people still ask about are gone entirely: Sonnet 3.7 and Haiku 3.5 retired on 19 February 2026, Haiku 3 on 20 April 2026, Opus 4 and Sonnet 4 on 15 June 2026, and Opus 4.1 on 5 August 2026. Calling any of them returns an error. Sonnet 4.5 is the oldest model still alive, with retirement no sooner than 29 September 2026. If you are on a chat plan rather than the API, model availability differs again - the pricing page sets out which plans expose model selection at all.

#Frequently asked questions