Why I'm Bearish on Model Routers

Valentin De Matos explains why model routers - systems that route requests to cheaper or specialized LLMs to cut token costs - fail to gain traction in interactive coding. Token spending is real and can be huge, but engineers prioritize speed, quality, and minimal friction over marginal cost savings because they don't directly pay those bills. Engineers also develop mental models of each LLM’s strengths and weaknesses and adjust prompts and workflows accordingly; routers obscure which model is being used, removing that corrective leverage and adding a trust overhead that can cost more time than it saves. Manually choosing a preferred model is one click; trusting an opaque router that occasionally produces worse diffs is not.

Routing looks more plausible for fully autonomous “software factories” that run background agents at scale, but those systems either come bundled with routing from vendors or are built in-house by teams that want control. Factories collect richer outcome data - test results, PR merges, bug reopenings - that a standalone router cannot see, letting owners tune model selection to their codebase and business trade-offs. Because model selection ultimately resides with whoever owns the loop (engineer in interactive use, factory in background work), independent model routers lack a natural place to own or justify that layer, leading to a bearish conclusion on their broad usefulness.