Every request to a language model is a small purchase. You pay for the capability you need and, more often than you'd think, for capability you don't. Routing is how you stop paying for the second kind.
Two questions, in order
A router answers two questions for every request. First: which models can do this task at all? Second: of those, which one costs least? The order matters. Start from price and you send hard work to models that can't do it, and the savings disappear into retries, reviews and repairs.
So we treat the first question as a gate, not a score. A model that can't handle the tool format, context length or streaming behavior a request needs is out, however cheap it is. Only the models that pass the gate compete on price.
A low score can't make an incompatible route safe. Hard requirements stay hard.
What qualifies means
Qualification has two layers. The first is mechanical: does the route support the shape of the request? Tool calls, streaming, context size, account policy and available funding are yes-or-no checks. They cost almost nothing to run, and they rule out the worst failures before any money is spent.
The second layer is quality: is this model good enough at this kind of task? That is where measurement comes in. We run models on task sets drawn from real work, such as code changes, research questions, writing and long agent runs. A model qualifies for a kind of task when its results hold up across those runs, not when it wins one benchmark prompt.
Most work is ordinary
Sort a team's requests by how demanding they are and the pattern is usually lopsided. Much of it is routine: summaries, small edits, lookups, formatting. A smaller part needs deep reasoning or long context. A router that sends everything to the strongest model pays premium prices for routine work.
The opposite mistake costs just as much. Send a multi-file repair to a model that is only qualified for small edits, and you pay for the attempt, the failure and the second attempt. Cheap is only cheap when it works.
Keeping the roster honest
Models change every few weeks. New ones arrive, prices move, and existing models are updated behind the same name. A routing table that was right last month can be wrong today.
So the roster is never finished. New models earn their place by running the same task sets as the models already in it. Existing models are tested again when they change. A route that slips is demoted until it earns its place back.
Where this runs
This approach runs in MUSCLE Flex, our routing API. You send a request to one endpoint. Flex checks what the task needs, excludes routes that can't meet it, and chooses a qualified route for speed, reasoning, tools and cost. The same method shapes the systems we build for clients, where the routing rules come from their own tasks.