Expensive to Decide, Cheap to Do
31 Jul 2026We stopped putting the same model behind every agent this week. The expensive one decides what to do now, and a cheaper one does it.
Here’s the setup. We run a pipeline for fixing bugs: one agent investigates and works out what’s actually broken, a second writes the fix, a third reviews it. My instinct had been to put the best, most expensive model behind all three. Better model, better output, at every step. Right?
Not really.
The reflex
The default is to reach for the frontier model and reach for it everywhere. When the work matters you want the best, and the best costs the most, so you pay it at every step and then wince at the invoice. We do this without thinking about it: the model is good, the model is expensive, the work is important, therefore the model goes everywhere the work does.
It feels like rigor. It’s the opposite. It’s declining to make a decision about where the quality actually has to come from, and paying top price to avoid having to.
What you’re paying for
The hard part of that bug pipeline is the reasoning. Working out what’s broken, and how to approach it, is the whole game. Once that call is made, writing the fix is comparatively mechanical: you know what the change is, you just have to make it.
So the frontier model earns its price in exactly one of those steps. The investigator has to hold the whole messy problem in its head, form a theory, and be right. The engineer downstream is working from a decision that has already been made. One of those jobs is judgment. The other is closer to typing.
Judgment is the thing you’re paying the premium for. That’s what the frontier model is actually good for, and it’s the part a cheaper model can’t reliably do: not faster keystrokes, not cleaner prose, the call about what to do. So put the expensive model where the call gets made, and let a cheaper one carry that call out once it exists. Expensive model to decide what to do, cheap model to do it.
You already do this with people
This is the same call a good manager makes every day. You don’t put your most senior engineer on every line of code. You put them where the consequential decisions get made, the architecture, the nasty diagnosis, the design everything else hangs off of, and you let the rest of the work flow to the people it fits. Nobody calls that cutting corners. It’s just how you run a team that has a range of skill and a range of cost.
Running one model behind every agent is the equivalent of putting your principal engineer on the ticket queue because they’re the best you’ve got. It isn’t rigor. It’s a failure to delegate, and it costs the same way that one does.
Where it goes wrong
The whole split depends on one thing being true: that by the time the cheap model gets the work, the hard thinking is genuinely done. If the fix still involves real decisions, tradeoffs the investigator didn’t resolve, ambiguity about the right approach, then that step was never mechanical, and a cheaper model will make worse calls cheaply. That’s the false economy. Not paying too little for the work, but mis-drawing the line between deciding and doing.
So the question to ask of each step isn’t “Can I get away with a cheaper model here?” It’s “Has the judgment already happened?” Where the answer is yes, go cheap and don’t flinch. Where it’s no, you haven’t found a place to save money; you’ve found another decision, and decisions are the thing the expensive model is for.
Get that line wrong and you haven’t saved anything. You’ve automated bad judgment at a discount.
Keeping the decision upstream
You catch most leaks at review, and they have a specific look. An execution failure shows up as a bug: the code doesn’t do what the plan said. A leaked decision doesn’t. The code runs, it’s defensible, and it’s just not the approach you would have taken. When you or the reviewer keep disagreeing with the cheaper model’s choices rather than catching its mistakes, the judgment didn’t happen upstream. It happened downstream, in the model you picked because it wasn’t supposed to be deciding anything. Surprise at how well the work came out is fine. Surprise at what it chose to do means you drew the line in the wrong place.
Catching it at review is the safety net, though. The real fix is upstream, in what the investigator hands down. Its job isn’t to point at the bug and stop; it’s to produce a plan concrete enough that the next model has nothing left to decide. Which file, which approach, which cases to cover, what not to touch. When the investigator can’t get past a vague description of the problem, that’s the signal in itself: the thinking isn’t finished, and a cheaper model downstream is the last thing that’s going to finish it.
The cheaper model also needs somewhere to go when the plan doesn’t survive contact with the code. It should implement what it was handed and stop and flag the problem if the plan turns out to be wrong, rather than inventing a fix on its own. A frontier model can decide mid-task, because deciding is what you’re paying it for. A cheaper one told to “figure it out” will figure something out, and now there’s a real decision sitting in your codebase that nobody actually made. That escape hatch back up to the expensive model is what keeps a small ambiguity from hardening into a confident wrong turn.
Same models, different bills
The people who get real leverage out of these tools and the people who just get a big invoice are, more and more, the same people running the same models on the same problems. What separates them is that one group has worked out which single step actually needs the expensive brain and put it only there.
That skill isn’t technical. It’s an old management skill wearing new clothes: knowing which decisions are worth your best person’s time, and letting everything else run cheaper. If you can staff a project, you already know how to staff a pipeline.
So look at yours. Where are you paying frontier prices to carry out a decision that was already made?