# Orchestrate, don't operate > The most capable model is the most expensive one to let do grunt work. Put it in the orchestrator seat (planning, steering, judging subagent results) and hand the searching, reading, and typing to cheaper models. - Author: Jonas Rohde (@edhor) - Published: 2026-07-25 - Canonical: https://edhor.me/blog/orchestrate-dont-operate/ - Tags: ai-agents, agentic-coding, orchestration, model-selection, subagents Every now and then a model shows up that is not just a better version of the last one. A new generation of model, a new type of model, with a whole new level of taste and capabilities. But it is expensive: expensive to run and expensive to use. And then nearly everybody does the same thing, me included: you run it exactly like you ran the one before. Same prompts, same single-agent loop, same habits… and a bill that shows up without any of the value the model was supposed to give you. The fix is not rationing it. The fix is putting it into a different seat. ## TL;DR - Don't run a new top model like you ran the old one → same usage, way more cost, similar output - Its value is taste and orchestration, not throughput - Let it plan, write the subagent prompts, read the results and decide what to redo → let cheaper models search, read and type - Run it on medium or at the very most high (the levels above burn your tokens in seconds) - If your tasks are already well defined, _you_ are the orchestrator → skip the layer ## The trap The failure mode is sneaky because nothing looks wrong. You give the best model a task, it does the whole thing itself: greps the repo, reads twenty files, writes the boilerplate, runs the tests, fixes the lint… and the result is good. It's just that most of those steps produced output you can't tell apart from what a model at a fraction of the price would have produced. And you paid the premium rate for all of them. Searching a codebase is not a task that rewards taste. Reading a file isn't. Writing the fifteenth similar handler isn't. The expensive model is not better at any of that in a way you can measure. It's better at deciding _which_ files matter, whether that fifteenth handler should exist at all, and whether the result is actually right. So you paid for judgment and used it for searching and typing. ## Put it in the orchestrator seat The pattern: the strongest model you have holds the goal, writes the prompts for the agents doing the work, reads what comes back, and decides what to accept, redo or throw away. It doesn't do the work itself. Concretely that means telling it to: - use cheaper models for helper tasks → searching, reading, mechanical implementation with a clear spec. This is the single biggest cost cut available - run on medium or at the very most high → the levels above burn your tokens in seconds and in my experience nearly never change the decision it ends up with - also use external agents → if you have more than one agent CLI around, let it drive them non-interactively as workers. That's also the natural place for a [review from a different model family](/blog/dont-look-at-unreviewed-code/) - look at the results, not just delegate → this is what makes it orchestration instead of a routing table That last one is really the whole thing. The value is that it looks at the subagents and their results and steers them, killing a bad approach after one round instead of five. The word I keep coming back to, as weird or humanized as it sounds, is _advisor_. Orchestrator and advisor: it plans, it delegates, it judges, it advises. It doesn't type. ## The important part: tell it explicitly Here is the thing nobody tells you and which cost me real money to learn. Left alone, a capable model will helpfully do the work itself. That's what it's trained for: you gave it a task, it completes the task. It will not spontaneously decide that step four should go to something cheaper. It just gets on with it, competently, at the premium rate, including every search and every helper task on the way. So don't let it take over a complete task itself, incl. searches and all these helper/worker tasks → that's how you burn your tokens. Prompt it to be the orchestrator, explicitly, in the prompt. Without that instruction the whole pattern just doesn't happen, and you only notice it later on the invoice. ## When to skip the layer completely Two-layer setups are not always right, and this is where I think people overbuild. If you are doing a plan + implementation setup (the task is fuzzy, the approach is not settled, somebody has to decide what "done" even means) then yes, take the strongest model for the plan/orchestration agent. That's exactly the shape it is good at. But if you already have well defined tasks, you as the human are basically the orchestrator. You did the decomposition, you know what has to happen, there is no judgment left to delegate. Then the orchestration layer is pure overhead, you are paying a model to forward instructions you already wrote. Call the worker model directly. Keep the review either way. Skipping the orchestration layer means you took over the steering, it doesn't mean the work stops needing a second pair of eyes from another family. ## Why this really cuts the bill Worth being precise about the mechanism, because "use cheaper models" alone is not the insight. The saving is not mainly the price difference between the tiers, even though that's real. It's that most tokens in any bigger task go into exploration: reading files, searching, trying something and backing out again. That's the bulk, and that's exactly the part where the model tier matters the least. The tokens that really need the strong model are a small share: the plan, the judgment calls, the assessment of what came back. Splitting those two groups is where the cost drops a lot, and it drops without the quality dropping → because you didn't downgrade the decisions, only the labour. That's basically the whole idea: use the expensive model only for the parts where its judgment actually shows up in the result.