Blog
/
Engineering

Why we route on quality,not price.

ML
Maya Lindqvist
CTO at Northwind Labs (guest)
September 30, 2026
·
7 min
read

When our inference bill passed our payroll, the obvious fix was to route every request to the cheapest model that could answer it. We tried that for a week. Costs fell, and so did the answers.

The wrong objective

Cost-first routing optimises a number your customers never see. The number they do see is whether the answer was right. So we turned the problem around: set the quality bar first, then let cost break the tie.

Routing policy results on 1,800 support conversations with a 0.92 quality bar: one model costs 1.00 with quality 0.94 and passes; cost-first routing costs 0.31 with quality 0.83 and fails; a 0.92 quality threshold costs 0.38 with quality 0.93 and passes.

Setting the bar

We scored 1,800 real conversations with a rubric our support leads wrote, and picked 0.92 because that is where complaints stopped. The router config is four lines.

router:
  model: auto
  quality: 0.92
  fallback: [open-70b, frontier-xl]
“We expected a migration. It was a config change.”

What happened to the bill

Costs fell 62% against the single-model baseline in two weeks, while quality stayed above the bar. Most requests never needed the frontier model; the ones that did still got it.

What we would do again

Write the rubric before you pick a model. Version the test set like code. And put cost second, where it belongs.

ML
Maya Lindqvist

CTO at Northwind Labs. Runs the platform team behind their support assistant.