The wrong question buyers ask first
Somewhere in most AI kickoff calls, someone asks which model the system will run on. It is a reasonable question asked at the wrong time. The answer that follows is usually "the newest one from the biggest lab," offered with the confidence of a default that nobody has actually tested against alternatives.
That instinct is not irrational. Frontier models get the press, the benchmark charts, the demos. If you have no engineering staff to push back on the choice, reaching for the most capable option feels like the safe, defensible call. It is the AI equivalent of buying the top laptop for someone who only uses email. Nobody gets fired for it, and nobody asks whether it was the right spend.
But a production system is not a demo. It runs the same narrow task thousands of times a month, and the bill arrives on a schedule the demo never showed you. Once you are past the first working prototype, model choice stops being a branding decision and becomes an engineering one, with a cost line attached.
What a frontier model is actually buying you
The newest, largest models earn their premium on a specific kind of task: open-ended reasoning, unfamiliar problems, work where the system has to figure out what to do next with little guidance. Ambiguous research questions. Novel code. Anything where the range of plausible inputs is wide and the model has to generalize from patterns it was never shown directly.
Most production workflows inside a mid-market operation are not that. They are narrow and repeatable: answer a policy question from a fixed set of documents, summarize a report into a consistent format, route a request to the right template, extract a handful of fields from a submitted form. The input space is bounded. The output shape barely varies. The task was solvable last month and will be solvable next month in the same way.
On that kind of work, the gap between a frontier model and a smaller, cheaper one often shrinks to nothing you can measure. Not because the smaller model has secretly caught up in general capability, but because the task never needed the general capability in the first place. You are paying for a much larger reasoning budget than the job draws on.
Where the cost actually lands
The sticker price per API call looks small in isolation. It stops looking small once you multiply it by call volume, and add the retries, the longer context windows some frontier models push you toward, and the latency cost when a heavier model takes noticeably longer to respond inside a workflow with a human waiting on the other end.
None of that is exotic. It is the same math as choosing a database, a hosting tier, or a shipping courier: fixed unit economics multiplied by a volume that grows if the product works. The mistake is treating model choice as a one-time decision made at the demo stage, rather than a recurring cost that scales with adoption. A model that was a rounding error at fifty calls a day is a line item worth scrutinizing at fifty thousand.
There is also a slower cost that is easy to miss: vendor and version churn. Frontier models get deprecated, repriced, and replaced on a schedule set by the lab, not by you. A system built tightly around this month's flagship model inherits that schedule as a maintenance obligation. A system built around a smaller, well-specified model for a narrow task is easier to swap out later, because the task itself defines what "good enough" looks like, rather than the model's general reputation.
The actual selection criteria
The decision is not "frontier or cheap." It is a short list of questions worth answering for each workflow before a model gets chosen:
- How wide is the input space? If every input looks roughly like the last one (a policy question against a fixed document set, a report in a known format), a smaller model handles it. If inputs vary wildly in structure or subject, that variance is what you are paying a frontier model to absorb.
- How much does a wrong answer cost? A wrong answer in an internal FAQ assistant gets corrected by a follow-up question. A wrong answer in a compliance judgment or a client-facing legal summary gets escalated, and the tolerance for error is much lower. That tolerance, not general model prestige, should set the bar.
- Is the task the model's job, or the system's job? A lot of what looks like "the model got it wrong" is actually missing retrieval, a bad prompt, or no citation back to source. Upgrading the model does not fix a retrieval problem. It just makes the wrong answer more articulate.
- What does a failure actually look like at this volume? A workflow run twenty times a day tolerates a different risk profile than one run twenty thousand times a day, because the twentieth-thousandth edge case will eventually show up.
Answer those four honestly for a given workflow and the model choice mostly falls out of the answer. It stops being a preference and becomes a spec.
When the frontier model is the right call
None of this is an argument for always choosing cheap. Some workflows genuinely need the largest available reasoning budget: drafting a first pass on a genuinely novel legal argument, synthesizing an unstructured research question across sources that were never designed to be read together, handling a request where the input truly could be almost anything. Underpowering those tasks produces answers that are confidently wrong in ways that are hard to catch, which is its own expensive failure mode.
The point is not that smaller is always better. It is that model tier should be a decision made per workflow, based on what the workflow actually demands, not a single default applied across an entire system because it felt like the safe choice at the start. A single system can and often should mix tiers: a frontier model for the genuinely open-ended piece of a workflow, a smaller model for the repetitive extraction or formatting step feeding into it.
What this means if you have no one to make the call
This is exactly the gap a buyer with no internal AI team runs into. Comparing model tiers against a specific workflow's error tolerance and volume is an engineering exercise, not a procurement one, and it is not obvious from a vendor's marketing page which of your workflows actually needs the expensive option.
The practical fix is the same one covered in how to tell if a vendor's benchmark has anything to do with your business: build a small evaluation set from your own documents and your own tasks, then test a cheaper model against it before assuming you need the expensive one. If the cheaper model clears your own bar on your own examples, the frontier premium is a cost you were paying for nothing. If it does not clear the bar, now you know exactly why the upgrade is worth it, rather than assuming it by default.
Either way, the answer comes from the workflow, not from whichever model made headlines this quarter.
