Haiku, Sonnet, and Opus are three levels of the same AI family, built so you can trade a little power for a lot of speed, or the other way around.

What a model family is

A language model is a computer program trained on huge amounts of text so that it can read questions and write answers. A model family is a group of such models that come from the same maker, share the same general design and values, and differ mainly in size and strength. Claude is the family name. Inside it, Anthropic sorts its models into tiers, and the three main tiers are Haiku, Sonnet, and Opus.

The one-sentence version of each tier

Haiku is the smallest and fastest tier. It is built for quick answers at a low price, especially when you have a lot of requests to handle. Sonnet is the middle tier. It aims to be smart enough for most real work while staying fast and affordable. Opus is the largest tier. It is meant for the hardest problems, where getting the best possible answer matters more than saving time or money.

Where you can meet them

You can use these models in several ways. The Claude apps on the web, desktop, and phones let you chat with them, and you can switch models during a conversation. Claude Code is a tool that helps software engineers write and fix code. Developers can also build their own products using the Claude API, which is a way for one program to send questions to Claude and get answers back. Some cloud platforms, such as Amazon Bedrock and Google Cloud Vertex AI, also offer Claude models.

The names are not random. They hint at size, and the history shows how the tiers keep improving.

The meaning behind the words

All three names come from the world of writing and music. A haiku is a very short poem, traditionally just seventeen syllables long. A sonnet is a longer poem of fourteen lines with a careful structure. An opus is a large, major work, such as a symphony or a great book. So the order of the names is also the order of size: small, medium, large. You can remember the whole family just by thinking of a short poem, a longer poem, and a grand masterpiece.

A short timeline

A pattern is easy to see in this history. Each new generation lifts every tier. What was once only possible with the biggest model slowly becomes possible with a smaller, cheaper one. That is why you should revisit your model choices every few months instead of choosing once and forgetting.

Every model choice is a balance between three things, and you rarely get all three at once.

Capability

Capability means how well the model handles hard work: following long and tricky instructions, reasoning through multi-step problems, writing careful code, understanding subtle meaning, and avoiding mistakes. Larger models generally have more of it. Capability matters most when a task is complicated or when a wrong answer would be costly.

Speed

Speed has two parts. Latency is the wait before the answer starts to appear. Throughput is how many answers the system can finish in a given time. Smaller models usually respond faster, because there is less computing work behind every word they write. Speed matters most when a human is waiting, such as in a live chat, a voice assistant, or an auto-complete box.

Cost

Models are usually billed by the token, which is a small piece of text the model reads or writes. Smaller models generally cost less per token than larger ones. At a few requests, the difference is tiny. At millions of requests, it decides whether a product is profitable. If tokens are new to you, think of them as the small units of text that every AI service counts and charges for.

The words in the table are relative on purpose. Exact prices, speeds, and scores change with every release, and they are published on Anthropic’s pricing and model pages. What stays stable is the ordering: within one generation, price and depth generally rise from Haiku to Opus, while speed generally falls.

Haiku is the small, quick tier, designed for tasks where speed and low cost matter most.

What Haiku is

Haiku is the smallest model in the family. It is like the nurse at the front desk: it answers quickly, handles a very large number of routine questions, and rarely keeps anyone waiting. Because it is cheap to run, it lets you use AI in places where a bigger model would be too slow or too expensive.

What Haiku does well

Sonnet is the middle tier and the default choice for most everyday work.

What Sonnet is

Sonnet sits between the other two. It is like the general doctor: capable enough to handle the large majority of problems, quick enough that nobody waits long, and affordable enough to use all day. For many teams it is the first model they try, and for many tasks it is also the last model they need.

What Sonnet does well

Opus is the most capable of the three, kept for problems where depth and accuracy matter most.

What Opus is

Opus is the largest tier in the core family. It is like the specialist doctor: you do not see it for every small problem, but when a case is complicated, rare, or serious, its depth is worth the extra time and cost. It tends to handle long chains of reasoning, subtle trade-offs, and large, messy tasks better than the smaller tiers.

What Opus does well

A model name is a small label with three parts, and each part tells you something useful.

The parts of a name

Take the name “Claude Sonnet 5.5”. The first word, Claude, is the family. The second word, Sonnet, is the tier, which tells you the size class. The number, 5.5, is the generation and version, which tells you how new the model is. Two models with the same tier but different numbers are not the same. The higher number is usually newer and usually better.

Names inside the API

Developers refer to models by a short text code called a model ID or model string. It is the exact name you type into your program to tell the service which model to use. The current ones follow a simple pattern, as the table shows.

The tier above Opus

Anthropic has also described a Mythos tier that sits above Opus. The first of these models, Claude Mythos Preview, is not open to the public and is used by a small number of trusted organizations as part of a program called Project Glasswing. The current Mythos-class models, Claude Mythos 5.1 and Claude Fable 5.1, share the same underlying model, but Fable has extra safety measures for biology, cybersecurity, and AI research. For most people and most projects, Haiku, Sonnet, and Opus remain the everyday choices.

Why version pinning matters

When your app calls a model, it is wise to name an exact version, and to test again before moving to a new one. Providers occasionally retire older models after giving notice, so a quiet change in the model underneath your product can change its behavior. Pinning a version and planning upgrades keeps your results steady.

All three tiers follow one basic recipe. They differ mainly in how much brainpower is packed into them.

The shared recipe

All Claude models are large language models built on a design called the transformer. During a first stage called pretraining, the model reads enormous amounts of text, cut into tokens, and practices guessing the next token over and over. After that, it goes through further training in which humans and written principles guide it toward being helpful, honest, and careful. Anthropic uses a method it calls Constitutional AI, where a written set of principles helps shape the model’s behavior.

flowchart LR
  A["Huge text collection"] --> B["Tokenizer turns text into tokens"]
  B --> C["Pretraining: learn to predict the next token"]
  C --> H["Smaller model: Haiku tier"]
  C --> S["Medium model: Sonnet tier"]
  C --> O["Larger model: Opus tier"]
  H --> D["Fine-tuning with human feedback and written principles"]
  S --> D
  O --> D
  D --> E["Safety testing and release"]
  E --> F["Access through apps, Claude Code, API, and cloud platforms"]
    

The picture shows one shared path that splits into three model sizes and then comes back together for tuning, testing, and release. Anthropic does not publish the exact sizes or training recipes of its models, so nobody outside the company can say precisely how many parameters, which are the adjustable numbers inside a model, each tier has. What matters in practice is the behavior you can measure: speed, price, and quality on your own tasks.

What stays the same across tiers

What changes across tiers

The biggest changes are depth, speed, and price. Larger tiers usually follow long and complicated instructions better, hold more details in mind at once, and make fewer reasoning slips. Smaller tiers answer quicker and cost less. Features can also differ by model and by generation, such as the maximum size of the context window, which is the number of tokens a model can handle in one request, and the maximum length of an answer.

In a well-built product, not every question goes to the same model. A small piece of logic decides who should answer.

A router is a small piece of software that looks at each incoming request and decides which model should handle it. The router can be very simple, such as a rule that says “short questions go to Haiku.” It can also be a tiny model of its own that rates how hard the request looks. Either way, its job is to send easy work to the cheap, fast tier and save the expensive tier for the problems that truly need it.

flowchart TD
  U["User request"] --> R["Router: simple rules or a small classifier"]
  R -->|Simple and high volume| H["Haiku tier"]
  R -->|Everyday complexity| S["Sonnet tier"]
  R -->|Hard or high stakes| O["Opus tier"]
  H --> V["Quality check"]
  S --> V
  O --> V
  V -->|Passes| A["Answer returned to the user"]
  V -->|Fails| E["Retry on a stronger tier"]
  E --> O
    

The diagram has three stages. First, the router sorts requests by difficulty. Second, the chosen tier produces an answer. Third, a quality check, which can be a rule, a test, or another model, decides whether the answer is good enough. If it is not, the request is retried on a stronger tier. This design is often called a cascade, because requests fall from cheap options toward expensive ones only when needed.

The life of one request

There is no free lunch in model choice. Each strategy gains something and gives something up.

A worked example with practice numbers

To see why mixing tiers can save money, use some made-up relative costs. These are not real prices. Suppose one Haiku task costs 1 unit, one Sonnet task costs 3 units, and one Opus task costs 5 units. Imagine a product that handles one million tasks, where careful testing shows that 70 percent are simple, 25 percent are medium, and only 5 percent are hard.

The routed cost per task is 0.70 plus 0.75 plus 0.25, which is 1.70 units. Compared with sending everything to Opus, that is a saving of about 66 percent. The routed design also answers most requests faster, since most go to the quick tier. The catch is that you must keep checking that the routing is accurate, because a wrongly routed hard request can produce a poor answer.

A handful of simple questions will usually point you to the right model.

A quick starting guide

The real power comes from using the tiers together, each doing what it does best.

The planner and workers pattern in detail

In this pattern, one strong model acts as a team leader. It reads the goal, breaks it into small jobs, hands those jobs to several faster models working at the same time, and then combines what comes back. Anthropic has written about building a research system in this style, where a lead agent plans the search and several helper agents explore different parts of the question in parallel. Claude Code also lets you choose the model, and tasks handed to helper agents can run on a different model from the main one.

flowchart TD
  G["Goal from the user"] --> L["Lead agent on a strong tier plans the work"]
  L --> W1["Worker agent A on a fast tier"]
  L --> W2["Worker agent B on a fast tier"]
  L --> W3["Worker agent C on a fast tier"]
  W1 --> M["Lead agent merges and checks the results"]
  W2 --> M
  W3 --> M
  M --> F["Final answer to the user"]
    

The diagram shows a fan-out and a fan-in. The leader spreads the work out to several workers, which saves time because the pieces run side by side, and then pulls everything back together. The expensive model is used only twice, at the start and at the end, while the cheaper models do the bulk of the reading and searching.

Choosing a bigger model does not remove the need for careful engineering. Safety belongs to the whole system, not just the model.

Human review for high stakes

Even the strongest tier can make mistakes, invent details, or misread a situation. For medical, legal, financial, or safety-related work, treat the output as a draft for an expert to review rather than a final decision. This habit costs little and prevents the rare but serious failures.

You cannot improve what you do not measure. A short testing loop keeps your model choices honest.

An evaluation, often shortened to an eval, is a set of example tasks with known good answers or clear checks, used to score a model. Evals are the single most useful tool for choosing a tier. They replace guesswork and marketing claims with evidence from your own work. A small set of fifty to a few hundred real examples is a good start.

flowchart LR
  A["Collect real examples"] --> B["Write expected answers or checks"]
  B --> C["Run each tier on the examples"]
  C --> D["Score quality, speed, and cost"]
  D --> E["Pick the cheapest tier that passes"]
  E --> F["Deploy and monitor"]
  F --> G["New failures found in production"]
  G --> A
    

The diagram is a circle on purpose. You start with real examples, test each tier, choose the cheapest one that passes, and then watch it in production. Every failure you find in the real world becomes a new example in your test set. Over time, the tests become a more faithful copy of your real work.

Metrics worth tracking

Managing versions over time

New versions arrive regularly, and old ones are eventually retired. Treat each upgrade like any other software change. Re-run your evals on the new version, compare quality and cost against the old one, roll out gradually, and keep the ability to go back. Because a new Sonnet may match what used to require an Opus, each upgrade is also a chance to move work to a cheaper tier.

Follow a few habits, avoid a few traps, and most of the pain disappears.

Habits that pay off

Mistakes to avoid

These typical situations show how teams combine the three tiers. They are illustrations of common patterns, not claims about any one company.

Tokens are the meter that runs behind every Claude request, and each tier reads that meter at a different rate.

A token is a small piece of text, often a short word or part of a longer word, that a model reads or writes. Every Claude request is measured in tokens. The tokens you send are called input tokens, and the tokens the model writes back are called output tokens. Providers charge for both, and output tokens usually cost more because the model must produce them one at a time.

The same request, three prices

The same prompt costs different amounts on different tiers, because each tier has its own price per token. The longer your prompt and the longer the answer, the bigger the gap between tiers becomes. To practice the idea, here are made-up prices in imaginary coins per million tokens. They are not real prices. Suppose Haiku charges 1 coin for input and 4 for output, Sonnet charges 3 and 12, and Opus charges 6 and 30. Now take one request with 800 input tokens and 200 output tokens.

For Haiku, the input costs 800 times 1 divided by a million, which is 0.0008, and the output costs 200 times 4 divided by a million, which is also 0.0008, so the total is 0.0016. The other rows use the same steps. Notice that the cheapest and most expensive tiers differ by almost seven times for exactly the same request. This is why token-aware design matters.

The context window

The context window is the maximum number of tokens a model can handle in a single request. Everything has to fit inside it: your instructions, the earlier messages, any documents, your question, and the model’s answer. The size of this window can differ between models and generations, so check the current model page instead of assuming it is the same for all tiers.

Ways to spend fewer tokens on any tier

A prompt is the set of instructions you give the model. Good prompts make every tier better, and they matter most for the smaller ones.

A simple recipe for a strong prompt

Tier-specific tips

Every model, even the largest, has limits. Knowing them early saves you from nasty surprises.

Quick answers to the questions people ask most about Haiku, Sonnet, and Opus.