Hardware Lasts Years, Models Last Months: Planning the Mismatch

Concept render

Providers publish minimum notice before retiring a model: at least 6 months for OpenAI generally available models, at least 60 days for Anthropic, and as little as 2 weeks for OpenAI previews, as of October 31, 2026. Google lists earliest possible shutdown dates. Record the identifier, the dates and a swap path before you lock a model.

A device takes months to build and is expected to work for years. A hosted language model can be deprecated and retired on a provider schedule that you do not control. This guide reads three providers' deprecation pages, turns the dates into day counts you can check, and lists what to measure and what to ask before you pick a model. It contains no Duobay price and no measured result.

All dates and rules below come from the providers' public pages, as of October 31, 2026. Retirement tables change often, so re-read the linked pages before you decide.

How much notice do providers publish?

Each provider states its own rule. The rules differ in length and in how binding they are.

How much notice did models actually get?

These are retirements listed on the same pages. The day count is the removal date minus the notice or deprecation date, computed here from the listed dates.

The Anthropic claude-sonnet-4-5-20250929 retirement date of 2026-11-30 is still ahead of the date we read the page. The claude-opus-4-1-20250805 and claude-3-7-sonnet-20250219 models were already retired.

How long did Gemini models stay listed?

Google's table gives a date for each model and an earliest possible shutdown date. The day count below is the gap between the two. The page says shutdown dates are the earliest possible dates, so an actual shutdown can come later.

The same page lists the stable Gemini 2.5 models with no shutdown date announced. Some 2.5 preview models do have dates, so that statement covers the stable models only (source, as of October 31, 2026).

What do the numbers tell you?

This section is our reading of the tables above.

• The two OpenAI entries and the three Anthropic entries each ran between 61 and 183 days from notice to removal. Notice length varies by provider and by entry.
• The Gemini rows span a wide range of listed lifetimes, and the shortest belongs to a preview model.
• Every date from Google and every "not sooner than" date from Anthropic is a lower bound. The date can come later, and the provider does not promise it.
• A hosted model can leave while units built today are still in stock or in the field. The tables show the schedule, and they say nothing about your build time or your support promise.

What are the common traps?

These follow from the published rules and dates above. They are engineering reasoning. None describes an incident at any company.

• A preview model in a production design. OpenAI says preview models can get much shorter notice, such as 2 weeks. Keep preview models in early experiments, and write down that they are previews.
• Counting on the stated notice class. OpenAI lists a 6-month minimum for generally available models. The GPT-4 series entry above runs 92 days from notice to removal. The page text we captured does not say which class those models belong to, so we cannot say the rule was broken. Plan on the shorter number.
• Reading an earliest date as a promise. Google says its shutdown dates are the earliest possible dates. Anthropic lists tentative dates as "not sooner than". Both are lower bounds. A stable Gemini 2.5 model with no shutdown date announced tells you only what the page said on the day you read it.
• A notice shorter than your update cycle. If a swap, retest and over-the-air update take longer than the notice you were given, the notice cannot be met even if you start the day it arrives. Measure your swap time before you rely on any notice period.
• Request code that breaks on a swap. Anthropic documents that temperature, top_p and top_k are removed in API version 2026-10-21 and return a 400 error. A model or API swap can fail on the request, before any question of answer quality arises.
• A retired identifier on a unit in stock. This is our engineering reasoning. A device that left the factory with a model identifier that has since been retired can fail at first power-on, before any release can fix it. Check the retirement status of the pinned identifier before each shipment.
• No owner for migration cost. A hosted model leaves on the provider schedule. If the contract with the team that built the firmware does not say who pays for and who tests the swap, the device can reach the field with no one assigned to it.

What should you measure on your own board?

The provider pages tell you the schedule. They do not tell you how long your swap takes or how your answers change. We have not run these tests for you, and this page reports no results. The pass line for each test is yours to set from your product requirements, and you should record the reason for it.

Set the pass line yourself, write it down before you run each test, and record how you chose it.

What should you think through before you choose?

Answer each question yes or no. Take the list to your team and to any supplier who builds the firmware or the backend, including us. Each no is an open item to resolve before you commit. The gate process describes the stages where you can close them.

• Do we know the exact model identifier the firmware calls?
• Did we write down the date we read its retirement status?
• Do we know whether that model is generally available, a specialized variant or a preview?
• Have we recorded the earliest published retirement date for it?
• Is the model name a setting on a server we control?
• Have we measured how long a swap takes end to end?
• Have we checked every request parameter we send against the replacement model and the current API version?
• Does the device have a defined behavior when the model call is rejected?
• Is there a named person who re-reads the deprecation pages after launch?
• Does the contract say who pays for and who tests a forced migration?
• Do we have a fallback model that is already tested?
• Have we written down the pass lines for our own tests and the reason for each?

To talk about your device, tell us about it. You can also read how our app, cloud and AI scope keeps the model behind an interface you own.

Sources

All pages accessed October 31, 2026. Retirement tables change, so re-read them before you decide. This is an engineering summary, so confirm contract and compliance questions with your own advisers.

• OpenAI, Deprecations: https://developers.openai.com/api/docs/deprecations (accessed 2026-10-31)
• Google, Gemini API deprecations: https://ai.google.dev/gemini-api/docs/deprecations (accessed 2026-10-31)
• Anthropic, Model deprecations: https://platform.claude.com/docs/en/about-claude/model-deprecations (accessed 2026-10-31)