AI Without the Hype.
Chapter 2 of 17
Part One · Don't Trust One Pass · Chapter 02

OpenRouter and
multi-model

By the end of this chapter you understand what a single key to many models buys you, and you can pick the cheapest model whose output you would actually ship instead of defaulting to the biggest one.
AVATAR OPENER · ~90s
Watch: one key, many models, and how to choose between them
HeyGen avatar · generated, consistent presenter

Last chapter ended with a promise: a real council needs genuinely different models, from different labs, arguing over the same question. This chapter is how you get them. The short version is that you do not sign up for five separate services and juggle five bills. You get one key that reaches almost all of them.

That key is OpenRouter. It is a single account with a single API that routes your request to whichever model you name, from most of the major labs, through one consistent interface. You put a little credit on it, you get a key, and from then on asking a model from one lab or a model from another is a one-word change. That is the whole unlock, and it is what makes the multi-model council from the last chapter something you can actually run instead of just admire.

But the key is the easy part. The real skill in this chapter is not wiring. It is judgment: knowing which model to reach for, and resisting the pull to always grab the biggest one.

Loyal to one model
You pick a favourite and run everything through it. Simple decisions and hard ones get the same expensive brain, and you never see how another model would have failed differently.
Result: one bill, one blind spot, and usually overpaying.
VS
Right model per task
One key reaches them all. You route the cheap, high-volume work to a cheap model and save the expensive brain for the work that needs it. And you can convene a real council.
Result: lower cost, more perspectives, and a choice you can defend.
The right model is the cheapest one whose output you would actually ship. Bigger is not a strategy. It is what people reach for when they have not set up a way to tell whether smaller would have been fine.

That line is worth sitting with, because it is the opposite of how most people choose. The instinct is to always use the most capable model, on the theory that more is safer. But most of what you send a model is not hard. It is classifying, extracting, tidying, drafting a first pass. Handing all of that to the biggest, slowest, priciest model is like couriering every letter by taxi. It works, and it quietly costs you a fortune while being slower than it needed to be.

THE LADDER

Every lab sells roughly the same three rungs, under different names: a small fast one, a balanced middle one, and a big deep one. The names change constantly and they are not worth memorising. What matters is the shape and how you climb it.

Start cheap
Run the task on the small, fast, cheap model first. For a lot of real work, its answer is already good enough to ship.
Judge the output
Not "is it impressive" but "would I actually send this". If yes, you are done, and you just saved money and time.
Climb only if needed
Only when the cheap answer genuinely falls short do you step up to the middle model, and only then to the top one.

You climb the ladder from the bottom, not the top. Start with the cheapest model that could plausibly do the job. If its output is something you would actually put your name on, stop. You are finished, and you spent almost nothing. Only when the cheap answer genuinely is not good enough do you step up a rung. Most people do this backwards: they start at the top out of anxiety and never come down, because they never checked whether they needed to be up there.

HOW YOU KNOW: A SMALL EVAL

Here is the move that turns that discipline from a vibe into something real. Before you commit to a model for a recurring job, you build a tiny test. Not a benchmark, nothing formal. You take twenty or thirty real examples of the actual task, run the same task through two or three models, and lay the answers side by side. Now the choice is not a guess. You can see which model is good enough and pocket the difference in cost.

You do not need to write code to think this through. Here is a prompt that helps you design the eval for one of your real recurring tasks. The runnable version, the one that actually calls several models through your OpenRouter key and scores them, lives in the companion repo under council/. You clone that repo in the terminal chapter later; for now, this is how you decide what to even test.

Design a model eval
I run this task over and over: [describe the recurring task, e.g. "turn a messy voice note into a clean three-line summary"]. Help me build a small, honest eval to choose the cheapest model that is good enough for it. 1. Ask me for 20 to 30 real past examples of this task, or help me assemble them. 2. Tell me the two or three things that make an output "good enough to ship" for this specific task, in plain terms I can check. 3. Lay out how I would run the same examples through a cheap, a mid, and a top model and compare, so the decision is evidence, not a guess. Do not tell me to just use the biggest model. The point is to find the floor, not the ceiling.
Try it in Claude

What you get back is a scoring sheet you can actually apply. Run it once and you have a real answer for now: this job is fine on the cheap model, that one really does need the top tier. It is a snapshot, not a permanent verdict, so for anything where a single miss is costly, spot-check a sample now and then and re-run the test when your inputs or the models change. Multiply that across the ten tasks you do most, and you have a routing map, cheap models doing the bulk, the expensive brain saved for the few things that earn it.

What a routing map looks like
Cleaning up voice notes: cheap model. Indistinguishable from the top one on 28 of 30 examples. Drafting client replies: mid model. The cheap one missed tone twice in ways I would not send. The final go / no-go call on a contract: top model, and still my eyes after. This is the one worth paying for.
THE HONEST COSTS

Two things the excited version of this chapter would skip, so here they are plainly.

Speed is a real cost
Bigger models are slower. For anything interactive or high-volume, latency is not a footnote. The cheap model being three times faster often matters more than a small quality edge.
You pay per use
No subscription, you buy credit and spend it per request. Freeing, but it means a sloppy loop can burn real money fast. Watch what your automated jobs actually cost.
Trust moves outward
Your prompt now leaves your Claude account and goes to a third party and onward to a lab. That is a different privacy surface. OpenRouter lets you restrict which providers ever see your data. Use it.
Names go stale weekly
The exact model IDs and prices change constantly. Never hardcode "the best model" by name in your head. Keep the eval habit and re-check the current lineup when it matters.

The privacy one deserves a beat, because it is easy to get burned. On a paid Claude plan your prompts sit under one company's terms you already accepted. Route through OpenRouter and the same prompt can pass through several labs, each with its own terms. In practice you will send your real work through these tools, everyone does, and pretending otherwise would be dishonest. The move is not to hold back, it is to know it is happening and use the one control that matters: the setting that limits which providers your prompt can reach. Ask Claude where it lives on today's version, point it at providers you are willing to trust, and get on with the work.

NOW YOU TRY · ANALYZE
Build a routing decision for one real task

Take one task you already hand to AI regularly, the kind you do most weeks. Use the eval-design prompt above. Be honest about what 'good enough to ship' means for that specific task, in checkable terms. Then decide, on the evidence you would gather, which rung of the ladder it actually needs. The win is catching one task you have been overpaying for, or one you have been under-serving.

Right if you can name a task where the cheapest good-enough model is not the one you have been using, and you can say how you would prove it with real examples.
Show the worked solution
The drill lands when you catch yourself overpaying. Say the recurring task is "summarise each morning's client emails into a short list of what needs a reply today." Your instinct, and probably your habit, is to run it on the top-tier model, because it is important. Design the eval honestly and "good enough to ship" turns out to mean three things: it never misses an email that actually needed action, it does not invent urgency that is not there, and the summary is short. Those are checkable. Gather twenty real past mornings, run them through a cheap model and a top one, and compare against what you actually did that day. Very often the cheap model matches the expensive one on exactly those three checks, because triage is not a hard reasoning task, it is a sorting task. If it does, you move that daily job to the cheap model and stop paying top-tier prices for it, every single morning, forever. That is the whole point of the ladder: the important-feeling task and the expensive task are not always the same task, and the only way to know is to look at real examples instead of guessing. Contrast that with the one genuine judgment call in your week, deciding whether to take on a difficult client, where the eval would show the top model earning its price. Same person, same key, two different rungs, each one chosen on evidence.
WATCH FOR
✗You always reach for the biggest model. That is anxiety, not strategy. Start at the bottom of the ladder and only climb when a real example proves you need to.
✗You choose a model by its reputation or its launch hype. Reputation is not your task. Twenty of your own real examples beat every leaderboard for deciding what works for you.
✗You forget the prompt now leaves your trusted tool. Routing to many labs means many privacy terms. Send only what the task needs and restrict providers for anything sensitive.
✗You hardcode "the best model" by name. The names and prices churn weekly. Keep the eval habit instead, and re-check the current lineup when the stakes are real.
WHAT YOU LEARNED
The takeaways
  • OpenRouter is one account and one key that reaches most major models from most labs, which is what makes a real multi-model council practical.
  • The core discipline: the right model is the cheapest one whose output you would actually ship, not the biggest one you can reach.
  • Climb the ladder from the bottom. Start on the cheap fast model, judge the real output, and step up only when it genuinely falls short.
  • A tiny eval, twenty or thirty of your own real examples run across a few models, turns model choice from a guess into evidence you can point at.
  • The honest costs: bigger is slower, you pay per use so loops can burn money, and your data now crosses into third parties, so use the provider controls.
Your project · the routing map

Take the one recurring task you run most, and design its eval with the prompt above. You do not have to run it for real yet, that waits for the terminal chapter and the companion repo. But decide now which rung it should sit on, and start the routing map for your real work. Next chapter turns the review habit into a discipline: two loops of review, and why the second reviewer catches what the first one could not.

Reaching for the biggest model every time feels responsible and is usually just expensive. The operator move is quieter: find the cheapest model that clears your bar, prove it on your own examples, and spend the difference on the decisions that actually deserve the best.

← Chapter 1: The AI Council Next → Chapter 3: Two loops of review