How do we know whether an announcement affects us?

By having recorded which versions your features actually call, which is the piece of work that pays for itself here. Without it, every announcement starts with an investigation under time pressure, and organisations discover dependencies they did not know existed. With it, the answer is a lookup and the planning can start immediately.

What does moving actually involve?

Re-testing rather than reconfiguring. The identifier changes in a moment; what takes the time is checking anything tuned to the old behaviour, which means instructions, thresholds and whatever evaluation you have. Budget it as a testing exercise and the notice period is usually adequate; budget it as a swap and it is not.

Can we avoid this entirely?

Two arrangements do, and both trade the deadline for a standing cost. Running downloadable weights yourself means nothing retires without your agreement, at the price of operating the serving. Routing through a layer that can swap providers makes the change a configuration, at the price of another company in the path.

Why do vendors do this at all?

Because keeping old versions serving costs them capacity and attention indefinitely, and the field moves quickly enough that maintaining every generation is not viable. It is a rational commercial decision rather than a hostile one, which does not make the date any more negotiable for the people who built on it.

Glossary

Model deprecation

Model deprecation is a vendor retiring a version on a published date, which makes it the one deadline in this field that somebody else sets and you have no way to decline.

In plain terms

The vendor announces that a version will stop working on a certain date, and on that date it stops. Everything else about using these tools is a choice you can revisit. This one is a deadline set by somebody who does not know what you built, and the only options are moving in time or not working afterwards.

Why it matters

Because it converts an invisible dependency into a scheduled piece of work, usually at an inconvenient moment. Anything that quietly depends on one version now has a date attached to it, and the teams caught out are the ones who never wrote down which versions they were using, so the announcement does not obviously apply to anybody in particular.

How it works

Notice periods are real and shorter than the work they imply. Vendors publish dates ahead of time and the interval assumes a straightforward swap, whereas the actual job is re-testing anything tuned to the old version's behaviour, which is a different size of task. Reading the announcement as a swap is where the surprise comes from.

The replacement is better and not identical, which is the part that catches teams. A newer version generally performs well on everything you measured and differently on something you did not, so instructions that relied on a habit, thresholds chosen from old output and evaluations calibrated against it all need revisiting. Improvement and equivalence are not the same claim.

Two arrangements avoid the deadline altogether and both cost something else. Running downloadable weights on your own hardware means nothing is retired without your agreement, at the price of owning the serving; putting a routing layer in front means the swap is a configuration change, at the price of another party in the path. Each converts a deadline into an ongoing cost.

The teams that suffer are the ones without a record of what they use. An announcement names a version, and answering whether it affects you requires knowing which versions your features call, so organisations that never wrote that down have to go looking under time pressure. The remedy is upstream and cheap, and it is almost never in place before the first announcement arrives.

How the same announcement lands

The uncomfortable thing about deprecation is that it is the moment an organisation finds out what it actually built. A notice names a version, and answering the simple question of whether it matters requires knowing which features call which models, which is exactly the sort of thing nobody records while a project is being delivered. So the first week goes on discovery rather than on migration: searching code, asking people who have moved teams, finding an automation somebody set up during a busy quarter and never documented. That week comes out of the notice period, and the re-testing that follows is the part that actually needed the time. None of this is difficult to prevent and all of it is easy to postpone, because the cost of not recording a version is zero until precisely the day it is not.

Seen in the wild

An open-weight family with no first-party hosted tier, so what you run is retired only when you decide to retire it.
Llama (Meta)
A routing service in front of many providers with automatic fallbacks, which turns replacing one model into a policy change rather than a migration.
OpenRouter
A line whose downloadable members are self-hosted while its current flagship is reachable only as a hosted service, so the two halves carry different exposure.
Qwen

Common misconceptions

People assume

The notice period is the time we need.

In fact

The notice period assumes a swap and the work is a re-test. Anything tuned to the old version's habits has to be checked against the new one, which is a larger job than changing an identifier and is the reason these dates arrive as emergencies for teams who read them as administrative.

People assume

The newer version is a drop-in improvement.

In fact

It is generally better and reliably different. It will perform well on what you measured and behave unlike the old one somewhere you did not look, so instructions, thresholds and evaluations built around the previous behaviour need revisiting rather than carrying over.

People assume

Self-hosting removes the problem.

In fact

It removes the deadline and adds a standing obligation. Nothing is retired without your agreement, and in exchange you own the serving, the capacity and the decision about when to move, which is a real cost that simply falls in a different place on the balance sheet.

Telling them apart