The AI model you shipped with won't outlive your app.

OpenAI, Anthropic, and Google all retire model versions on a published schedule now, not a quiet fade-out. Google's current retirement date for the entire Gemini 2.5 generation — Pro, Flash, and Flash-Lite together — is October 16, 2026. If your app calls a model ID directly, that date is the day the call goes from working to throwing an error, with no code change on your side to explain it.

Deprecation is a calendar entry, not a rumor

It used to be easy to treat "the model might go away someday" as a hypothetical. It isn't anymore — all three major labs run a formal lifecycle with dates attached. Anthropic classifies every Claude model as Active, Legacy, Deprecated, or Retired, and commits to at least 60 days' notice before a publicly released model is retired. Google's Gemini models ship as stable, preview, or experimental, with different guarantees per tier: preview models get at least two weeks' notice, and once a stable model's retirement date is set, new access is blocked a month ahead of shutdown so existing traffic has a runway to move. OpenAI maintains a public deprecations page and gives anywhere from a few weeks on an experimental snapshot to a full year on something as load-bearing as the Assistants API — the notice period tracks how deeply the surface is embedded in other people's production code.

The common thread: every provider now treats a model ID the way a cloud vendor treats an EC2 image — versioned, dated, and eventually end-of-lifed. Pretending otherwise is the bug.

What actually happens on the date

Nothing dramatic — which is exactly the problem. A retired model doesn't degrade gracefully or return a helpful message about what replaced it. The call just starts failing: a not-found error on the model ID, or an explicit deprecation error if the provider bothers to say so. If that call sits behind one try/catch with no fallback, the feature that worked yesterday is broken today, and the bug report that reaches you will say "AI stopped working" with nothing pointing at the actual cause. Whoever's on call spends an hour in the debugger before realizing the code didn't change — the model underneath it did.

The Gemini 2.5 case, concretely

This isn't abstract right now. Google's retirement date for Gemini 2.5 Pro, Flash, and Flash-Lite — the whole 2.5 line — lands October 16, 2026. Plenty of apps still call one of those model IDs directly, often because a tutorial or a getting-started doc from early in the year pinned it explicitly and nobody has touched that file since. None of that code is wrong today. All of it stops working on the same afternoon, for a reason that won't show up in the diff.

Two patterns that survive the calendar

The fix isn't "check the deprecations page more often" — that doesn't scale past one provider or one engineer's memory. Two structural choices do the job instead.

Use the rolling alias, where the provider offers one. Google publishes gemini-flash-lite-latest — an alias that always resolves to whatever the newest stable Flash-Lite model is, no code change required. ShotCanvas's own AI calls point at that alias as the first entry in a single models file. When Google shipped Gemini 3.5 Flash-Lite on July 21, 2026, the app rolled onto it automatically that same day — no deploy, no PR, no one even had to notice at the time.

Keep an explicit fallback chain behind it. An alias protects you from a model disappearing; it doesn't protect you from the provider having a bad day. ShotCanvas's models file lists the alias first and two pinned prior-generation models after it, and every AI service in the app iterates that list with retry-on-failure — rate limit, outage, or deprecation error, it falls to the next entry instead of surfacing a dead end to the user. The list lives in exactly one file, so shipping a new model everywhere the app calls Gemini is a one-line change, not a grep-and-replace across a dozen services.

What an alias can't save you from

Rolling onto a new model automatically trades one risk for another: behavior can shift under you with no error at all. A newer model in the same family can change its default reasoning behavior, its output shape, or its judgment on an edge case your prompt relies on — and nothing in that is a failure the way a 404 is. The only way to catch it is to actually run your real prompts against the new model and read the output, not just watch the error rate. Treat a provider's changelog as something you check on a cadence, and keep a way to force a specific pinned model when you need to reproduce a bug or compare quality side by side — an escape hatch you'll want the one time the newest model quietly gets worse at your exact task.

Built this way from the start

Every AI feature in ShotCanvas — headline generation, the auto-designer, the metadata writer, translations — runs on the pattern above: one models file, newest first, fallback behind it. It's not a defensive afterthought; it's why the free tier can promise AI generation stays up even when a single model has a bad hour.