Claude 3 gave the model picker real tradeoffs

Claude 3 was the first time Anthropic’s model picker felt like a real product decision to me instead of a branding exercise.

Before that, “use the best model” was a lazy but understandable default. If the model was going into a serious workflow, you picked the strongest one and absorbed the cost. Claude 3 made that harder to justify because the lineup had meaningful differences around speed, price, and capability.

That is when model choice starts looking like architecture.

haiku, sonnet, opus

The useful part of the Claude 3 lineup was not that the names were cute. It was that the names mapped to different jobs.

Haiku made sense for cheap, fast work where the output could be checked or thrown away. Sonnet sat in the middle, which is often where product defaults live. Opus was the expensive path for work that needed more reasoning, more context, or more tolerance for ambiguity.

That split changed how I thought about AI features. A single “assistant” setting was not enough anymore. The product needed to know what kind of work it was asking for.

The model family also made a quiet point about user expectations. A user does not experience “model lineup.” They experience response time, answer quality, cost limits, and whether the product feels reliable. If the product exposes the choice directly, the labels need to mean something. If the product hides the choice, the routing needs to be good enough that users do not feel tricked.

The worst version is the fake picker: three options with vague adjectives and no operational difference the user can understand. Claude 3 made the picker feel less fake because the tiers had a practical shape. Small and fast. Balanced. Strong and expensive.

That is a product vocabulary, not only a model catalog.

routing before it was fashionable

The obvious routing rule is cost based: send easy tasks to the cheap model and hard tasks to the expensive one. That is a start, but it is not enough.

Some cheap tasks are high risk. A short moderation decision can matter more than a long summary. Some long tasks are low risk. A draft outline can be wrong and still useful. The route should consider ambiguity, reversibility, user impact, and whether a verifier can cheaply catch the mistake.

I would rather route on task shape than on vibes:

cheap path: classification, extraction, rewrite suggestions, cacheable summaries
middle path: user-facing drafts, routine coding help, product support
expensive path: ambiguous reasoning, high-impact decisions, messy multi-step work

None of those buckets is permanent. They need evals. They need cost review. They need a rollback path when the model changes under you.

The important detail is that routing should happen before the prompt becomes overloaded with hidden policy.

If the product needs cheap extraction, choose the cheap extraction route. If it needs careful synthesis, choose the route that can handle that. Do not ask one prompt to secretly mean “be fast unless this is hard unless the user is premium unless the data is sensitive unless the answer affects billing.” That is how prompts become junk drawers.

Model routing deserves structured inputs:

{
  "task": "extract_invoice_fields",
  "risk": "low",
  "latencyBudgetMs": 1500,
  "qualityFloor": "schema_valid",
  "fallback": "retry_with_sonnet"
}

For a different request, the route should look different:

{
  "task": "review_security_architecture",
  "risk": "high",
  "latencyBudgetMs": 20000,
  "qualityFloor": "human_review_required",
  "fallback": "escalate"
}

Those examples are intentionally plain. The product is making an explicit choice instead of pretending the biggest model is the only honest answer.

the hidden cost of a model picker

A model picker creates user agency, but it also leaks complexity. Most users do not want to think about model routing. They want the product to pick a sane default and let them override it when they have a reason.

That means the product team still owns the decision. If the default is too cheap, the product feels flaky. If the default is too expensive, the bill becomes the product roadmap. If the picker is too prominent, users start debugging the model lineup instead of doing their work.

Claude 3 made that tension visible. The model lineup was no longer a ladder. It was a set of tradeoffs.

That is a healthier way to think about models. Less magic. More engineering.

defaults carry responsibility

The default model is a product promise.

If the default is Haiku-shaped, the product is promising speed and cost control. That may be perfect for autocomplete, classification, or quick summaries. It may be wrong for messy planning. If the default is Opus-shaped, the product is promising quality and patience. That may be right for a hard reasoning mode. It may be wasteful for everyday work.

Sonnet-style middle paths are interesting because product defaults often live in the middle. The middle model needs to be good enough that users do not constantly reach for the expensive option, and cheap enough that the product can afford normal use. That is a hard balance. It is also where a lot of AI product design actually happens.

The mistake is treating the default as a neutral technical setting. It is not neutral. It decides what kind of experience most users get most of the time.

I would measure the default by task slice:

• how often users rerun with a stronger model
• how often cheap outputs fail validation
• how often expensive routes produce no accepted improvement
• how latency changes completion rate
• how cost changes feature availability

Those measurements keep the picker honest. Without them, the model menu becomes a place for everyone to project vibes.

vision made the picker less text-only

Claude 3 also mattered because the family handled image input.

That changed the picker from a text-only decision to a broader workflow decision. If the user can upload a chart, screenshot, diagram, or scanned document, the product has to decide which model should see that image and what kind of answer is expected.

Image input is not one task. Reading a receipt is different from interpreting a UI screenshot. Extracting text from a document is different from reasoning about a system diagram. Some image tasks can be verified against structured output. Others require judgment.

That makes routing more interesting:

haiku-like route:
  quick OCR-adjacent extraction where validation is cheap

sonnet-like route:
  screenshot explanation, chart summary, routine mixed-media support

opus-like route:
  ambiguous diagram reasoning, high-impact analysis, messy visual context

Again, the names are less important than the habit. The product should know what kind of work the user is asking the model to do.

the menu is not the architecture

It is easy to confuse a model picker with routing architecture.

A dropdown is an interface. Routing is the system behind it. The dropdown may expose manual control, but the product still needs logs, evals, fallbacks, cost tracking, and policies. Users should not have to debug the model lineup every time an answer is bad.

The product should be able to explain its choice:

used: Sonnet
reason: balanced route for user-facing summary with moderate context
fallback: Opus available if summary fails review

That does not need to be visible all the time. It should exist somewhere, because teams need to understand how model choice affects quality.

Claude 3 made the picker feel real because the options mapped to different work. The next step was making the system around the picker real too.

That is still the part worth caring about.