Routing on Quality, Not Just Cost

The trap of optimizing for cost alone

It's easy to build a routing policy that just picks the cheapest model available and call it optimization. For genuinely simple, low-stakes requests, that's often the right call. For anything where a wrong or low-quality answer has a real cost — a customer-facing response, a decision that feeds into something else — cost-only routing quietly trades a small, visible savings for a larger, less visible quality cost.

What "quality" actually means per task

Quality isn't a single global score — a model that's excellent at creative writing isn't automatically excellent at structured data extraction, and a model that's strong on English reasoning tasks doesn't automatically carry that strength into Arabic-language tasks. Routing on quality means matching the task type to the model that's actually strong at that type, not assuming a single "best" model wins every category.

A practical way to think about it

Rather than treating cost and quality as opposites, treat quality as a floor and cost as the thing you optimize once that floor is met. Define the minimum acceptable quality for a given task type, then route to the cheapest model that clears that bar — rather than routing to the cheapest model available and hoping it clears an unstated bar.

How this plays out in routing infrastructure

This is why routing needs to be a real decision per request type, not a single fixed default. Mizan's Router lets a single API key reach every provider, and its cost-optimization layer specifically targets the cheapest model that still meets quality requirements — not the cheapest model available regardless of fit.