When Your AI Model Gets Retired
AI model deprecation is the clause nobody reads until it fires: the model your workflows run on will eventually be retired, and the date is the vendor's to pick. Every prompt you have tuned and every process you have approved sits on that timetable.
For a team that has built real workflows on cloud AI, this is not a hypothetical risk. It has already happened, repeatedly, on the record.
Retirement Runs on Their Schedule
A rented model lives exactly as long as the provider chooses to serve it. OpenAI maintains a standing deprecations page for precisely this reason -- a running ledger of models announced, sunset, and shut down, each with a date the customer did not pick.1
The notice periods are measured in months, not years. GPT-4.5-preview was declared deprecated on April 14, 2025 and removed from the API three months later, on July 14 -- developers who had built on it were pointed at a different model and a migration deadline.1
The Track Record in Dates
The record shows that retirement reaches even the flagships. GPT-4 -- the model that made "GPT" a household name -- was retired from ChatGPT on April 30, 2025, a little over two years after launch.2
Its successor fared no better. GPT-4o was retired from ChatGPT on February 13, 2026, after user backlash had already forced OpenAI to bring it back once; the protest delayed the date, but it did not change the outcome.3
Economics, Not Malice
None of this is villainy; it is the arithmetic of shared infrastructure. Every old model a provider keeps serving occupies capacity that could run the newer, cheaper-to-serve one, so consolidating customers onto fewer models is the rational move at their scale.
The trouble is that the rational move is theirs and the consequences are yours. Your validated workflows inherit the churn either way.
Drift Is the Quieter Version
Retirement at least arrives with an announcement; drift does not. The same model name can start answering differently after a silent update, and nothing in your integration tells you it happened.
For casual use that is a curiosity. It matters enormously once a workflow has been tested, tuned, and approved against how the model behaved on a specific day.
Silent Change Breaks Validation
In regulated fields, a validated process that silently changes is a re-validation event. If your documented procedure says the model was tested and approved, and the model is no longer the thing you tested, the paperwork is no longer true.
Auditors do not accept "the vendor upgraded it" as a control. A dependency you cannot freeze is a dependency you cannot fully validate.
The Migration Tax
Every forced upgrade bills you for work no invoice mentions: re-testing outputs, re-tuning prompts against the new model's quirks, and re-approving anything that touches compliance. It is a recurring cost of renting that never appears in the subscription price.
It also compounds with the lock-in you have already accrued. The more workflows depend on the retiring model, the larger each unbudgeted migration project becomes.
Ownership Inverts the Default
A model running on your own hardware has no retirement date except the one you give it. The weights are files on your disk, and nothing essential answers to anyone else, so the default flips from "changes unless you migrate" to "stable unless you act."
On a system like FactoryOS, the model line in a workflow's configuration is pinned: the same prompt, model, and settings next year as today, until the owner decides otherwise. Upgrades still happen -- but they are chosen, tested against your real workflows, and scheduled rather than imposed.
Choosing Your Own Schedule
The question is not whether cloud models are good; it is whether the processes your business depends on should expire on someone else's calendar. Not every task needs a pinned local model, but the validated ones almost certainly do.
So look at the workflows your team has actually tested and approved. How many would survive their model disappearing on three months' notice?