14 Models, One Budget: LLM Routing in Practice

Last Sunday afternoon I sat looking at my AI usage dashboard and clicked the downgrade button on my main subscription, from the biggest plan down to one a quarter its size. Not because I stopped using it. Because I set a new target: the monthly AI bill had to get much smaller.

Then I traced where that money actually went, and found something I could not laugh off. The system runs 14 language models. Flagship models I talk to every day, and a tiny 0.6B model humming quietly on a cheap server. Some work hard around the clock. Some were configured once and never called again. It was a house with every light left on, and a single electricity bill. You cannot know which bulb burns the money until you walk the rooms one by one.

This article is the walk. The full model map, which jobs go where, the rules that decide, and three lessons from the teardown that anyone paying for AI through several channels at once can probably use today.

Part 1How many LLMs, and what does each one do?

Fourteen models, in four tiers by where the money comes from: flat-rate subscriptions already being paid, local models that run for the cost of electricity, GPUs rented by the hour, and pay-per-use APIs. Fourteen sounds like a lot, but the count is not the point. The point is that every model must answer two questions: which tier it sits in, and which kind of work it takes.

Inside the subscription tier the Claude models split the work again. The top model (Fable, Anthropic's tier above Opus) is the orchestrator: the team lead that plans, breaks the work down, and assembles the results. The next tier down (Opus) takes problems that need deep thought at specific points. The mid tier (Sonnet) is the main workforce, fast at well-specified jobs. The smallest (Haiku) handles the sweep-and-check chores that recur every few hours. Codex plays the grinder teammate: hour-long coding runs you hand over and review when they are done.

The smartest model should not do the most work. The opposite: it should do the least, because its minutes are the most expensive. Its job is to think and delegate, not to type. That principle is the heart of the whole tier map.

Part 2Which job goes to which model?

Shortest version: human-facing work gets the best model, machine-to-machine work gets a mid-tier model, high-volume low-stakes work gets a free one. The rest is detail in three rules.

Rule 1: Human-facing work never gets downgraded

Text a person will read, documents used for decisions, and anything touching money always run on the subscription tier. No exceptions. We tried letting a lower-tier model write to humans once; you could tell instantly it was not the same league. A saving that lowers the quality of the work people actually see is not a saving.

Rule 2: Climb the ladder from what is already paid for

The order is existing subscriptions first, then local, and only last pay-per-use. The reasoning is plain. A subscription costs the same whether you use it or not, so filling its quota is free capacity. Local models take unlimited volume but are clearly lower quality, so they get the work that can afford a miss. Pay-per-use comes last, and in our system it requires asking first, because it is the only channel where cost can balloon with no ceiling.

Rule 3: Have an automatic fallback, and see it fire at least once

Our automation chains fallbacks: if the primary model is down or the quota runs out, work moves to the next standby on its own, with an alert sent to us. The system never goes silently dead; quality just dips for a while. The part that matters: test the chain until you have seen it fire with your own eyes. A backup switch that has never been flipped is the same as no switch.

Part 3Three lessons from the real teardown

Lesson 1: What is configured is not what is running

During the teardown I planned to move the recurring sweep jobs onto a small model to save money. When I checked what the running system actually had in memory, it was already on the small model; someone had moved it earlier. The config line I had been reading was one the system never parses, written in the wrong format from day one. Some switches turn on the light because the wiring is real. Others click fine and are connected to nothing. From the wall they look identical; you have to trace the wire. Lesson: do not trust the config file, ask the running process what values it is actually using.

Lesson 2: The money burner is context, not call count

Before measuring, I assumed the fix was fewer model calls. Seven days of real numbers (440 calls) said otherwise: tokens spent re-reading conversation context outweighed tokens spent writing answers by roughly 80 to 1. Long-running conversations were the cause; every new message re-reads the whole history. The longer the thread, the quieter and steeper the cost. The fix that worked was not a different model but shorter conversation rounds: cap dropped from 30 messages per round to 12, with the system starting each new round carrying a summary of the old one. Trade long memory for a cost you can see.

Lesson 3: Measure before you cut, the suspect is usually wrong

I was sure the server-side automation was the big quota eater, and the whole savings plan rested on that belief. Pulling per-account usage showed the automation was on its own account and eating modestly; the heavy user was the interactive work I run myself every day. Had I cut on belief, I would have degraded the system and saved nothing. One look at the meter is cheaper than a month of cutting in the wrong place.

Part 4How to start on your own system

You do not need 14 models to start. Two is enough. The order that works:

1. Build a model registry. List every model and AI service you pay for or run, three columns: name, where the money comes from, and the work it takes. Any row that cannot fill column three is your first suspect.
2. Measure a real week before changing anything. Find out what the tokens actually go to. Ours went to re-reading context; yours may differ, but know it from numbers, not from feel.
3. Draw the quality floor. Write down which work must never be downgraded. Everything below that line is candidate work for cheaper models.
4. Change one thing at a time, and prove each switch fires. Every time you move work to a new model or add a fallback, test that it actually gets called. Do not trust the config file (lesson 1 is waiting).

What you get back is more than a smaller bill. You get to know what every unit of AI spend is doing, and once you know that, every next decision gets easier: a new model slots into an obvious tier, and a budget cut has an obvious place to land that does not hurt.