The Claude Model Family: Haiku, Sonnet, Opus and When to Use Each

Claude is not a single model but a family, and picking the right tier is one of the highest-leverage decisions you make when you build with it. The tiers trade cost and speed against raw capability. Paying for the flagship on work a smaller model handles is one of the most common ways teams quietly overspend. Here is how the lineup breaks down, and a rule for choosing.

The tiers, from light to heavy

Anthropic names its models by weight class, and the metaphor is accurate.

Haiku is the fast, lightweight tier. It is the cheapest to run and the quickest to answer, built for high-volume, latency-sensitive work where you make many calls and each one needs to be cheap. Its context window is smaller than the larger models. Big enough for most single tasks, but not for pouring an entire codebase into one prompt.

Sonnet is the balanced tier, and it is where most everyday work should start. It pairs strong reasoning with a very large context window at a moderate price, which makes it the sensible default for writing, analysis, coding, and general assistant work. For a lot of teams, Sonnet is the only model they ever need.

Opus is the heavy tier, built for complex, multi-step agentic tasks. The kind where the model has to plan, use tools, and hold a long chain of reasoning without losing the thread. It costs more per token. It earns that when the problem is genuinely hard.

Above Opus sits the most capable tier, kept for the hardest problems where you want the best reasoning available and cost is a secondary concern. Most workloads never need to reach for it.

Context windows matter as much as capability

Here is a difference that is easy to miss. The larger models carry a much bigger context window, up to around a million tokens, while the lightweight tier carries a fraction of that. Context is what lets a model hold a whole book, a long contract, or a large codebase in one session.

So the choice is not only about how smart the model is. If your task means feeding in a large amount of text at once, that requirement alone can push you up a tier, no matter how simple the reasoning.

A simple rule for choosing

Here is a procedure that holds up in practice.

Start at the balanced tier. Assume Sonnet until something forces you off it.

Drop to the lightweight tier when you are running high volume, the task is simple, and cost or latency per call is the constraint. Classification, extraction, short replies, and routing usually belong here.

Move up to the heavy tier when the task is genuinely multi-step and agentic, long tool-use chains, complex planning, hard debugging, and the balanced model is visibly straining.

Reach for the top tier only when the problem is at the edge of what is possible and quality outweighs cost.

The mistake to avoid is defaulting to the most powerful model for everything. It feels safe. It quietly triples your bill for work a cheaper model does just as well.

Cost levers beyond the tier

Picking the tier is the biggest lever, but two others cut cost sharply without changing the model. Batch processing, submitting many requests together when you do not need an instant answer, is significantly cheaper than real-time calls. And prompt caching, which reuses a stable chunk of context across requests, drops the cost of the cached portion close to nothing. If you send the same long system prompt or document on every call, caching is almost free money.

Put together, these mean the effective price of a workload depends as much on how you call the model as on which model you call.

Matching tiers to real jobs

To make it concrete. A support bot answering routine questions at scale is a lightweight-tier job. A tool that reads long documents and drafts a summary is a balanced-tier job. An autonomous coding agent that plans a change across a large codebase, runs the tests, and iterates is a heavy-tier job. And a research task at the frontier of difficulty, where you want the strongest reasoning regardless of price, is where the top tier finally justifies itself.

Get that mapping right and the payoff is real: most of the flagship's quality at a fraction of the spend. Start balanced, move down for cheap high-volume tasks, move up for the genuinely hard ones, and layer in batching and caching to keep the bill honest.