Meet the Claude family

Every project that uses Claude starts with the same decision, and most teams make it badly: which model? The instinct is to reach for whatever is cheapest and "upgrade later if needed" — which quietly caps the quality of everything you build on top of it, because you never find out what the task looks like when it works. This lesson gives you the map, the naming system, and a decision procedure that runs in the right direction.

How the lineup is organised

Claude models come in capability tiers, and each tier gets versioned over time. As of mid-2026, the current generation looks like this:

Claude Fable 5 (claude-fable-5) — the most capable widely released model, built for the hardest reasoning and long-horizon agentic work. Thinking is always on, single requests on hard tasks can run for many minutes, and it carries additional safety measures for dual-use capabilities. Priced above the Opus tier, and it requires 30-day data retention — organisations on zero-data-retention agreements cannot call it at all.
Claude Opus 5 (claude-opus-5) — the workhorse frontier model for complex agentic coding and enterprise work. This is the default choice for anything intelligence-sensitive: multi-file refactors, agents, deep analysis.
Claude Sonnet 5 (claude-sonnet-5) — near-Opus quality on coding and agentic work at a lower price and latency. The high-volume production tier.
Claude Haiku 4.5 (claude-haiku-4-5) — the fast, cheap tier for simple, well-specified tasks: classification, routing, extraction at scale.

The Claude model family: capability and cost rise left to right, speed and volume headroom rise right to left

Two things about the names are load-bearing. First, the model ID is an exact string — claude-opus-5, not claude-opus-5.0 or a guessed date suffix. A wrong ID is a 404, and constructing IDs from memory is the single most common integration bug. Second, current-generation IDs are aliases without date suffixes, which means they are stable strings you can put in config; older models used dated IDs like claude-haiku-4-5-20251001.

The numbers that drive architecture

Three properties of a model shape your system design more than anything else: the context window (how much you can send in — 1M tokens on the current Fable/Opus/Sonnet models, 200K on Haiku 4.5), the max output (128K tokens on the frontier models, 64K on Haiku), and the price per million tokens, which differs roughly 2× between adjacent tiers (as of mid-2026: Opus 5 at $5 input / $25 output per million tokens, Sonnet 5 at $3/$15, Haiku 4.5 at $1/$5, Fable 5 at $10/$50). Prices and models change — treat the ratios as the durable lesson and check the pricing page before quoting numbers in a budget.

Notice the asymmetry: output tokens cost roughly five times input tokens. That single fact explains a lot of production behaviour you will meet later in this course — why verbose responses matter to your bill, why prompt caching targets input, and why controlling output length is a first-class cost lever.

Two operational facts complete the picture. Rate limits are per-model-family buckets measured in requests and tokens per minute, and they grow with your usage tier — a route that works in development can throttle at launch traffic, so check your tier's headroom before shipping, not after. And models have a lifecycle: they launch, get superseded, get deprecated with notice, and eventually retire with a documented replacement. A model ID in production is a dependency like any other pinned version — subscribe to the deprecation notices and plan migrations on your schedule instead of the calendar's.

Choose by starting high, not low

The reliable procedure is the opposite of the cheap-first instinct:

1. Prototype on the most capable model you can afford — for most teams that is Opus. You are answering the question "can Claude do this task at all, and what does great output look like?" A failure on the top model means rethink the task; a failure on a small model means nothing.

2. Freeze a set of real examples with known-good answers. Twenty is enough to start. This is your evaluation set, and it is the only honest way to compare models.

3. Downshift route by route. Run the same examples on Sonnet, then Haiku. Wherever quality holds, take the cheaper model for that route. A production system rarely uses one model — it uses Haiku for the router, Sonnet for the bulk path, and Opus for the hard cases.

This ordering matters because model choice is reversible and evidence is cheap. The teams that get stuck are the ones who tuned three months of prompts around a small model's failure modes and can no longer tell which limitations are real.

Discover models at runtime, not from memory

The API can tell you what exists and what each model supports — context window, output cap, and feature support — so capability checks belong in code, not in a wiki page that goes stale:

python

import anthropic

client = anthropic.Anthropic()

m = client.models.retrieve("claude-opus-5")
print(m.display_name, m.max_input_tokens, m.max_tokens)

for model in client.models.list():
    print(model.id)

If you build anything that lets users pick a model, drive the list from this endpoint. Hardcoded model lists are the second most common integration bug, and they fail in the worst way — silently, months later, when a model is deprecated.

What to take into the next lesson

A model is not a brand choice; it is a point on a capability–latency–cost surface, and your system will end up using several points at once. Start high to learn the ceiling, keep a small evaluation set so "good enough" is a measurement rather than a feeling, and treat model IDs and capabilities as data your code fetches rather than facts it remembers. Before touching the API, though, the next lesson maps something most developers never see laid out: every surface Claude ships on, and how to pick the right one for each job.