Choosing a Model

Model choice is the single largest lever on cost, latency and quality, and it is not a one-off decision: new generations arrive, old ones are retired, and the right answer differs per route in your application. The exam tests the tier trade-offs, the naming conventions, and the discipline of evaluating before switching.

The three tiers

Claude ships in three families that trade capability for speed and price:

Tier	Strength	Typical use
Opus	Highest reasoning and agentic capability	Complex coding, multi-step agents, hard analysis
Sonnet	Balanced capability, speed and cost	Most production workloads, coding assistants, RAG
Haiku	Fastest and cheapest	Classification, routing, extraction, high-volume simple tasks

Within a generation, every tier shares the same API and the same input types, so you can swap models by changing one string. Across generations, parameters sometimes change (for example how extended thinking is configured or whether sampling parameters are accepted), so a model change is a code change that needs testing. Current IDs, context windows, maximum output lengths and prices are on the models overview page at docs.anthropic.com; do not rely on remembered numbers.

IDs, aliases and snapshots

A model is addressed by its ID string in the model field. Anthropic publishes two forms: a dated snapshot (a fixed version that never changes) and an alias (a shorter name that points to the latest snapshot of that model). Aliases are convenient for development; production systems that need reproducibility should pin a snapshot and upgrade deliberately. Cloud platforms use their own identifier formats for the same models.

Query what is available programmatically rather than hard-coding:

for m in client.models.list():
    print(m.id, m.display_name, m.created_at)
info = client.models.retrieve(MODEL)   # includes capability and limit fields

for await (const m of client.models.list()) console.log(m.id, m.display_name);

A 404 not_found_error on model means either a typo or a model your organisation cannot access; the Models API shows what you can use.

A selection process

1. Start with the most capable model to establish what "good" looks like on your eval set.
2. Step down a tier and re-run the eval. If quality holds, you have found a cheaper option.
3. Route by difficulty. Use a small model to classify and handle easy cases, escalating hard ones to a larger model (the routing pattern from lesson 1-2).
4. Tune effort before changing model. On models that support an effort or thinking setting, lowering it often saves more than switching tiers, while keeping one prompt cache.
5. Measure cost per completed task, not per request. A cheaper model that needs retries or more turns is not cheaper.

Capabilities that differ by model

Check the model page for: context window size, maximum output tokens, whether extended thinking is supported and how it is configured, vision and PDF support, which beta features are available, and the minimum cacheable prompt length. Long-context models let you avoid retrieval for medium-sized corpora, but long inputs cost more per request and increase latency, so retrieval still wins at scale.

Extended thinking in brief

Newer models can reason before answering. Older generations expose this as thinking: {"type": "enabled", "budget_tokens": N} with a fixed budget below max_tokens; the current generation uses adaptive thinking (thinking: {"type": "adaptive"}) and an output_config.effort level from low to high and beyond. Thinking tokens are billed as output tokens. Thinking is valuable for maths, planning and hard coding, and wasteful for simple extraction. Read the extended thinking page for the exact parameters your target model accepts; sending the wrong form returns a 400.

Deprecation and migration

Models are announced as deprecated with a retirement date, after which requests fail. Subscribe to the deprecations page, pin snapshots so you are never surprised by silent behaviour changes, and keep your eval suite ready so migration is a measured exercise: run the suite on the new model, compare pass rate, token usage and latency, then flip traffic gradually. Token counts can differ between generations because tokenisers change, so re-baseline cost estimates with count_tokens on the new model.

Exam focus

• Opus is the most capable, Sonnet balances quality and cost, Haiku is fastest and cheapest; the right tier depends on the task and should be verified with an eval.
• Aliases point to the latest snapshot; dated snapshots are fixed. Pin snapshots in production.
• client.models.list() and retrieve() show the models your organisation can use and their limits; a 404 on model means unavailable or misspelled.
• Routing easy requests to a small model and escalating hard ones is the standard cost pattern.
• Extended thinking configuration differs by model generation and is billed as output tokens.
• Treat model upgrades as code changes: re-run evals, re-measure tokens, and migrate before the retirement date.