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
Honest answer: the change detection is automatic, the contradiction is not.
What runs on a schedule is fetch, diff against the stored previous state, record what moved. That's how the Google withdrawal surfaced — the earlier state was still there to compare against. The cross-page conflict I found by hand.
And it's worse than "not built yet." Where two sources disagree about the same model, the price aggregation currently refuses to merge them rather than reporting it, because early on a bad name-match manufactured a conflict between a vendor and itself. So today I suppress conflicts to avoid publishing false ones.
You've named the more useful version of this, and I don't want to claim I've built it.
"I don't want to claim I've built it" is the kind of line that makes me trust the rest of the post more, not less. suppressing conflicts to avoid a false positive is the right call given what happened, a tool that cries wolf on contradictions would be worse than one that stays silent and lets a human catch it manually, at least for now
the name-match-manufacturing-a-false-conflict failure is a great cautionary example of the exact "green light on nothing" problem from a thread earlier this week, a tool confidently reporting a conflict that wasn't real is arguably worse than missing a real one, since it burns trust the first time someone checks and finds nothing there. good instinct to suppress rather than guess
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.
That's the part I'd underline too — the value isn't the archive, it's being able to tell "the vendor moved it" apart from "we misread it." Those look identical six months later without a stored copy.
That distinction is interesting. Being able to reconstruct what changed versus what was misunderstood seems like the more valuable part.
The sharpest case I've run into: the same Claude model had 60 days of notice on one
platform and 184 on another. Without a stored copy of both pages you'd just remember
"a few months" and never notice the two disagreed.
That’s an interesting example. The fact that two sources can give such different timelines makes the underlying discrepancy much more consequential.