Overview of Claude models

You're scoping a new feature and the product manager asks the question every engineer building on Claude eventually hits: which model do we use? You already know the honest answer is "it depends" — but that's not useful on a Friday afternoon when you need to ship something on Monday. What you actually need is a short decision procedure you can run in your head.

That procedure starts with the shape of the Claude model family.

The three tiers

Claude ships as a family of models stratified along one axis that matters for real engineering decisions: how much reasoning capacity you're paying for per token. More capacity costs more and runs slower. Less capacity costs less and runs faster. Everything else flows from that.

Haiku sits at the speed-and-cost end. It's the model you reach for when the task is well-defined, the input is bounded, and latency is part of the product. Classification, extraction, routing, "is this text toxic," "which category is this ticket" — Haiku is built for the fat tail of small, repeatable calls that used to be cron jobs and regexes.

Sonnet is the default. It's the balanced tier — strong general reasoning, solid coding, good instruction following, and pricing that lets you build things that aren't batch jobs. Most production features that sit in front of a user start life on Sonnet and stay there.

Opus is the heavy lifter. You pay more and you wait longer, but you get noticeably better performance on deep reasoning, long-horizon planning, hard code, and the kind of ambiguous task where a cheaper model starts compounding small mistakes into big ones. It's the model you call when being right matters more than being fast.

The decision guide

When you're picking a model, run through three questions:

1. How precise does the output need to be? If a wrong answer costs you hours downstream — a bad refactor, a corrupted dataset, a misclassified high-value customer — the cheaper model is the more expensive choice.
2. How tight is your latency budget? User-facing autocomplete and chat have millisecond budgets; overnight pipelines don't. Pick accordingly.
3. How much does a single call cost times the number of calls you'll make? A 10x price difference is irrelevant at 1,000 calls and catastrophic at 10 million.

Here's how that shakes out in practice:

| Use case | Start with | Why | |---|---|---| | Classification, tagging, routing | Haiku | High volume, narrow task, needs to be cheap and fast | | Extraction of structured fields from text | Haiku | Well-defined output shape, minimal reasoning | | Summarization of standard documents | Haiku or Sonnet | Depends on length and nuance required | | Chat assistants, Q&A over docs | Sonnet | Balanced quality for conversational UX | | Code generation and review | Sonnet | Strong coding at workable latency | | Agents with tool use | Sonnet | Reasoning over tool outputs without Opus cost | | Hard multi-step reasoning | Opus | Worth the cost when correctness compounds | | Long-horizon planning | Opus | Ambiguity tolerance and recovery from dead ends | | Complex code generation on critical paths | Opus | Fewer silent bugs you'll have to unwind later |

Default posture: start on Sonnet, measure, then move up or down. Opus when the evals prove you need it. Haiku when the volume proves you can't afford anything else.

A note on model evolution

Model names and capabilities shift. New versions release, pricing adjusts, and a task that needed Opus last year often runs fine on this year's Sonnet. Treat this mapping as a snapshot of the tiered logic — fast/cheap, balanced, heavy — not as a fixed table of product IDs. The tier you want is the one that clears your quality bar at the lowest cost, and you verify that with evals, not vibes. That's the next thing this course teaches you to do.