Counted in press releases, this was a season of frontier launches. Counted in what our applications do differently afterwards, it was one event: for most ordinary production work, several of these systems now land inside each other’s error bars.
That is a structural change, not a leaderboard event. It is worth being precise about what it does and does not mean.
What convergence does not mean
It does not mean the models are the same. They differ in ways that matter operationally and that averages hide: instruction adherence under long tool chains, behaviour when evidence is thin, how they fail when a tool returns garbage, refusal calibration, output stability across repeated runs on identical input. Two systems with the same headline score can have very different variance, and variance is what a production path experiences.
It does not mean capability has stopped moving. It means the gap between the top few has narrowed on the middle of the distribution — ordinary production tasks — while the differences that remain have moved to the tails and to behaviour rather than raw capability.
And it does not mean choosing is now unimportant. It means choosing is no longer a source of advantage. Anyone can make the same choice, the same week, for the same price.
What it changes about selection
Our selection criteria had already been drifting away from benchmarks. Convergence finished the job.
We now select on properties that a leaderboard does not report:
- Behavioural stability. Repeated runs on identical input, scored on trajectory spread. This predicts production experience better than any capability score we have tracked.
- Failure manners. What it does with a malformed tool response, a contradictory context, an unanswerable question. We want a model that stops; we can build around stopping. We cannot build around confident improvisation.
- Instruction adherence under length. Compliance measured at the context lengths our paths actually run at, not at the lengths evals are convenient to write at.
- Operational surface. Rate limits, latency distribution — not the median, the tail — and how the provider behaves on a bad day.
None of these are exotic. They are simply the properties that survive when raw capability stops separating the candidates.
What it changes about routing
We have argued before that routing is architecture rather than model selection. Convergence sharpens the argument in an unexpected direction: it makes routing simpler at the top and more valuable at the bottom.
At the top, when several frontier models are near-parity for a class of requests, the routing decision within that class stops being about which is best and becomes about substitutability. That is a resilience property, and it is worth engineering: if a provider degrades, the path should move without a redeploy, and the only way to know it can is to have moved it on purpose, regularly.
At the bottom, the value of routing has gone up. The cheap tiers improved faster than the frontier did, so the share of requests that do not need a frontier model has grown. The routing question worth asking is no longer “which frontier model” but “does this request need one at all” — and that question is answered by the application’s own evidence, not by a benchmark.
What did not change
The layers between a foundation model and a reliable application are exactly where they were. Context construction, retrieval, evaluation, orchestration, failure handling, degradation paths — none of that got easier because the models converged. If anything the opposite: when the model is no longer the differentiator, everything else is, and everything else is engineering.
Convergence at the frontier is good news for anyone whose advantage was never the model. The thing to avoid is the conclusion that the choice no longer matters. It matters as much as it did — it just stopped being a place to win, and became a place to not lose.