Two Google pages give the same model two different retirement dates. Both are live.
If you build on an LLM API, your migration runway is a number you read off a vendor page. I've been crawling those pages for 15 vendors and recording every change. The number is less stable than it looks. Everything below I re-checked this morning.
Google publishes two answers for the same three models.
The Gemini API deprecation page lists gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite with "No shutdown date announced".
Google Cloud's model lifecycle page lists the same three with a retirement date of October 20, 2026, each with a named replacement. That page's footer reads Last updated 2026-08-21, so it isn't an abandoned corner of the docs.
Until early August the Gemini API page carried a date too: October 16, 2026, with replacements. It was removed. There is no changelog entry, no release note, and no change history on the page — the only signal is the Last updated stamp, which tells you that something changed, not what. The Internet Archive holds both sides, which is the only reason I can say the earlier date existed.
The second thing is that the runway itself is per-platform, by policy.
Anthropic: "providing at least 60 days' notice before model retirement for publicly released models."
AWS Bedrock: a model "will be in the Legacy state for at least 6 months before the EOL date."
Same model, three times the warning depending on where you call it. And this isn't an accident — Bedrock's own docs say it outright: "Model lifecycle dates on this page are specific to Amazon Bedrock and may differ from dates published by model providers (such as Anthropic or Cohere). For Amazon Bedrock usage, only the dates on this page apply."
So there is no such thing as "the shutdown date" for a model. There's the date on the page for the platform you actually call.
What I'd do differently having learned this: when you commit to a model, save the page as you read it. Not for compliance — so that six months later you can tell whether the vendor moved the date or you misremembered. The vendor page won't tell you, because it keeps no history of itself. I only caught the Google withdrawal because I had the earlier state stored.
Curious whether anyone here has actually been bitten by this: have you ever had a model retired on you with less warning than you'd planned for, and did the date change under you, or did you just read the wrong page?
Context: I run aichangewatch.com, which is where these observations come from.
"there is no such thing as the shutdown date for a model, there's the date on the page for the platform you actually call" is a genuinely unsettling reframe, and it's directly relevant to something I depend on (a third-party LLM interpreting commands before anything executes). if the vendor's own docs disagree with each other, that's not an edge case to plan around later, it's a reason to treat any single retirement date as unverified until cross-checked
"save the page as you read it" is such a simple, cheap habit that I don't think I would've thought to do until getting burned once. going to actually start doing this for whatever provider I end up depending on long-term
question on the tool itself: does aichangewatch flag conflicts like this automatically (the two Google pages disagreeing), or did you catch this one manually and then go looking for a pattern? if it's automatic, that's a genuinely different value prop than "here's the current date," it's "here's where the docs contradict themselves," which is the actual hard-to-find signal
The documentation conflict is interesting. Saving the source state when you adopt a model seems useful because six months later you can distinguish a vendor changing the date from your team simply remembering the wrong one.