Hosted models retire on a schedule you do not control

A hosted model is not a fixed artifact

A model reached through a hosted API is not a permanent object a developer can rely on indefinitely: vendors retire specific dated snapshots on published schedules, and the documentation describing those schedules is itself a living page rather than a dated announcement, so what follows describes each page as retrieved on 16 September 2026, not a fixed historical record. OpenAI's deprecations page, as retrieved, states that generally available models receive at least six months of notice before retirement, while models with preview in the name may be retired with much shorter notice, such as two weeks, and it distinguishes a deprecated model, which is on a path to shutdown, from a legacy model, which still runs but receives no further updates.

Three vendors, three notice periods

Anthropic's model deprecations page, as retrieved, sets a floor of at least 60 days' notice before retirement for publicly released models and defines a four-stage lifecycle, active, legacy, deprecated, and retired, with a retired model's requests failing outright. The same page documents that specific request parameters, not only whole models, can be deprecated on newer model releases, a second axis of change beyond the model name itself. Google's Gemini API deprecations page, as retrieved, frames its dates differently again: the shutdown dates in its table are described as the earliest possible dates on which a model might be retired, with the exact date communicated separately with advance notice, rather than one fixed notice period stated up front. None of the three pages promises indefinite availability of any dated snapshot, and none uses identical terms for the same underlying idea.

Pinning, testing and the cost of standing still

A version string that includes a date, rather than a rolling alias such as latest, lets an application know exactly which snapshot it is calling and avoid an unannounced change when a vendor updates the model behind an undated name. But pinning only defers the decision: every vendor page here describes dated snapshots eventually reaching a retirement date, after which requests fail, so a pinned integration still needs a process for testing a replacement before the deadline, not after it. The three pages differ in exactly what an engineering team needs to plan around, so a multi-vendor deployment cannot rely on one migration calendar; each model family's schedule has to be tracked against its own vendor's page, not assumed to match another vendor's policy.

Questions to carry into your own evaluation

• Is your production traffic pinned to a dated model snapshot, or to a rolling alias that can change behaviour without a deprecation notice at all?
• Do you have a standing process for testing a recommended replacement model before its predecessor's retirement date, rather than after?
• Have you checked each vendor's own deprecation page recently, given that these are living documents that change independently of any single announcement?

Retirement schedules are living documents that change as vendors ship new models, and treating a hosted model's availability as permanent is a documented way an application quietly breaks on a date nobody on the team wrote down.