Fifty posts arguing for routing by concept should end with the argument against routing at all, made as well as we can make it. If it cannot survive that, it is not worth the fifty.
The case
One model, always, is simpler and getting cheaper.
Frontier model prices have fallen repeatedly and substantially. Every price cut narrows the gap a router arbitrages, and the trend has been in one direction for years. Optimising against a cost difference that is closing is building machinery whose value decays.
A router is a component that can be wrong. Without one, a request goes where it goes. With one, there is a classifier that can misclassify, a policy that can be misconfigured, a filter that can be too strict, and a fallback chain that can refuse something a single model would have answered. You have added a distributed system to a function call.
Model choice is not where your quality comes from. Prompt, context and evaluation dominate. Teams with a router and no evals are optimising the cheap variable while the expensive one is unmeasured — and the router makes that easier to avoid noticing, because it feels like engineering.
It is a coupling to today's model landscape. Concepts, tiers and residency labels encode a snapshot. When the models change shape — longer contexts, better small models, different pricing units — the taxonomy needs revisiting, and taxonomies are expensive to revisit.
Most products do not have the problem. One kind of work, one model, no constraint. For them everything here is overhead with a maintenance cost.
That is a good case. For a large majority of products it is correct, and anyone choosing a single model and spending the saved effort on evaluation is making a defensible decision that we would not argue with.
Where it fails
Three conditions, and all three have to hold.
A rule that must never be broken for a subset of work. Not "we prefer" — must not. Residency, a data boundary, a model an auditor has approved. That is not a cost optimisation and no price cut makes it go away, because it was never about price.
Enough distinct kinds of work that one policy is wrong for some of them. Summarising a document and reviewing a migration that rewrites ledger entries are not the same request, and treating them identically means either over-spending on one or under-serving the other.
A need to explain, afterwards, why a specific request went where it did. Not aggregate reporting — this request, on Tuesday, and what it was not allowed to use.
If all three hold, "one model always" does not degrade gracefully. It fails at the third: the answer is that everything goes to one model, which is either compliant for all traffic or for none.
If any is missing, the case against stands.
What we would concede
That the cost argument is the weakest reason to adopt a router, and the one most often used to sell one. It is real today and shrinking.
That the classifier is a component that can be wrong, which is why it fails open to a default concept whose constraints still apply — but a fall-through is still a request routed on less information than intended.
That we cannot serve moneypath.verify at all right now, because the
in-infrastructure model it requires does not exist. The constraint holds, the
requests are refused, and that is a product with a hole in it rather than a
subtle trade-off.
And that if you have one kind of work and one model, you should stop reading and go and write evals.
What we would not
That explainability is a nice-to-have. The difference between a system that refuses a money-path request and one that quietly serves it from a vendor model is invisible in the response and total in the consequence. Whatever mechanism prevents that has to be structural, because a policy nobody can check on a Tuesday is not a policy — and that is the thing we think is worth building, independent of whether it also saves money.