The release, in one paragraph
The most important AI story of May 2026 is the one that didn't happen. After seven frontier-scale models launched between February and April — Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro and a handful of others — the Intelligence Index ceiling that was set in April held into mid-May with no frontier-scale jump from Anthropic, Google, Meta, Mistral, or any of the Chinese labs. What shipped instead was efficiency and product: Gemini 3.5 Flash reached general availability running roughly four times faster than comparable frontier models while reportedly outscoring the previous quarter's Gemini 3.1 Pro across most benchmarks; Qwen 3.7 Max landed on May 19 priced to undercut Claude Opus 4.7 and GPT-5.5 on price-per-quality; and across the board the top-tier coding models now cluster within a couple of benchmark points of each other — five frontier coding models within two points on SWE-style benchmarks, five general models within three on the broad reasoning suites. The consensus read across the May roundups: the frontier took a breath, and the action moved to architecture, efficiency, and the defaults baked into products.
The surprising line isn't "the frontier is plateauing" — plateaus have been called prematurely before and may be again. The surprising line is what the convergence does to strategy. For three years the implicit enterprise AI playbook was "pick the smartest model, and re-pick when a smarter one ships." That playbook assumed a meaningful gap between the best model and the rest. In May 2026 that gap, on most production workloads, has narrowed to noise. When five models are all good enough, "which is smartest" stops being a decision worth optimizing — they're all above the bar for most tasks. The durable advantage moves to the two things that don't commoditize: the eval suite that proves a given model actually works on your workload, and the routing layer that sends each request to the cheapest model that clears your bar. The teams still shopping for the single smartest model are optimizing the one variable that just stopped mattering.
Why convergence moves the decision from model choice to eval ownership
For three years, capability arrived through model upgrades, and the strategy that followed was simple: track the leaderboard, adopt the leader, repeat. Convergence breaks that loop — not because the models stopped improving, but because the gap between them stopped being decision-relevant for most workloads. When the question "which model is best" returns "they're all within the margin," the question that actually determines outcomes becomes "which model is best for this specific workload, and how do you know."
Leaderboards measure the average workload, which is nobody's workload. A model that leads SWE-bench by two points leads on the benchmark's distribution of tasks, not on your codebase, your contract template, your support tickets, your incident runbooks. The two-point benchmark gap tells you almost nothing about which model wins on the workload you actually run. The only instrument that answers that is an eval suite built on your data — and building it is the work that convergence makes unavoidable.
"Good enough" is a per-workload judgment, not a leaderboard rank. For a low-stakes internal summarizer, every frontier model and several cheap ones are over-qualified — route to the cheapest. For a customer-facing agent that touches money, "within two benchmark points" is meaningless; what matters is the measured failure rate on your highest-risk paths, which a public benchmark never tested. Convergence doesn't mean "any model works." It means the bar is now set by your workload's tolerance for failure, and only your eval measures distance from that bar.
The moat migrated from the model to the measurement. When everyone can call the same tier of model, the model is no longer a differentiator — it's a commodity input, like bandwidth. What differentiates is knowing, with evidence, which commodity input is sufficient for which job, and being able to prove it to a security team and a procurement committee. That knowledge lives in the eval suite. The teams that own a rigorous, workload-specific eval suite have a moat; the teams relying on the vendor's published score have a receipt.
Why the routing layer is the other half of the moat
If convergence makes the eval suite the instrument that grades models, the routing layer is the mechanism that acts on the grade — and together they're where the durable advantage now lives.
Price-per-quality is the axis the frontier is now competing on. Gemini 3.5 Flash at 4x speed and Qwen 3.7 Max undercutting the leaders aren't capability stories — they're cost stories. The vendors themselves have pivoted from "smartest" to "same quality, cheaper and faster," because that's the axis that's still moving. A team that routes every request to the most expensive flagship is leaving the entire price-per-quality improvement on the table. The savings from routing the 80% of easy requests to a cheap fast model, and reserving the flagship for the 20% that need it, is frequently larger than any single model upgrade delivered.
Routing is only safe on top of evals. The reason most teams over-provision — sending everything to the flagship — is that they can't prove the cheap model is good enough for the easy requests, so they pay for certainty. The eval suite is what makes routing safe: it measures, per workload, which model clears the bar, so routing to the cheaper one is an evidence-based decision rather than a hope. Evals without routing leaves the savings unrealized; routing without evals is reckless. The two are halves of one system.
Multi-model is the enterprise reality, so the routing layer is also a portability layer. Convergence means no single vendor wins everything, and enterprises increasingly run several — one for coding, one for cost-sensitive bulk work, one for the regulated workload, a fallback when a provider has an outage. A routing layer that abstracts the provider behind a workload-aware policy is what turns "we use four models" from an integration mess into a managed capability — and it's what lets you adopt next quarter's cheaper model by changing a routing rule instead of a codebase.
What this actually changes for production teams
Stop chasing the leaderboard; start building the eval. The single highest-leverage AI investment in a converged market isn't evaluating which model to standardize on — it's building the workload-specific eval suite that lets you evaluate any model against your bar, on demand, forever. That asset appreciates with every model release; a model choice depreciates the day a cheaper equivalent ships.
Treat model selection as a routing policy, not a standardization decision. The 2024 instinct was to pick one model and standardize the org on it. The 2026 move is to define a routing policy — cheap-and-fast for the easy majority, flagship for the hard minority, a specific model for the regulated workload — and let the eval suite set the thresholds. Standardizing on one model in a converged market means overpaying on the easy requests and under-serving the hard ones.
Budget for eval maintenance, not model migration. The recurring cost in a converged market isn't re-platforming onto each new model — the routing layer makes adoption a config change. The recurring cost is keeping the eval suite current as workloads drift and new failure modes surface. That's the line item that deserves the budget the "model migration project" used to get.
Build the abstraction before you need the second model. The teams that handle multi-model gracefully built the provider-abstraction and routing layer before they were running four models in production. Retrofitting it across a codebase that hard-coded one vendor's SDK everywhere is the painful version. Build the thin routing seam early, even if you start with one model behind it.
What it doesn't change
A plateau in headline capability isn't a plateau in everything. The Intelligence Index ceiling holding for a few weeks doesn't mean progress stopped — efficiency, context length, tool use, and agentic reliability are all still moving fast. "The frontier took a breath" describes the top-line capability number, not the whole field. Don't mistake a pause in one metric for the end of the curve.
Convergence doesn't mean the models are interchangeable on your workload. "Within two benchmark points" on average can hide a large gap on a specific task family — one model might be far better at your particular kind of code, your particular language, your particular failure-sensitive path. The whole point of the eval suite is that aggregate convergence and per-workload divergence coexist. Don't read "they're all close" as "pick any."
Cheaper-per-quality isn't free. Routing to a cheaper model captures real savings, but the routing layer, the eval suite, and the maintenance behind them are a genuine engineering investment. The savings are large enough to justify it for most teams at scale — but "we'll just route to the cheap model" without building the eval that proves it's safe is how you trade a cost line for an incident.
The plateau could end next month. Calling a plateau is a bet, and the frontier has surprised before. The strategy of investing in evals and routing is robust either way — it pays off if the plateau holds (the cheap models keep getting better and you keep capturing the savings) and it pays off if it breaks (you can evaluate and adopt the new leader the day it ships). That robustness is the actual argument for it, independent of whether the plateau is real.
Where we'd push back on the framing
"The frontier is plateauing" is a few weeks of data, not a trend. A held ceiling from April into mid-May is a real observation and a thin one. Calling it a plateau is premature; the honest statement is "headline capability paused this month while efficiency and price moved." Build your strategy on the convergence that's already measurable on your workloads, not on a prediction that the pause is permanent.
Benchmark clustering is partly a benchmark-saturation artifact. When five models cluster within two points, part of what you're seeing is the benchmark running out of headroom, not the models becoming truly equivalent. Saturated benchmarks compress real differences. That's another argument for your own eval suite — a fresh, workload-specific eval has headroom a saturated public benchmark doesn't, and will surface differences the leaderboard has stopped being able to measure.
"Just route to the cheapest model that passes" understates how hard "passes" is to define. The routing pitch is clean; the engineering is not. Defining "passes" for a workload — the rubric, the thresholds, the per-request difficulty classification that decides which tier to route to — is the genuinely hard part, and it's exactly the part a one-line "use a router" recommendation skips. The router is easy; the eval that makes its decisions safe is the work.
Cheaper models concentrate the eval burden, they don't remove it. Every dollar you save by routing down to a cheaper model raises the stakes on the eval that approved the routing. A flagship that's over-qualified hides the eval's weaknesses; a cheap model running near its competence ceiling exposes them. The savings and the eval rigor required to capture them safely scale together.
What we'd build differently this week
- Inventory your AI workloads by stakes, not by model. For each workload, write down the cost of a wrong answer and the current model it runs on. The mismatches — low-stakes workloads on the flagship, high-stakes workloads with no real eval — are your immediate routing and eval priorities.
- Build one workload-specific eval suite, end to end. Pick the workload where model cost or failure risk is highest, and build the eval that grades any model against your bar on your data. Treat it as the template for the rest. This is the appreciating asset; the model choice is the depreciating one.
- Stand up a thin provider-abstraction and routing seam. Even if you run one model today, put the routing layer in now — a workload-aware policy behind a stable interface — so adopting next quarter's cheaper equivalent is a config change, not a refactor.
- Set routing thresholds from eval data, not vibes. Use the eval suite to decide, per workload, the cheapest model that clears the bar. Route the easy majority down, reserve the flagship for the hard minority, and revisit the thresholds when the eval or the model set changes.
- Reallocate the "model migration" budget to eval maintenance. The recurring spend in a converged market is keeping evals current as workloads drift, not re-platforming onto each new model. Move the budget to where the recurring work actually is.
Sonnet Code's take
The quiet month at the top of the leaderboard is the loudest strategic signal of 2026. When the frontier was sprinting, "pick the smartest model" was a defensible strategy because the gap was real. Now that five models cluster within noise on most workloads and the vendors themselves are competing on price-per-quality, the gap that justified the strategy has closed — and the advantage has moved to the two things convergence can't commoditize: the eval suite that proves a model works on your workload, and the routing layer that sends each request to the cheapest model that passes. The teams still asking "which model is smartest" are optimizing a variable that stopped mattering; the teams asking "which is sufficient, and how do we prove it" are building a moat that survives every model release.
That's the work we do, on both sides. AI training at Sonnet Code is the senior-practitioner side of the eval engagement — the engineers and domain experts who build the workload-specific rubrics, the golden datasets, and the failure-mode catalogs that prove, with evidence a procurement committee will accept, which model clears your bar for which job. AI development is the engineering that turns those evals into a live system — the provider-abstraction layer, the workload-aware router, the threshold logic wired to the eval results, the observability that tracks cost and quality per route. If your team watched a quiet May at the top of the leaderboard and started wondering whether your AI strategy is still "adopt the newest model," the next conversation isn't about which model to switch to. It's about building the eval that tells you which model is enough, and the routing layer that turns that answer into the cost savings the converged frontier is handing you.
