One Model Is Not the Answer

Picking one model and using it everywhere is an appealing decision. One API, one bill, one set of quirks to learn, one thing to explain to your team. Most projects start that way and it is a reasonable place to start.

It stops being reasonable at the point where you are paying frontier prices to classify an email, or waiting on a slow reasoning model inside a phone call that needed an answer in 400 milliseconds. The single-model choice quietly becomes a tax you pay on every request that did not need what you are paying for.

Multi-model orchestration has become standard architecture through 2026: systems route different tasks to different models based on cost, latency, and capability. That sounds elaborate and is usually just a switch statement with good reasons behind it.

The useful question per task is which constraint actually binds. In a voice agent it is latency, and a faster, less capable model that replies in under half a second beats a smarter one that takes two, because the delay breaks the conversation more than an occasional imperfect answer. In bulk classification it is cost, and a small model at a fraction of the price handling a well-specified task is the right answer at volume. In a hard extraction or a genuine reasoning step, capability binds and you should pay for the best available.

Most systems contain all three shapes of work, which is why one model rarely fits.

The stronger argument for multi-model is not this quarter's cost. It is that the ranking changes. Models we would not have used a year ago are now the obvious pick for particular jobs, and that will keep happening.

So the thing worth engineering is not the choice, it is the ability to change the choice. Keep model selection at a boundary you control rather than scattered through your prompts and business logic. Then swapping a model for one task is a configuration change instead of a refactor.

This is also where a gateway earns its place: one interface, several providers behind it, with fallback when one is degraded. It turns provider outages from an incident into a routing decision.

We pick per task rather than standardising, and we expect to revisit it. On multi-agent systems that often means different models for different agents in the same pipeline, because a data-cleansing agent and a reasoning agent are not doing remotely similar work.

The overhead of doing this is smaller than it sounds, and it is mostly paid once, at the boundary. The overhead of not doing it shows up every month in a bill, or every call in a pause the caller notices.