Published benchmarks say how models do on someone else's prompts. The only measure that matters to an application is how each model does on its own traffic, and that is something a router can learn because it sees every request and can be told how the answer went. The loop is simple to state: route, observe the outcome, update the estimate, route again. The design questions are what to learn from, how fast to move and how to keep exploring.
Each target starts with a quality prior - the router's initial estimate, from declared capabilities and benchmarks - which outcomes then move. Several learners run side by side because they answer different questions. A contextual bandit learns which target wins for which signals and balances exploiting the current best against trying others. A pairwise preference model learns from comparisons - this target beat that one on the same request, as a fallback produces naturally. An item-response model separates a target's ability from a request's difficulty, so a hard request answered badly costs less reputation than an easy one. A sequence model learns which target tends to follow which in multi-step work.
Outcomes arrive in several forms and all of them count: an explicit success flag or quality score reported through the feedback endpoint, a correction or a retry, a parse failure caught by the output guard, a fallback that one target forced and another resolved. The savings ledger and the rankings on this site are read from the same evidence, so what the router prefers and what it reports are the same numbers.
Learning never overrides policy. Hard constraints are applied before scoring, so a learner cannot drift traffic to a target a data-boundary or budget rule forbids; rules keep their weight; and exploration is bounded so a new target earns traffic gradually. The learned state is persisted - a file, Redis or SQL - so a restart does not forget, and calibration reports check that the router's confidence matches how often it was right.
