The Claude Model Family and Selection Criteria

Model selection is one of the few decisions that touches cost, latency, quality, compliance and platform availability at once. The exam does not test memorised prices or release dates, which change too often to be examinable; it tests whether you understand how the tiers differ, which criteria drive the choice, and how to keep the choice reversible.

The tiers

Anthropic ships models in named tiers that have held stable across generations:

Tier	Design point	Typical production role
Haiku	Fastest and lowest cost	Classification, routing, extraction at volume, worker agents, real-time UX
Sonnet	Balance of capability, speed and cost	Default for most production workloads, coding, conversational agents
Opus	Most capable in general availability	Orchestrators, complex reasoning, hard coding tasks, final-quality drafts

From time to time a frontier tier above Opus is released with additional access, pricing or data-retention conditions. Treat such models as a distinct category: confirm eligibility, retention requirements and feature differences in the docs before designing around them.

Within a tier, successive versions improve capability and often change behaviour: how prescriptive a prompt needs to be, how thinking is configured, whether features such as assistant prefill or forced tool choice are still supported. Model IDs are versioned; the Anthropic docs list current IDs, context windows and output limits. Do not hard-code assumptions from memory into architecture documents.

Selection criteria

Work through these in order for each route in your system, not once for the whole system:

1. Task difficulty. Does the task require multi-step reasoning, nuanced judgement or long-horizon planning? Those favour higher tiers. Deterministic transformation and classification tolerate smaller tiers.
2. Quality bar and cost of error. A legal summary and a sentiment tag have different tolerances. The eval set defines the bar; the model must clear it.
3. Latency budget. Interactive paths need low TTFT; smaller tiers and lower effort help. Offline paths can use the strongest model in batch.
4. Cost envelope. Estimate tokens per task and multiply. Remember that agentic routes multiply tokens by turns.
5. Context and output limits. Long documents or long generations need models whose limits accommodate them; check the Models API or docs.
6. Feature support. Thinking modes, effort levels, structured outputs, specific server tool versions, compaction, and platform-specific availability vary by model. A feature your design depends on must be supported on the model and platform you pick.
7. Compliance constraints. Zero data retention eligibility, residency and inference-location options can exclude certain models.

Discover, do not assume

The Models API returns, for each model, its context window, maximum output tokens and a capabilities list. Use it at deployment time to validate configuration, and in dashboards to show what each route is running on:

m = client.models.retrieve(model_id)
print(m.max_input_tokens, m.max_tokens, m.capabilities)

Token counting also matters across generations. Tokenizers change between model families, so the same prompt can be a different number of tokens on a new model. Re-baseline with the token counting endpoint when you migrate; a cache minimum or a context budget calibrated on the old model may no longer hold.

The professional selection process

1. Prototype on the most capable model in general availability with default settings. This finds the ceiling.
2. Build the eval set while prototyping, from real inputs.
3. Try the same model at lower effort. On recent generations this often holds quality on routine tasks and avoids the cache fragmentation of running several models.
4. Try the next tier down. Accept only if the eval passes and production monitoring is in place to catch regressions.
5. Consider routing: a small classifier directing easy traffic to a cheaper tier and hard traffic to a stronger one. The router's accuracy becomes a quality risk you must also evaluate.
6. Record the decision and its evidence. Model choice will be revisited at every deprecation.

Aliases, pinning and deprecations

Model aliases that point to the latest version of a tier are convenient for experimentation and dangerous in production: behaviour can change under you. Pin an explicit version in production, run your regression suite against new versions, and migrate deliberately. Anthropic publishes deprecation notices with retirement dates; the model lifecycle lesson in the stakeholder domain covers the migration process. Design for migration from day one by keeping model IDs in configuration, never scattered through code.

Multi-model systems

Mixing tiers is normal: a strong orchestrator with cheaper workers, or a cheap classifier in front of an expensive specialist. Be aware of two costs. Prompt caches are scoped per model, so a cascade forfeits cache reuse across its stages. And every additional model is another eval set, another migration path and another set of behavioural quirks to document.

Exam focus

• Know the Haiku, Sonnet and Opus design points and typical roles; frontier tiers may carry extra access and retention conditions.
• Selection is per route, driven by task difficulty, quality bar, latency, cost, limits, feature support and compliance.
• Start with the most capable model, build evals, then step down effort before stepping down tier.
• Use the Models API and token counting to discover limits and re-baseline rather than assuming from memory.
• Pin versions in production, keep model IDs in configuration, and treat aliases as a development convenience.
• Mixing tiers is normal but fragments caches and multiplies evaluation and migration work.