Why one model for everything is the wrong answer
Making a frontier model reason over an entire repository just to rename a variable is wasteful. Letting a cheap model design a database migration is dangerous. Most teams still pay the top price for every task, no matter how trivial.
This is exactly what model routing addresses. Instead of using one model for every step, you split the work: the most expensive, smartest model plans. A cheaper, faster model executes. The planner thinks, the executor types. At IJONIS in Hamburg we run this pattern daily, across both client and product projects.
"A large model over an entire repository is wasteful just to rename a variable. A cheap model is dangerous when designing a migration." — the core principle of model routing, settled into practice in 2026
This separation is not a gimmick. It follows a principle I have seen confirmed again and again in agentic coding: code has become a commodity. The scarce skill is no longer writing it, but thinking in systems and architecture. Model routing pours that exact insight into a workflow. The architect and the builder are two different roles. They do not need the same person, the same model, or anything like the same price per hour.
How the split actually works
A standard agent running the reason-act-observe pattern calls the big model after every single step to decide the next one. Across twenty steps, that is twenty expensive reasoning rounds, most of them mechanical.
The planner-executor split breaks this work into three clearly separated phases. Each phase has its own role, and each role gets the model that fits it on price and skill. Here is how it runs in practice:
- Planning phase. A high-reasoning model reads the request, understands the repository, and breaks the goal into an ordered list of steps. It writes no code. It thinks and plans.
- Execution phase. A smaller, faster model takes the plan and works through it step by step. It makes no architecture decisions. It implements what has already been decided.
- Review phase. A third, independent model reads the finished code against the plan and flags deviations. It catches silently introduced errors before they reach production.
A concrete example: adding an invoicing module
A concrete example from practice: you want to add an invoicing module to your existing software.
- The planner (say Claude Fable 5 or Opus 4.8) reads the code, recognizes the data models, plans the new table, the Application Programming Interface (API) endpoints, the validation, and the tests. Output: a clean twelve-step plan.
- The executor (say Claude Haiku 4.5, a Generative Pre-trained Transformer (GPT) 5.6 Codex, or a local model) implements steps one through twelve. Each step is small, clearly defined, and no longer needs deep intelligence, just clean execution. Recurring patterns like Create, Read, Update, Delete (CRUD) fall in here too.
Why this is cheaper
Almost all the expensive tokens land in the planning phase, and that phase is short. The many mechanical execution tokens run through the cheap model. A typical feature build splits roughly into one quarter planning and three quarters execution. That ratio is exactly what you route across two price tiers.
The numbers: how much does the split really save?
According to production reports, model routing can cut cost by 40 to 85 percent depending on the split. The range depends on how much traffic you move to the cheap model. The more mechanical execution you hand to the cheap tier, the larger the saving, as long as quality holds. The figures below come from published production and benchmark data from 2026.
Concretely, according to 2026 production reports: a conservative 10/90 split saves 8 to 10 percent, a moderate 50/50 split saves 40 to 49 percent, and an aggressive 80/20 split saves 64 to 79 percent. The RouteLLM benchmark reached 85 percent cost savings at 95 percent of the quality of a pure frontier setup. In a multi-agent setup where a planner orchestrates a team of executors, routing the execution turns to a cheap model like Haiku can save over 50 percent more on the execution load, according to analysis from digitalapplied.
That sounds like a clear win. It is not always.
The honest part: when the split loses
The planner-executor split is no cure-all, and this is where this article parts ways with most. In a careful benchmark by Akita on Rails, the forced split lost almost across the board to a single strong model. On tightly connected coding tasks, delegating to a weaker model measurably costs quality, and the planner itself burns so many tokens that the hoped-for saving disappears.
"A strong planner plus a cheap executor loses to Opus alone." — Fabio Akita, 2026 coding benchmark
According to Akita's 2026 results, a single Opus model scored 97 out of 100 at 18 minutes and around 4 dollars. The table below shows the split variants from the same benchmark, with model names updated to the current generation.
Source
All figures in this table come from the coding benchmark by Fabio Akita, 2026.
The exact numbers shift with each model release, but the pattern holds unchanged across generations. Two lessons sit in that table. First: if you force a model to delegate to a weaker one when the task is tightly connected, you lose quality. Second: the hidden planning cost is real. When Opus manually orchestrated a cheap model to hold full quality, total cost tripled because the planner itself burned so many tokens.
The hidden planner tax
Planning is not free. A frontier model reasoning through a whole plan burns expensive tokens itself. If your task is small and tightly connected, the overhead of planning is larger than the saving on execution. The split only pays off above a certain size and decomposability.
The decision rule: split or solo?
When is routing worth it, and when not? The answer hangs on a single question: can the task be cleanly broken into independent steps? If yes, the split wins almost every time. If no, because each step depends on the one before it, a single strong model is the better choice. The comparison below makes the decision quick.
Vorteile
- Large features with many mechanical steps
- Repeatable work (boilerplate, CRUD, writing tests)
- Clearly bounded, independent sub-steps
- High volume, where token cost becomes noticeable
- Migrations and refactors with a clear target picture
Nachteile
- Small, tightly connected tasks (planner overhead eats the saving)
- Tasks with strong dependencies between steps
- Creative architecture decisions that need reasoning throughout
- Debugging, where each step depends on the previous finding
- One-off, small changes
As a rule of thumb: the larger and more mechanical the task, the more the split wins. The smaller and more interlocked, the more a single good model wins. For a mid-market company that means: building a new module or running a migration is worth routing. The quick bugfix on a Friday afternoon is not.
How to set up the split in practice
You do not have to build a system for this. Several tools ship the split ready to use, and you can start with any of them in minutes. These three routes have proven themselves in practice:
- Aider architect mode. Aider has long separated a strong model for planning from a separate editor model for implementation. You name two models, Aider handles the split.
- Claude Code with subagents. A main model plans and delegates clearly bounded sub-tasks to cheaper subagents. We run this daily at IJONIS, steered through structured instructions in a project file (
claude.md). - Router layer. Tools like LiteLLM or an AI gateway route requests automatically by difficulty across different models. This fits when you push many different tasks through one system.
Do not skip the quality gate
The most expensive mistake in routing is silent quality regression: the cheap model ships worse code for weeks, and you only notice when the errors pile up. Test every new split against 50 to 500 real cases before you raise the cheap model's share. An independent review model that checks the output closes the gap.
The clean chain reads: frontier model plans, cheap model executes, independent model reviews. Three roles, three price tiers, one result.
What this means for your business
Model routing is not a technical trick for developer teams alone, it is a business decision. You pay for intelligence only where intelligence is needed, and for execution only the execution price. For a mid-market company that means predictable cost at the same output quality, without paying frontier prices for every trivial change.
The mistake I see most often: companies pick one model, usually the most expensive, and send everything through it. That is like having your chief architect pull cables. He can do it, but you are paying the wrong price for it.
The real skill is not knowing the best model. It is breaking the task down correctly and matching each step to the right model. That is exactly the loop engineering discipline. It is also the core of what an AI orchestration layer delivers in a company, as covered in the AI orchestration guide: not one model for everything, but the right model for each step.
Frequently Asked Questions About Model Routing
What is model routing in AI coding?
Model routing means sending different tasks to different AI models instead of pushing every single request through one expensive model. In coding, a strong, expensive model plans the task, and a cheaper model executes the plan step by step. You pay top prices only for the thinking, not for the mechanical implementation.
When is the planner-executor split worth it?
The split pays off on large, decomposable tasks with many mechanical steps, such as database migrations, large refactors, or building entirely new modules from scratch. On small, tightly interlocked tasks or fast debugging, a single strong model usually wins, because the planning overhead eats the saving.
How much does model routing save?
Teams report savings between 40 and 85 percent depending on how much execution traffic they move to the cheaper model. A moderate 50/50 split cuts cost by roughly 40 to 49 percent, an aggressive 80/20 split by 64 to 79 percent. The RouteLLM benchmark reached 85 percent savings at 95 percent of the quality of a pure frontier setup.
Does the split always lose quality?
The split does not necessarily lose quality, but it can lose several points when you apply it to the wrong kind of task. Forcing delegation on connected tasks drops quality by five to seven points. With a quality gate and an independent review model, quality stays stable. The key is to use the split only where the task breaks cleanly into steps.
Which tools support the split?
Several established tools ship the split ready to use out of the box, so you do not have to build a routing system yourself at all. Aider ships an architect mode with separate planner and editor models. Claude Code delegates through subagents. Router layers like LiteLLM or an AI gateway distribute requests automatically by difficulty. For a first test, Aider with two models is enough.
If you want to know where in your development and business processes this split pays off and where it does not, talk to us. We build exactly these workflows, on the bleeding edge of what agentic tools can do today.
