Four roles, one frontier hire
Most jobs in a planning pipeline do not need a frontier model. Picking the right one per role saves an order of magnitude. One job earns the splurge.
The bill that doesn’t add up
Open a planning pipeline’s spend report and the first thing you notice is that most of the money went into rooms where nobody had to think very hard. A round of interviews with the user about what they want. A walk through an existing codebase to map what is already there. A panel of judges scoring a finished plan against a rubric. Honest work, but not the kind of work that needs the most expensive model on the market.
The second thing you notice is that the most expensive model on the market is what you used anyway, because that is what everyone uses. The default in this industry is to wire a frontier model into every step and let the bill arrive.
I went through my own planning pipeline asking a different question. Not “which model is best”, but “which model is least wrong for this job, at the lowest price I can get away with”. The answer turned out to be four different models for four different roles, and the most expensive one only shows up in one of them.
Four roles, four jobs
The pipeline runs four kinds of work, and the work is not the same. I will give the roles generic names so the architecture does not leak, but the jobs are real.
The first is the Interviewer. It runs a back-and-forth with the user to elicit requirements, one question per turn. The transcript grows every turn, so the model reads more and more of the same conversation. The capabilities that matter are sticking to format (“one question, then wait”) and reading cheaply. Reasoning helps pick the next question. A code-trained model would be wrong here, because code models tend to lose their conversational poise. On the pipeline as it stands, gemini-3.5-flash sits at the head, with minimax-m3 and qwen3-235b-a22b-thinking behind it on the failover chain.
The second is the Cartographer. It reads an existing codebase and maps the patterns, the integration points, the shared abstractions. The capabilities that matter are code comprehension and the largest context window money can buy, because a whole repo has to fit in one mouthful. This is the one role where a code-tuned model is an asset rather than a liability. The chain runs minimax-m3, then deepseek-v4-pro, then qwen3-coder, all three at one-million-token context so a failover never drops into a model that cannot fit the codebase.
The third is the Designer. It looks at what the Interviewer learned and what the Cartographer mapped, and it decides how the work should be built: the architecture, the abstractions, the pitfalls to head off. It runs once. Its mistakes propagate into every downstream task. The capability that matters is the strongest reasoning judgment available. The chain runs claude-opus-4.8, then gemini-3.1-pro-preview, then claude-sonnet-4-6. The frontier model goes at the head; the cheaper alternatives sit below it as fallbacks for the day the vendor is down.
The fourth is the Panel. Five judges scoring the finished plan in parallel across five dimensions. The capabilities that matter are calibrated 0 to 10 scoring and reliable JSON output. The head model runs five times per plan, so its cost multiplies fivefold. The chain runs deepseek-v4-pro, then qwen3-max-thinking, then gemini-3.5-flash. The head is the cheapest strong reasoner that emits valid JSON; the thinking model sits second in case the head’s calibration drifts.
Each of these is a different hire. The market tells you to pay frontier prices for all four. Three of them do not need it.
Cost-first for clerical work. Quality-first for the one decision that poisons everything downstream if it goes wrong.
The one role that earns the splurge
The Interviewer can run on a cheap, well-behaved flash model. The Cartographer can run on a cheap model with a one-million-token window, because the value lever there is context, not reasoning rank. The Panel runs on the cheapest reasoner that scores cleanly and emits valid JSON, because it runs five times and the multiplier dominates.
The Designer is different. The Designer runs once. If the Designer ships a bad call, the Interviewer’s good answers do not save you, the Cartographer’s careful map does not save you, and the Panel will catch what it can but a frontier-grade mistake usually slips through a mid-tier critic. The Designer is the only chair in the room where the marginal dollar bought from the frontier returns more than the dollar costs.
So three of the four roles are filled cost-first, escalating only on failure, with a frontier model parked at the end of each chain as a break-glass floor. The Designer is filled quality-first: the frontier model goes at the head, and the cheaper alternatives sit below it as fallbacks for the rare day when the frontier vendor is down.
That is the whole trick. The bill drops by roughly an order of magnitude on three of the four roles and stays at frontier prices on the one role that earns it. The plan quality, on the data I have so far, does not move.
The Takeaways
-
Match the capability lever to the job, not to the vendor. Each role needs at most two or three levers: reasoning, code comprehension, context window, instruction-following, calibrated judging. Pick the cheapest model that has them.
-
Cost-first is the default; quality-first is the exception. Three out of four roles in this pipeline are clerical-shaped. Only the role whose mistakes propagate downstream is worth a frontier price.
-
A frontier model has a job, but it is not every job. Default to frontier and you are paying frontier prices for clerical work. That money is not buying you anything you could not have bought for ten cents on the dollar.