In mid-February 2026, OpenAI retired GPT-4o and a batch of other legacy models, following the schedule laid out in its model release notes. For everyday ChatGPT users this was an invisible background update. For API developers who hardcoded model IDs into their code, their eval pipelines, and their unit-cost assumptions, it was the kind of event that has to be taken seriously every single time.
The story here is not which model died. It is the frequency. Line up the release notes of the two major vendors and the cadence speaks for itself:
- OpenAI: GPT-5.2 base (December 11, 2025), then GPT-5.2-Codex (January 14, 2026), then GPT-5.3-Codex (February 5, 2026)
- Anthropic: Claude Opus 4.6 (February 5), then Claude Sonnet 4.6 (February 17), which became the default model for free and Pro users on day one
Lifecycles Shorter Than Project Timelines
Connect those dates. OpenAI shipped three GPT-5-family versions in under two months; Anthropic put out two new major models in February alone. Most product teams plan in quarters. The model a team picked at kickoff may well be on the deprecation watch list before the feature ships.
A model retirement does not behave like server end-of-life, where things slow down before they stop. It is a hard cutoff: once the release notes say a model is gone, the hardcoded ID fails outright, and what fails is the entire API call, not some degraded sub-feature.
The second-order effect lands on planning. Roadmaps that assume a stable model for six months are quietly planning against a market that no longer offers one, and the gap shows up later as rushed migrations right before launches — the worst possible moment to re-validate prompts, evals, and cost ceilings at once.
Where Things Actually Break
In practice, deprecation risk concentrates in three places:
- Hardcoded model IDs — they start returning errors on retirement day, with no gradual performance decline to warn you
- Prompts tuned to the old model — behavior differs on newer models, output quality drifts quietly, and the complaint often arrives from users before monitoring catches it
- Evals and cost models — token usage and pricing structures change with the model, and unit economics built on the old assumptions stop being accurate
Three Defenses That Work
Given a cadence that will only accelerate, the move is not to predict which model lasts longest. It is to build lifecycle management into the architecture:
- Pin exact versions — fix full model names in configuration and code, and do not let an alias decide your upgrade schedule
- Abstract model routing — collapse vendor and model selection into one configurable routing layer, so swapping a model is a config change, not a code change
- Make migration routine — subscribe to release notes, validate new models in staging first, shift traffic in stages, and turn upgrades into a quarterly chore instead of an incident response
None of this is exotic engineering; it is the same discipline teams already apply to database versions and operating systems. The difference is cadence. Infrastructure vendors deprecate on multi-year horizons, while model vendors now do it on quarterly ones, so the boring practices have to run on a much faster clock.
Accelerated deprecation is not vendor malice; it is simply how this industry competes right now. The difference between teams is procedural. Teams that treat lifecycle management as a first-class engineering problem turn retirement dates into calendar entries. Teams that do not get their notification from a production error in the middle of some February.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.