“Which model is best?” is the wrong question. It assumes there is a single answer, valid for every case, that a leaderboard could settle. In production, that is almost never how it works. You do not choose a model, you route each task to the model that fits it.
Claude models come in several families, from the fastest and lightest to the most powerful. The good practice is not to send everything to the most capable one out of caution, nor to the cheapest one out of thrift, but to match each task to the right profile. Here is how we reason about this model choice for AI in production.
The single-benchmark trap
A benchmark measures average capability across a set of generic tasks. Your production, by contrast, is made of specific tasks: classify an alert, extract a field, write a summary, diagnose a complex incident. The top model on a general leaderboard may be oversized for half of them, and the fastest one may be enough where you thought you needed power.
Trusting a single benchmark leads to two opposite mistakes: paying for a heavy model on trivial tasks, or handing a light model a piece of reasoning beyond it. LLM routing is about avoiding both, task by task.
Three task profiles, three answers
Fast, high-volume triage
Many tasks are simple, repetitive and massive: classify, filter, route, extract a well-defined piece of information. They run into thousands of calls, and what matters is latency and unit cost, not reasoning depth. This is the ground of the fastest and most economical family, Haiku. A light model, tightly framed by a precise prompt, handles these cases in a fraction of a second and for a fraction of the cost.
The everyday production task
Between the two extremes sits the bulk of real work: writing a structured answer, calling tools, following a multi-step procedure, producing correct code. These tasks need a good balance of quality, speed and cost. This is where the middle family, Sonnet, belongs. It now reaches near top-tier quality on code and agentic tasks without the cost of the most powerful model. For most agents in production, it is the reasonable starting point.
Long reasoning and hard cases
That leaves the tasks where quality comes before everything: a multi-source diagnosis, a long analysis, a complex plan of action, a chain of reasoning that must hold across many steps without losing the thread. There, the most capable model, Opus, earns its cost. You enable deeper reasoning, give it the time and tokens it needs, and reserve that use for the cases that truly deserve it.
A fourth criterion runs through all three profiles: latency. An interactive assistant, where a human is waiting live, does not tolerate the same response times as a background job run overnight. At equal quality, a faster model improves perceived experience as much as it cuts cost. So routing weighs three axes at once: the difficulty of the task, its volume, and its response-time requirement.
Routing is not a one-time choice
Routing is not a fixed decision made at startup. It is a logic that runs on every task. The same agent can triage an alert with a fast model, then, if the case turns out to be complex, escalate to a more powerful one for the diagnosis. You route by the nature of the task, not by a global preference.
That escalation requires recognising early that a task exceeds the current model. This is a design criterion in its own right, on par with those of a good evaluation framework: you only route well what you can measure. Without measuring quality per model and per task type, you route on intuition, which amounts to not routing at all.
One caveat, though: a prompt tuned for one family does not always carry over unchanged to another. Swapping a model on a route means re-checking its behaviour on real cases, like any other change in production. Treat the routing table itself as versioned configuration, not a constant.
Routing as a cost and quality lever
Well routed, a fleet of agents costs a fraction of what it would cost if everything went through the most powerful model, at equal perceived quality. It is one of the most effective levers of FinOps for agentic AI: the right model in the right place cuts the bill without the user noticing.
Because all of these models are available on Amazon Bedrock, routing happens within a single foundation, with the same governance and traceability, which makes it practical to operate. This discipline fits within our industrialisation method: choosing the model is not a one-off setting, but a design decision, measured and revisable.
Do you want to tune the cost and quality of your AI services by routing your models better? Let’s talk.