Here is a bill most teams pay without noticing. You pick a good model, wire it into your agent, and then run every single step through it: the hard reasoning, and also the trivial "is this a bug report or a feature request" classification that a far cheaper model would nail. You are paying frontier prices for grunt work, on every call, forever.

LLM model routing is the fix. The idea is simple: instead of one model for everything, you send each task to the cheapest model that can do it well. The hard part is not the concept, it is drawing the line without quietly degrading quality. This is how to do that.

What model routing actually is

A router is a small, fast decision that sits in front of your models. For each unit of work, it asks one question: what is the least expensive model that will get this right? Simple, well-defined tasks go to a small cheap model. Genuinely hard tasks go to your best one.

The economics are lopsided in your favor because model prices are lopsided. Within a single provider's lineup, the cheapest tier and the most capable tier can differ by more than 10x per token, and across the market the gap is wider still. So every task you can safely move down a tier is a large, permanent saving, not a rounding error.

Route by the kind of task, not the vibe

The reliable way to route is by task category, because categories map cleanly onto difficulty. A rough division that holds up in practice:

Cheap-model work. Classification, extraction, formatting, short summaries, yes/no checks, and turning structured data into prose. These are pattern tasks. A small model (in the Claude lineup, Haiku is the example) handles them at a fraction of the cost, and you will struggle to tell the output apart from a frontier model's.

Expensive-model work. Multi-step reasoning, writing or refactoring real code, planning a change across files, and anything where a subtle mistake is costly. This is where a top model (Opus, or Sonnet as a balanced middle) earns its rate.

The mistake is routing by gut feel per request. Route by type of step instead, decided up front, so the behavior is predictable and testable. An agent doing real work runs many small steps, and most of them are the cheap kind.

How much it actually saves

The public numbers here are striking, and worth stating with the caveat that model rates move, so verify the current ones before you quote them. Analyses of production routing report that a large majority of tasks, often cited in the 60 to 80 percent range, can be served by a model many times cheaper than a frontier model, while overall quality holds. Reported cost reductions from routing land in the high double digits.

You do not have to take those figures on faith, and you should not. The point is the shape: if most of your steps are cheap-model work, and the cheap model is an order of magnitude less expensive, your blended cost per task drops sharply even though the few hard steps still cost what they cost. Measure it on your own traffic rather than trusting a headline percentage.

How to build a router without overbuilding it

Start with the simplest thing that works, and only add machinery when it pays for itself.

Rule-based routing first. Tag each step in your pipeline with its category (classify, extract, plan, implement, judge) and map categories to models in config. This is boring, transparent, and it captures most of the savings on day one. You can read the routing table and reason about it, which matters when a bill spikes.

Add signals only if you need them. If a single category has a mix of easy and hard cases, you can add a lightweight complexity estimate (input size, presence of code, number of files touched) to split it. Some teams train a small local classifier for this. It is rarely worth it until the rule-based version is clearly leaving money on the table.

Escalate on low confidence. The safety valve that makes routing safe: when the cheap model is uncertain, or its output fails a downstream check, retry the step on a stronger model. You pay the premium only on the cases that need it, and you stop the cheap model from confidently shipping a wrong answer. Pair this with a hard ceiling on retries so escalation cannot itself become a runaway, which is its own topic in capping runaway agent spend.

Where routing fits with the other levers

Routing is one of a small set of levers that compound. It pairs naturally with prompt caching, which cuts the cost of the repeated context each model sees, and with moving the latency-insensitive work to a batch pipeline for a further discount. Routing decides which model; caching and batching cut what that model costs to run. Together they move the blended number far more than any one of them alone. The full picture is in the economics of AI coding agents.

The honest limitation

Routing has a real failure mode, and pretending otherwise is how teams get burned. When you send a task to a model that turns out not to be good enough, the failure is rarely loud. You do not get an error. You get an answer that is subtly worse: a missed edge case, a plausible but wrong detail, a tool call that silently does the wrong thing. Those are more expensive than the tokens you saved, because they surface later, in production, where they are hard to trace back to "we routed that to the cheap model."

So routing is not free savings, it is a trade you have to instrument. You need evaluation on the cheap-model paths to catch quality drops, and the escalation valve to recover when they happen. Without those, aggressive routing is just a slower, cheaper way to ship bugs. With them, it is one of the highest-leverage cost decisions you can make.

There is also a maintenance cost. Model lineups and prices change, new tiers appear, and a routing table tuned a year ago can be leaving obvious savings unclaimed or, worse, sending work to a model that has since been outclassed. Treat the routing config as something you revisit, not set once.

This is a lever we expose deliberately in Loopsfinity: the model used for each kind of step is configurable, so the cheap work runs cheap and the hard work runs on your best model, on your own account. How we tune that split is our own work. The principle, and the escalation discipline that keeps it honest, is yours to apply to whatever you are building.