The model you built on is being switched off: what a deprecation notice costs a small product
Hosted AI models are retired on as little as two months' notice. What the main providers promise, what breaks besides the obvious when the replacement answers differently, how fifty saved examples turn a migration into a checklist, what to promise your own customers, and how to budget for one or two switches a year.
The email arrives on a Tuesday. The model behind your product's best feature is deprecated, and requests to it will start failing in about two months. There is a recommended replacement. It is newer, cheaper per word in some cases and better on the provider's benchmarks. Nothing in the email says it will answer your customers the same way.
Anyone who builds on a hosted model will get this email, and probably more than once a year. This article is about what it actually costs a small product: how much notice the main providers give, what breaks besides the obvious, how a set of saved examples turns the migration from guesswork into a checklist, what to promise your own customers, and how to budget for it before the email comes.
How much notice you get
Each provider publishes a policy and a list of retirement dates. They are short reads, and worth reading for the provider you are on.
Anthropic says it gives "at least 60 days' notice before model retirement for publicly released models", by email to customers with active use and on its deprecations page (Anthropic). The recent record matches the policy closely. Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August. Claude Sonnet 4.5 was deprecated on 30 September 2026 and retires on 30 November. Once retired, "requests to retired models will fail".
OpenAI generally gives at least six months for generally available models, around three months for specialised variants, and much less, around two weeks, for models with "preview" in their name, unless safety or compliance require faster (OpenAI). gpt-4.5-preview, for example, was announced for shutdown on 14 April 2025 and shut down on 14 July 2025. whisper-1 was announced on 26 August 2026 for shutdown on 26 February 2027.
Google lists the earliest dates a Gemini API model can be shut down and says it will give notice of the exact date and a replacement (Google). gemini-2.0-flash, a workhorse for many small products, had a listed shutdown of 1 June 2026.
Two details catch people out. First, if you use a model through a cloud platform rather than directly, that platform sets its own schedule: Anthropic's page says plainly that Amazon Bedrock and Google Cloud "set their own retirement schedules". Read theirs, not the model maker's. Second, the clock starts when the notice is sent, not when you read it. If it goes to a founder's inbox that nobody watches, two months can become three weeks.
What breaks, besides the obvious
The obvious break is the request failing. That one is easy: change a model name, deploy, done. If that were all, nobody would write articles about it. The expensive breaks are the ones where the new model works and answers differently.
Format. Your code expects a JSON object with four fields and gets five, or a sentence before the JSON, or a list where there was a string. Parsing fails on a fraction of requests, not all of them, which is worse, because it gets past a quick test.
Length and tone. The new model writes longer summaries, or shorter ones, or adds a polite closing line to every customer reply. Your interface truncates, or your customers notice that the support assistant now sounds like a different person.
Refusals and caution. A newer model may decline requests the old one handled, or add warnings to answers that did not have them. In a product used by lawyers, doctors or security teams, both directions matter.
Parameters. Settings your code passes may no longer be accepted. Anthropic's own page notes that on its newer models, setting temperature, top_p or top_k to a non-default value "returns a 400 error". A prompt tuned with a low temperature for consistent answers now needs a different approach, not just a new model name.
Cost and speed. The replacement may cost less per token and use more tokens per answer, or think for longer before answering. Work out the cost per real request, not per token, and time it. A feature that answered in two seconds and now takes eight is a different feature.
Your own words about it. Screenshots in the help pages, examples in the documentation, sales material that quotes a sample answer, and anywhere you named the model to a customer. These are small, and they are the ones still wrong three months later.
The regression set: fifty saved examples
The single most useful thing a small team can do, long before any deprecation notice, is keep a fixed set of real examples for each AI feature, with what a good answer looks like. When the email arrives, you run the set through the replacement and read the results. Without it, you are deciding by trying a few things in a playground and hoping.
How to build one is the subject of fifty examples and a spreadsheet, which covers choosing a model in the first place. The short version for migrations:
Fifty cases per feature is enough to start. Take them from real use, with customer details removed. Include the ordinary ones, the hard ones, and every case that ever produced a support ticket.
Write down what passes. For some features a machine can check: valid JSON, the right category, under 200 words. For others, a person needs to read both answers side by side. Mark which is which before running anything, so the result is not argued after the fact.
Keep the old answers. Store what the current model said for each case, with the date. When the old model is gone, those stored answers are the only record of how your product used to behave.
Run it on a schedule, not only in a crisis. Once a quarter, run the set against the model you use and the provider's newest one. You will see a deprecation coming months early and know whether the replacement is a one-hour change or a two-week one.
That table is a made-up example, but it is the shape of the answer you want: a short list of what changed, each item either fixed or accepted, and a date.
Make the next switch smaller
Some of the cost of a migration is decided in how the product was built, long before any notice:
One place for the model name. If the model identifier appears in twelve files, a migration starts with a search. Put it in one setting per feature, so you can switch a single feature, or a single customer, and switch back.
Know what you are calling. Anthropic's console, for example, lets you export usage by API key and model, which is the quickest way to find the forgotten script still calling an old model. Check it each quarter.
No preview models behind paying customers. Preview models are retired on the shortest notice of all. Use them to test, not to serve.
Validate every answer before using it. Code that checks the shape of each response, and falls back cleanly when it is wrong, turns a format change from an outage into a log entry.
Keep a second provider tested. You do not need to run two providers in production. You need to have run your fifty examples against a second one recently, so that if the replacement is bad, there is somewhere else to go within the notice period.
What to promise your own customers
Your customers did not sign up for a model; they signed up for a feature. Do not name a model version in a contract, an order form or a sales deck as if it were part of the product, unless you are willing to be held to it after the provider retires it.
Larger buyers are starting to ask for notice of model changes in their contracts. A promise you can keep looks like this: notice of a change of model provider some weeks in advance, notice of a version change within the same provider as soon as practical, and a description of how you test changes before release. Do not agree to get the customer's approval before switching: you cannot control the provider's timetable, and two months' notice does not leave room for someone else's sign-off. We cover the rest of that negotiation in the first enterprise contract.
When you do switch, tell people who will notice. A short note in the changelog, "summaries now use a newer model; they may be slightly shorter", saves a dozen support tickets from customers who think something is broken.
Budgeting for it
Treat a forced migration as a recurring cost, like renewing a certificate or upgrading a framework. A rough way to size it:
Those figures are our own estimate for a small product with a handful of AI features, not a measured average; your numbers will depend on how much of the answer reaches the customer directly. The point is to have them in the plan, so that the notice email moves a scheduled task forward rather than displacing whatever the team was meant to ship.
When the answer is to stop renting
Some products cannot live with a model changing underneath them at all: regulated workflows that were validated against one specific behaviour, or features whose whole value is that the output is stable over years. For those, an open-weight model you host yourself, or rent from a host that lets you pin the exact weights, is the one way to decide for yourself when to switch. It costs more to run and more to keep secure, and its own replacement will still come, just on your timetable. We weighed that trade in open-weight models in a small company.
For most small products the answer is simpler: keep renting, keep the fifty examples, and expect the email.
Sources
Anthropic, Model deprecations (the 60-day notice, lifecycle terms, retirement dates, partner platform schedules, the parameter change and the usage export); OpenAI, Deprecations (notice periods by model type and shutdown dates); Google, Gemini API deprecations (earliest shutdown dates and replacements). Pages read on 15 October 2026; providers update these pages often, so check the current version for the model you use. The example results table and the time estimates are illustrations of our own, not measurements.