Claude 3 gave the model picker real tradeoffs

Claude 3 made the model picker feel like architecture instead of branding.

The useful distinction was practical: Haiku for quick and cheap work, Sonnet for a broad default, Opus for harder or more ambiguous tasks. The names mattered less than the fact that the tiers had different operating costs and different jobs.

That makes model selection a product decision. Users experience latency, quality, price, and reliability. A menu with three vague adjectives is theater. A menu whose options change those outcomes needs routing behind it.

I would route on task shape rather than one global “best model” setting:

cheap:
  classification, extraction, rewrite suggestions, cacheable summaries

middle:
  user-facing drafts, routine coding help, product support

expensive:
  ambiguous reasoning, high-impact decisions, messy multi-step work

The categories need evaluation. A short moderation decision may be high risk even if it is cheap to generate. A long outline may be low risk and easy to discard. Reversibility, ambiguity, user impact, and verifier cost all belong in the route.

The route can be explicit:

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

Or it can escalate:

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

That is more honest than hiding every policy inside a prompt that says to be fast unless the work is hard unless the account is important.

The middle model deserves special attention because product defaults usually live there. It needs to be capable enough that users do not constantly upgrade the request, and affordable enough for normal use. I would measure it by reruns, validation failures, latency, accepted output, and cost rather than by preference polls alone.

Claude 3 also widened the route beyond text. Image input created separate choices for OCR-adjacent extraction, screenshot explanation, chart summaries, and ambiguous diagram reasoning. Those are not one visual task, and they do not necessarily deserve the same model.

The picker is only the visible part. The system still needs logs, fallbacks, cost accounting, evals, and a way to explain why a route was chosen:

used: Sonnet
reason: balanced route for a user-facing summary
fallback: stronger model if review fails

Claude 3 mattered because its lineup mapped to recognizable work. The durable lesson is to make those tradeoffs explicit and test them against the tasks the product actually serves.