There is an obvious way to pick a model for a virtual try-on: score every candidate on quality, cost and latency, weight the three, and take the winner. It is obvious, it is easy to tune, and it is wrong.
What a weighted score actually does
A weighted score lets a model buy its way past a quality problem. Cheap enough and fast enough, and a model that mangles one face in twenty still wins the average. The failure is invisible in aggregate — the mean score looks fine — and extremely visible to the one shopper who uploaded their photo and got a stranger back.
Averages are the wrong instrument here. A try-on is not a batch job whose quality you can amortise. It is a single image, shown to a single person, once.
Two stages instead of one
So the router runs in two stages, and the first has nothing to do with cost.
A model joins the routable pool only by clearing a quality benchmark. That is a pass/fail gate: clear it and you are eligible, miss it and no amount of cheapness gets you in. Cost and latency are then optimised within the pool that already passed.
The ordering is the whole point. Optimising for cost first and checking quality afterwards means the check is a filter on work you already did badly.
What it costs us
Being honest about the trade: this is more expensive than the weighted version, sometimes noticeably. A cheaper model that would have won on a blended score sits out entirely, and we pay for a better one instead.
It also means a provider's price cut does not automatically change our routing. The cut matters only once that model is in the pool, which requires the benchmark, which requires an evaluation run. Good news arrives slower than it would otherwise.
We think that is the right way round. The alternative is a routing table that quietly gets worse every time someone launches a cheap model.