Who picks the model?
Last week I ran a single task that touched four different models. I chose exactly one of them. That’s a bigger change than it sounds like, and we haven’t really named it yet.
When I started with ChatGPT it was my only model. One box, one answer. Then we got a lot of models – different providers, different sizes, different prices, and wildly different costs for what often turned out to be a similar answer. Running a small bootstrapped lab, matching the work to the model started being real money. Cheap models for the easy stuff, expensive models for the hard stuff.
There are two main ways we’ve been picking a model. The first is model routers. OpenRouter and similar. You send a request, a small classifier looks at it, decides what kind of task it is, and maps it to a model based on your tradeoffs and their data. Swap models without touching your code, get automatic fallback when a provider falls over.
The second is orchestration. A capable model runs the job and delegates: it writes the plan, then hands implementation to one subagent, review to another, research to a third. It picks the model for each based on the work and whatever instructions you’ve given it. The expensive model does the delicate thinking and farms out everything else.
This is where the payoff is. Every big task has a pile of work that doesn’t need a frontier model. Things like simple research, writing tests for code that already exists, turning a diff into a changelog entry. The current Artificial Analysis cost-per-task numbers span about 137x, from the cheapest model on the board to the most expensive. Same benchmark, same work, two orders of magnitude apart on the bill. Even at my scale that’s the difference between running four experiments a month and running ten.
The rate isn’t the only savings either. A subagent that reads fifty files and hands back a paragraph keeps all of that out of the main context. Otherwise it rides along on every turn for the rest of the run.
I use orchestration for almost everything now. Routers I keep around for fallback and load balancing.
The usual explanation is that orchestration just fits agentic workflows better. That’s true, but it’s more than that. The real reason routers lost the interesting half of this job is information position.
A router decides at the request layer. It sees one prompt, in isolation, and has to infer what kind of work it is. An orchestrator decides at the task layer. It doesn’t have to infer anything because it wrote the plan. It knows this subagent is doing a mechanical file rename and that one is untangling a race condition, because it decided that thirty seconds ago.
Routers aren’t losing on technology. They’re losing on position. A classifier guessing the task from a prompt is reconstructing something the orchestrator already has.
So what’s left for routers is everything that doesn’t need to know the task: rate-limit failover, provider outages, price arbitrage, burning down a committed contract, regional availability, deterministic policy. That’s real, and I’d argue it’s permanent. But it’s infrastructure. The decision moved up a layer.
The interesting part is that model choice used to be a configuration decision. You made it once, deliberately, somewhere you could see it. Now it’s an inference decision, made a few hundred times a day, by a model, mid-run, on your behalf. And the simple question I still can’t answer is: what did that task cost? Not what did I spend this month, that one’s easy. What did that one job cost, once you add up four models across two harnesses, each with its own token efficiency and its own cache behavior. I don’t have a clean way to get that number, and I’d bet most people don’t either.
Do you pick your models, or does something else pick them for you? Could you tell me what your last big agent run actually cost? And do you think we get more specialized from here or does this all flatten out into one big model?
