Choosing which artificial intelligence model to build on used to be a one-line decision that a technical lead made once and revisited rarely. Over the past year it has quietly turned into something closer to portfolio management, with a corresponding effect on cost structures that most finance teams have not yet been asked to look at, and the companies buying AI are still largely buying it as though it were a subscription.
Consider what happened over four weeks this summer. On 1 July, Anthropic’s Fable 5 returned to general availability after the US Commerce Department lifted the export order that had taken it offline. On 9 July, OpenAI made GPT-5.6 generally available in three separate tiers, marketed as Sol, Terra and Luna. On 24 July, Anthropic shipped Claude Opus 5 with a one-million-token context window at the same headline price as the model it replaced. Three releases in under a month, and every sensible default in the market shifted, which means that any organisation that standardised on a model in June was working from a stale standard by August. This was not an unusual summer, either: the SWE-bench Verified leaderboard now tracks 113 distinct models.
For a business reader the useful question is not which of these is best, since that answer will have changed by the time a procurement cycle completes. The question is what a market this fragmented does to your cost structure and to your decision-making, and the answer turns out to be more interesting than an instruction to shop around.
The single-model company is already extinct
Whatever your AI strategy document says, your engineering team is almost certainly running several models already. Industry surveys through 2026 put the share of teams using multiple models in production or development above seventy-five per cent, with most routing across at least four providers and dozens of model tiers, and that happened for reasons that have nothing to do with indecision or vendor politics.
Frontier models and lightweight ones differ in price by roughly an order of magnitude, while the majority of production traffic never required the expensive option in the first place. A request that classifies an incoming support ticket does not need the same machinery as a multi-step financial reconciliation, and sending both to the same premium endpoint is the software equivalent of chartering a jet for the school run. Engineering teams responded by building routing layers, which estimate the difficulty of each incoming request and dispatch it to the cheapest model capable of handling it, and the vendors selling those layers report reductions in the model bill somewhere between forty and eighty-five per cent. Those figures deserve scepticism, since they come from the companies selling the layer, but the underlying arithmetic is easy enough to verify independently: moving seventy per cent of traffic from a frontier model to a cheap one cuts the input-token bill by roughly two-thirds, and the savings compound once the cheap-model share passes half.
Cheaper per token is not cheaper
This is where finance teams get caught, and in my experience it is the single most expensive misunderstanding in enterprise AI at the moment.
Model pricing is quoted per million tokens, a format that makes it look like a commodity you can compare on a rate card, when what you actually pay depends on how many tokens a complete task consumes and that in turn depends on reasoning depth, output length, retries, tool calls, caching behaviour and how many attempts the model needs before producing something your team will accept. A cheaper model that fails quality checks twice and succeeds on the third attempt costs more than a premium model that succeeds immediately, and it also consumes a review cycle from a human being, which never appears on the API invoice at all.
The multiplier matters considerably more than the rate, and the multiplier has been growing. Gartner estimates that agentic tasks consume five to thirty times more tokens than a standard chatbot interaction, for the straightforward reason that agents plan, call tools, read the results and revise, with every loop billable. The move from chatbots to agents that dominated enterprise AI budgets this year therefore changed the shape of the bill as well as its size, converting a reasonably predictable per-seat cost into something that behaves like cloud compute: variable, spiky and capable of producing an unpleasant surprise at the end of a quarter. The figure worth managing is total cost per acceptable result rather than price per token, and organisations tracking the first are optimising while organisations tracking the second are guessing.
A second dimension is hidden from rate cards entirely. The same model can be run at different effort settings that materially change both output quality and cost, and the defaults are not always the maximum. Anthropic ships high effort rather than max effort as the standard configuration in Claude Code, because at the top tier the model spends substantially longer on each attempt, which is a pricing decision presented as a configuration flag and one that most buyers never see.
The benchmarks cannot settle it for you
The natural instinct is to delegate the choice to the leaderboard, select whatever sits at the top and move on to the next decision. I would urge caution there, because 2026 has been an unkind year for benchmark credibility.
Take a single benchmark and a single model. On Terminal-Bench 2.1, Artificial Analysis reports GPT-5.6 Sol at 89.5 per cent, vals.ai reports the same model at 85.77 per cent, and a third tracker records 88.8 per cent for a single-agent configuration, which amounts to four points of spread generated purely by differences in scaffolding and effort settings. SWE-bench Pro is messier still, with three separate figures circulating as the leading score: 59.1 per cent for GPT-5.4 on Scale AI’s standardised public set, 80.0 per cent for Fable 5 in a vendor-reported aggregate, and 47.1 per cent for Opus 4.6 on Scale’s set. Those are not disagreements about ranking but about what the percentage denotes.
The academic picture is no more comforting. When researchers strengthened the test suites behind SWE-bench Verified this year, every leading model lost between thirteen and nineteen points and the rankings partially reshuffled, while a separate audit across 134 model submissions found that flawed tasks inflate scores by roughly fourteen percentage points, uniformly across vendors and model generations. The practical implication for a buyer is narrow but important: because everyone is inflated by a similar margin, relative rankings still carry some signal, whereas absolute scores carry very little. A leaderboard can tell you which three models are worth evaluating, and it cannot tell you which one to deploy.
What good practice looks like
Coinbase has publicly described the architecture that most large adopters appear to be converging on, and it makes a reasonable template: multi-cloud and multi-model routing, an internal evaluation framework, dashboards covering usage and billing, semantic caching, latency benchmarks and a documented decision framework for choosing between models. What is worth noticing about that list is that none of it is a model. It is the infrastructure for changing your mind about models cheaply, and in a market where the defaults move every few weeks that capability is the durable asset while the specific model chosen this quarter is not.
Four things get most organisations most of the way there. Build an internal evaluation set of twenty to fifty tasks drawn from work your team actually does and scored the way you actually judge quality, since this is the only benchmark that reflects your distribution and it takes days rather than quarters to assemble. Measure cost per completed task rather than per token, instrumenting retries, tool calls and human review time, because the model that looks expensive on the rate card is frequently the cheaper one once you count the work it avoids. Put an abstraction layer between your applications and any single provider, not out of distrust but because you will want to switch and the switching cost should be a configuration change rather than a project. And decide explicitly who owns the decision, which is the step companies most often skip: model selection currently falls somewhere between engineering, which understands capability, procurement, which understands contracts, and finance, which sees the bill afterwards, and in a market moving at this speed an unowned decision defaults to whatever happened to be configured last quarter.
The uncomfortable part
There is no stable answer arriving. The proliferation of models, tiers, effort settings and pricing structures is not a transitional phase preceding consolidation but simply what a competitive market with rapid release cycles looks like, and anyone who watched cloud infrastructure fragment over the previous decade before the industry decided to call it normal will recognise the pattern.
The organisations that handle this well will not be the ones that choose correctly, because correctness has a shelf life measured in weeks. They will be the ones that can choose again in six weeks without it becoming a migration project, which is an unglamorous capability that appears in no vendor demonstration and is quietly becoming one of the higher-return investments available in the enterprise AI stack.
—
Sources: Artificial Analysis, vals.ai and tbench.ai Terminal-Bench leaderboards; Scale AI SWE-bench Pro leaderboard; llm-stats SWE-bench Verified aggregate; arXiv:2603.00520 and arXiv:2606.16062 on benchmark inflation; Gartner guidance on agentic token consumption; published enterprise routing surveys, 2026.
