Between Friday morning and Saturday morning, seven model shutdown dates I had written down moved. I had published one of them.
On Friday I wrote here that Microsoft Foundry retires claude-haiku-4-5 on Sunday, November 15, and that when two official pages disagree, you should plan for the earlier date. On Saturday morning, Microsoft's retirement schedule says February 22, 2027.
This is not a complaint about Microsoft. It is the point of this post: a shutdown date is a value you read, not a value you store. If you copied one into a calendar, a ticket or a code comment, you made a cache with no expiry.
What moved overnight
Read on Nov 13 and Nov 14, 2026, from each provider's own page
| Model | Where | Read Nov 13 | Read Nov 14 |
|---|---|---|---|
claude-haiku-4-5 (versions 1 and 2) |
Microsoft Foundry | 2026-11-15 | 2027-02-22 |
claude-opus-4-5 |
Microsoft Foundry | 2026-11-24 | 2027-02-22 |
gemini-2.5-flash-preview-tts |
Gemini API | Nov 17, 2026 | Dec 18, 2026 |
gemini-2.5-pro-preview-tts |
Gemini API | Nov 17, 2026 | Dec 18, 2026 |
gemini-3.1-flash-tts-preview |
Gemini API | Nov 17, 2026 | Dec 18, 2026 |
gemini-3.1-flash-live-preview |
Gemini API | Nov 17, 2026 | No shutdown date announced |
gemini-2.5-flash-native-audio-preview-12-2025 |
Gemini API | Nov 17, 2026 | Mar 31, 2027 |
Sources: Microsoft's model retirement schedule and Google's Gemini deprecations page.
Every date moved later. Anyone who planned a migration for this weekend got three more months on Foundry and a month or more on the Gemini API. Nice for them. It still means the date they planned against was wrong by Saturday.
The pages tell you this, in the small print
Each provider says, in its own words, that its dates are not fixed.
- Google says the shutdown dates on its page are "the earliest possible dates", and that it will announce the exact date with advance notice (Google).
-
Anthropic lists most models with a "Not sooner than" date.
claude-haiku-4-5-20251001is listed as Active, not sooner than October 15, 2026, which passed a month ago (Anthropic). - Microsoft says preview models launch with a "not sooner than" date that is sometimes extended, and that it can retire a model early, with shortened notice, for security or compliance reasons (Microsoft).
The same Microsoft page answers "Can I get an exception to extend a model's retirement date?" with "No. Retirement dates aren't extendable." To be fair, that is about a customer asking for more time. Microsoft can still change its own schedule, and between Friday morning and Saturday morning it did, for two models that are generally available. The page does not say why.
And the two official sources for Claude on Foundry still disagree. Anthropic says its dates apply to Microsoft Foundry. Microsoft's page now says February 22, 2027. Yesterday they disagreed in the other direction.
Dates move both ways
This week every move was later, and later is mostly harmless. But the policies above leave room for earlier: a security retirement with shortened notice, or a preview model with 30 days' notice on Foundry (Microsoft).
The replacement moves too. My notes from November 2 give gpt-5.6-sol as the replacement for o3 on OpenAI's API. OpenAI's deprecations page says gpt-6.1-sol today, with the same December 11, 2026 shutdown. A calendar entry would have kept the date right and the fix wrong.
What to store instead
- The model ID and where you call it. The platform, and the region on Amazon Bedrock. The same model has different dates on different clouds.
- The URL of the page that owns the date. Not the date.
- A job that re-reads that page and tells you when the row changes. A diff of the row is enough. It does not need to understand the page.
- Plan against the earliest date on the page today. Treat a later date as more time, not as permission to stop checking.
The best argument against this
"If dates mostly move later, a stale calendar entry only makes you migrate early. Early is fine."
That is mostly true, and if a stale date only ever moved later, I would stop here. Two things keep me from agreeing. First, the replacement changes, as with o3 above, and migrating early to the wrong replacement is work you do twice. Second, the policies allow a date to move earlier, and a calendar entry cannot tell you which kind of change happened. You only find out by reading the page again. So read it on a schedule.
Where Since fits
This is the problem I build Since for. Its calendar shows the current date for each model on each platform, and changes when the provider's page does.
Where do your team's shutdown dates live today: a calendar, a ticket, a code comment, or nowhere?
I'm Nabil. I build Since, which tracks what your code depends on and tells you before it breaks.
Top comments (0)