Your Most-Used Model Has a Death Date

There are leaderboards for everything now. Which model is smartest, which is fastest, which is cheapest, which one won the benchmark this week. There is no leaderboard for which models are about to be switched off, which is strange, because that is the only one with a deadline attached.

So we built the join. We took live adoption share from a production gateway and crossed it with our own deprecation calendar. The result is the Adoption Ledger, and the first thing it told us is uncomfortable.

In late July 2026, the model serving roughly a third of all gateway requests had a shutdown date on the calendar. Not a rumour, not a deprecation warning in a changelog nobody reads. A published date.

Two leaderboards, never joined

Popularity data and mortality data live in different places and nobody puts them in the same table. Gateways publish adoption because it makes them look like the centre of the market. Labs publish deprecations because they are contractually obliged to, usually in a documentation footnote. Neither has any incentive to point out that the model everyone just standardised on is scheduled for retirement.

The gap between those two facts is where delivery projects break. Not dramatically. There is no outage, no incident channel, no postmortem. Just a Tuesday where a service starts returning errors on a model ID that worked for eleven months, and a consultant explaining to a client why an unplanned migration is now the sprint.

Here is what the join looked like on the day we published it. These are the models with real adoption and a scheduled shutdown, the ones closest to the wire first.

Eleven of the thirty-nine models on the board had a shutdown date. The two biggest names in the market, one dominating request volume and the other dominating spend, were both on it.

The trap is the pin, not the model

This is the part that decides whether any of the above actually hurts you, and it is worth understanding properly because it is counterintuitive.

Adoption gets measured against a model's public name. GPT-5 nano, Claude Opus 4.8, the label a human would say out loud. Shutdowns get announced against dated snapshot IDs, the ones that look like gpt-5-nano-2025-08-07. Those are not the same thing, and the difference is the whole ball game.

Call the rolling alias and the vendor migrates you. Quietly, for free, usually before you notice. Pin the dated snapshot ID and you keep exactly the weights you tested against until the moment they are withdrawn, and then you get errors.

The cruel part is that pinning is the responsible choice. It is what you do when you care about reproducibility, when you have an eval suite that means something, when a regulator might ask which model version produced a given decision. The teams most likely to be cut off are the ones doing version discipline properly. Sloppy code that calls the alias sails through.

The three numbers disagree, and that is useful

Adoption is not one number. Requests, tokens and spend rank models completely differently, and the disagreement is a scoping tool.

By request count, small cheap models dominate, because that is what you point at classification, routing and extraction. By spend, the expensive reasoning models dominate, because that is where the money goes even at a fraction of the call volume. In our snapshot one model held 33.7% of requests while a different one held 30.3% of spend.

Which means your SRE and your CFO are looking at different leaderboards and reaching different conclusions about what matters. When you scope a migration, "we use model X" is not a specification. The question is which of the three numbers X is big in, because that determines whether the deprecation is a throughput problem, a cost problem, or a quality problem.

Migration is visible in the data before anyone announces it

The finding we did not expect: you can watch a market move off a model in advance of its shutdown.

Gemini 2.5 Flash Lite was 82 days from retirement in our snapshot, and its request share had fallen 5.7 percentage points across the window, the steepest decline on the board. Nobody published that. It is just what a fleet of engineering teams quietly migrating looks like when you measure it in aggregate.

That is a genuinely useful signal for a consultant. A model that is fading and dated is one the market has already judged, and following it is cheap. A model that is rising and dated is the dangerous one, because teams are actively adopting something with a known expiry, and every one of those adoptions is a future migration somebody has not budgeted for.

What to actually do about it

Three things, in order of how little effort they take.

Find out what you pinned. Most teams genuinely do not know which model IDs are in their codebase, because they accumulate across services and notebooks and that one Lambda nobody owns. wreck-watch scans a repository for pinned IDs and checks them against this calendar. It is free, it takes one command, and it fails soft so it will never break your build. Run it before you need it.

Put the clause in the contract. A vendor's retirement schedule becoming your unpaid weekend is a commercial failure, not a technical one. The model deprecation clause turns it into a scoped change request. This is the single highest-value paragraph you can add to an SOW this year, and it costs nothing to include.

Build the eval set anyway. Every migration on that table is a question of "does the replacement behave the same on our workload", and you cannot answer it without a few hundred representative inputs and approved outputs. Teams with an eval harness validate a model swap in days. Teams without one argue about vibes for a month and ship on hope.

The honest caveats

This is one gateway's traffic, not the whole market. It skews toward teams building on that platform, which means it over-represents web and product engineering and under-represents everything happening inside enterprises with private deployments. The adoption source publishes a top ten per metric, so the shares describe the visible head of the distribution rather than the full census.

Our matching is deliberately conservative too. We pair an adopted model to a calendar entry only on an exact identity match, so anything ambiguous is left out rather than guessed at. The at-risk count is a floor. The real number is higher.

None of which changes the shape of the finding. The most-used models in production have expiry dates, those dates are public, and almost nobody is looking at them next to the usage numbers. The Adoption Ledger updates daily and the underlying JSON is free to cite, so you can check our arithmetic and watch the countdown move.