What do the Haiku, Sonnet, and Opus tiers mean in Claude's model line-up?

## The naming scheme Anthropic names Claude models after poetry forms of increasing length, and the ordering is deliberate: a haiku is short, a sonnet is medium, an opus is a large work. Every Claude generation has shipped some subset of these three tiers, so a full model name combines the tier with a generation number — the family reads as "Claude <tier> <version>". Interviewers use the tier names as shorthand for a position on the cost/capability ladder, so knowing the ordering (Haiku < Sonnet < Opus) is the floor. ## What actually differs between tiers **Capability.** The larger tiers are better on tasks with a long chain of dependent steps: multi-file code changes, ambiguous instructions, subtle reasoning, long agentic loops where one early mistake compounds. On easy, well-specified tasks — classify this ticket, pull these five fields out of this invoice, rewrite this sentence — the gap narrows sharply or disappears. This is the single most important nuance: the tiers are not "bad, okay, good", they are points on a curve whose spread depends entirely on task difficulty. **Latency.** Smaller models emit tokens faster and start responding sooner. For anything user-facing and interactive — autocomplete, inline suggestions, a chat that must feel instant — latency often decides the tier before capability does. **Price.** Pricing is per million tokens, quoted separately for input and output, and the rate climbs with the tier. The gap between the smallest and largest tier is typically several-fold, which is why a workload that runs millions of cheap calls is usually economically impossible on the top tier and trivially affordable on the small one. **Response-length ceilings.** The maximum number of output tokens you may request in one response varies by model, so swapping tiers can change the ceiling on how long a single answer can be. Check the ceiling for the specific model you are moving to rather than assuming it carries over. ## What does NOT differ The API surface is the same. Same endpoint, same request shape, same SDK client, same authentication, same streaming events, same tool-use and vision support in the current generation. That is a design decision with a practical consequence: a tier swap is a configuration change, not a rewrite. It also means you can A/B two tiers behind the same code path and compare outputs on real traffic. Context window is also not a tier ladder — the current tiers share the same standard window, so "I need to fit more text, therefore I need Opus" is a false inference. ## How the choice is actually made in production The naive pattern is to pick one model for the whole application. The professional pattern is to pick a tier **per step**, because most real pipelines are a mix of trivial and hard work. A support-triage system might use the small tier to classify the incoming message, the small tier again to extract the order id, and the large tier once to draft the reply to a genuinely complicated complaint. The cost profile of that system is dominated by the cheap calls and its quality is dominated by the one expensive call. The decision procedure that survives interview scrutiny is: 1. Start on the middle tier to get the task working at all, because it is the cheapest way to find out whether the task is even feasible. 2. Build a small held-out evaluation set of real inputs with known-good outputs. 3. Try the smaller tier against that set. If accuracy holds, downgrade — you have just cut cost and latency for free. 4. Only escalate to the top tier for steps where the eval demonstrably fails on the middle tier, and where the failure actually costs you something. Every arrow in that procedure is justified by measurement rather than intuition, which is exactly what an interviewer is listening for. ## Common traps Defaulting to the top tier "to be safe" is the most expensive mistake teams make, and it also makes the product slower, which users notice. The inverse mistake — forcing everything onto the small tier to save money — shows up as quiet quality regressions in the hard 5% of traffic that nobody eyeballs. Both mistakes come from treating the tier as a global constant instead of a per-task decision backed by an eval set. A second trap is assuming tier names carry across vendors. Haiku, Sonnet and Opus are Anthropic's naming only; other providers use entirely different schemes, and a "small model" from one vendor is not price- or capability-comparable to another's by name alone.