Model Routing in 2026: Stop Picking a Model, Start Picking Per Task

Most systems pick one model and send everything to it. That was defensible when models differed a lot in capability. After a month of measuring fifteen configurations on identical tasks, it isn't.

Two findings make routing worth building:

1. On ordinary verifiable work, capability has converged. Everything from Grok 4.5 at $2/$6 to Fable 5 at $10/$50 passed the same hard battery.
2. Which model is cheapest depends on the shape of the task, and the ranking genuinely inverts.

If capability is flat and cost varies 17×, routing is just picking up money.

The ranking inverts — this is the whole argument

Grok 4.5 and Gemini 3.6 Flash have crossing rates: Grok is $2.00 in / $6.00 out, Gemini is $1.50 in / $7.50 out. Gemini is cheaper on input, Grok on output. So whichever side dominates decides the winner:

Same two models, both correct on every task, opposite rankings. There is no "best cheap model" — only the best model for a token mix. Any router that ignores that leaves 2–4× on the table in one direction or the other.

Routing rules, with the measurements behind them

Input-heavy → cheap input rate. RAG, summarization, classification, document extraction: you send a lot and get back a little, so the input rate dominates. Gemini 3.6 Flash won every input-heavy task we measured.

Output-heavy → cheap output rate, and prefer terse models. Code review, generation, long-form analysis. Grok 4.5 won these, partly on rate and partly because it's unusually concise — 286 output tokens where Claude Opus 5 used 1,440 for the same three answers. Verbosity varied 6× across our models and routinely exceeded the rate difference between tiers.

Hard output constraints → route on measured adherence, never on price. Gemini Flash went 20/20 on a strict-format check; Claude Opus 5 went 13/29 at roughly ten times the cost. This axis is inverted against price. If a downstream parser depends on format, measure the pass rate and route on that number.

Currency-sensitive → grounded search. Anything whose answer changes over time. Perplexity Sonar answered post-cutoff questions correctly at $0.0002 — cheaper than most ungrounded models we tested. Grounding here is the correct tool, not a premium one.

Genuinely frontier-difficulty → the expensive models, but prove it first. Our battery is single-turn and cannot measure long-horizon agentic work, which is what the flagship benchmarks measure and what those models are sold for. That's a real category. It's just much narrower than most routing tables assume — nothing in a month of testing required it.

Four harness failures you must handle regardless

Routing multiplies your exposure to per-provider quirks. All four of these bit us in production this month.

1. Refusals return HTTP 200. Safety classifiers decline with stop_reason: "refusal" and an empty content array. We hit this asking Claude Opus 5 to review a function containing a SQL injection — refused three times out of three. Your retry logic won't catch it because nothing failed. A router needs an explicit refusal branch that falls through to another model.

2. Reasoning models return the answer behind a thinking block. Read content[0] and you get an empty string on any prompt hard enough to trigger reasoning. Three distinct causes produce an identical-looking empty response, each needing a different fix.

3. The same error has different status codes per provider. An oversized prompt returns 400 from Anthropic, 429 from OpenAI, and 403 from Groq. The 429 is actively dangerous — every SDK retries it by default, so an unfixable request becomes an infinite backoff loop. Normalise errors on message content, not status.

4. Host choice can exceed model choice. Kimi K3 is served by Together and Fireworks at an identical $3/$15. Fireworks was exactly 2.00× faster. Same weights, same price. For open-weight models the host is a routing decision in its own right.

Building the router

Classify by token shape, not by task name. "Summarization" isn't a routing category — long input, short output is. Estimate the ratio from real traffic and route on that.

Measure on your own prompts. Every number here came from our tasks. Verbosity is workload-dependent; a model that's terse on our code review may be wordy on yours.

Instrument cost per usable output. Not cost per call. A model that fails your validation 30% of the time costs 1.43× its sticker price once you retry — and the worst retry tax we measured was on the most expensive model, at 2.11×.

Sample enough to trust the routing decision. We measured 26% run-to-run cost variance on identical prompts, and got two different constraint scores from the same weights on two hosts. If your A/B gap is under about 25% on a single run, you haven't measured anything yet.

Keep a fallback path warm. Between refusals, rate limits and provider outages, single-model routing has a failure mode that multi-model routing simply doesn't.

Try it yourself

• The extraction task — input-heavy, no account needed

To measure token shape and cost across candidate models on your own prompts, that's Promptster.

Every measurement referenced here comes from runs conducted 2026-08-04 to 2026-08-11 via the Promptster API at max_tokens: 4000, reported in the linked posts. Costs are computed from list pricing against actual token usage. Latency figures are comparable within a post but not across posts. This article contains no new measurements — it's the routing argument the earlier data supports.