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 an easy default. If the model was going into a serious workflow, you picked the strongest one and swallowed the cost. Claude 3 made that harder to defend because the lineup had meaningful differences in speed, price, and capability.

That is when model choice starts looking like architecture.

the lineup stopped being decorative

The useful part of the Claude 3 family was not the naming. It was the fact that the tiers mapped to different jobs.

Haiku made sense for cheap, fast work that could be checked or thrown away. Sonnet sat in the middle, which is where a lot of 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 picker also made user expectations more honest. A user does not experience “model lineup.” They experience response time, answer quality, cost, and whether the product feels reliable. If the product shows the choice, the labels need to mean something. If it hides the choice, the routing needs to be good enough that users do not feel tricked.

The fake picker is easy to spot. Three options with vague adjectives and no operational difference is just theater. Claude 3 felt more real because the tiers had a practical shape: small and fast, balanced, strong and expensive.

routing is a design choice

The obvious 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 catch the mistake cheaply.

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, cost review, and a rollback path when the model changes under you.

The important part is that routing should happen before the prompt becomes a junk drawer of hidden policy. If the product needs cheap extraction, choose the cheap extraction route. If it needs careful synthesis, choose the route that can do 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.”

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 plain on purpose. The product is making an explicit choice instead of pretending the biggest model is the only honest answer.

the middle model matters

The default model is a product promise.

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

Sonnet-style middle paths matter because product defaults often live there. 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 balance is hard, and it is where a lot of AI product design actually happens.

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

Without that, the model menu just becomes a place for everyone to project vibes.

vision widened the choice

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

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

the menu is not the system

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 part worth caring about was the system around the picker.