Gemini's Model Deprecation and Retirement Schedule

Every Gemini model has an end date, including the one you are calling right now. Google publishes those dates, on two different pages depending on which platform you use, and the only part of this that should ever surprise you is the part you did not look up.

The lifecycle stages

The vocabulary is worth being precise about, because the stages have different consequences and are often used interchangeably in discussion:

• Experimental — a model marked -exp or similar. Documented as not for production. It can change or be withdrawn with little notice, and no support commitment attaches to it. Building on one is a decision to rewrite later.
• Preview — a dated build such as gemini-2.5-flash-preview-05-20. More stable than experimental, still explicitly pre-GA, and superseded when the stable version ships. Preview builds are withdrawn rather than supported indefinitely.
• Stable / generally available — a versioned snapshot such as gemini-2.0-flash-001. This is the tier that carries a support commitment and a published retirement date.
• Legacy — still callable, no longer recommended, often closed to new projects. A model can sit here for a long time before it is retired, which is why “it still works” is not evidence that it has a future.
• Retired / discontinued — the endpoint stops serving it. Requests fail. There is no fallback to a successor model, by design: a silent substitution would be worse than an error.

The commitment attaches to the version, not the family. Pinning to gemini-2.0-flash-001 buys you a known set of weights until a published date; the alias form buys you continuity of service and no reproducibility. Those are the two things you are choosing between, and neither choice avoids retirement—it only decides whether the change arrives as a scheduled date or as a silent swap.

Where the dates are published

There are two authorities and they cover different surfaces:

• For Vertex AI, Google publishes a model versions and lifecycle page listing each model version with its release date and its retirement date. This is the most explicitly dated of the two and is the page to read if you are on Google Cloud.
• For the Gemini API on AI Studio keys, deprecations are announced through the Gemini API changelog and reflected in the models page, where superseded models are marked as legacy or removed.

What has already been retired

The pattern is more useful than any individual date, and three announced events establish it.

Gemini 1.0 Pro was the first generation to go. Google announced its discontinuation and it was retired on Vertex AI during the first quarter of 2025, roughly a year after the Gemini API became generally available.

The 1.5 generation followed the same arc in two steps rather than one. Google first closed gemini-1.5-pro and gemini-1.5-flash to new projects—announced for 29 April 2025—while existing projects continued to be served. The versioned snapshots were then given a retirement date, with gemini-1.5-pro-002 and gemini-1.5-flash-002 announced for retirement on Vertex AI on 24 September 2025.

That two-step shape is the thing to plan around, and it is the most practically useful fact on this page:

Typical arc for a Gemini stable version

  GA release
      |
      |   ~ a year of full support
      v
  Closed to new projects        <- existing traffic unaffected;
      |                            nothing in your logs changes
      |   ~ months
      v
  Retirement date published
      |
      v
  Requests fail

The first transition is invisible to a running service. That is why
teams discover a deprecation at the last step rather than the second.

A model being closed to new projects produces no error, no warning header and no change in behaviour for anyone already calling it. If your only signal is your own error rate, the first thing you will notice is the retirement itself.

What a retirement looks like in your logs

A call to a model that no longer exists fails at the routing layer, before any generation, with a 404:

{
  "error": {
    "code": 404,
    "message": "models/gemini-1.5-pro-002 is not found for API version v1beta, or is not supported for generateContent.",
    "status": "NOT_FOUND"
  }
}

Three things about that error are worth noticing. It is a 404, not a 400, so retry logic keyed on 5xx will not retry it and retry logic keyed on 4xx will not either—it will simply fail. The message conflates “does not exist” with “does not support this method”, so the same string appears for a typo, for a model your key cannot access, and for a retirement. And nothing degrades gracefully: there is no automatic substitution, which is correct behaviour and also means 100% of traffic to that model stops at once.

Reading an announcement correctly

A deprecation notice contains several dates and it is worth knowing which one is the one that matters to you, because they are usually not the same date and the earliest is rarely the binding one.

• The announcement date tells you when the clock started. It is not a deadline.
• The date new projects lose access affects nobody already calling the model. It is the most commonly misread line in a notice, because it sounds terminal and is not.
• The retirement or discontinuation date is the one your service dies on. This is the date to put in a calendar, and it is the only one worth alerting on.
• The named replacement is Google’s recommendation, not an equivalence claim. A successor model is usually better on aggregate benchmarks and can be worse on your specific task, which is what makes the evaluation set below the real work of a migration.

Two surfaces, two timelines, is the other thing to hold onto. The Gemini API on an AI Studio key and Vertex AI on a Google Cloud project publish their lifecycles separately, and a model can remain available on one after it has gone from the other. If your organisation uses both, check both; an assurance drawn from the wrong page is worse than no assurance because it feels like diligence.

Google has also extended announced retirement dates on occasion. That is a reason to re-check a date you noted months ago, not a reason to treat any date as soft: planning on an extension that may not come is the same bet as not planning at all.

Making a retirement a non-event

1. Put the model string in configuration. If changing models requires a code change, a review and a deploy, you will not do it under time pressure. It should be a value you can change.
2. Log modelVersion from every response. This gives you an inventory of what you are actually calling, which is almost never identical to what you believe you are calling once more than one service is involved.
3. Diff the models listing on a schedule. A weekly GET /v1beta/models compared against the last one tells you when something new appears and when something you use stops being listed. It is a cron job and a text diff.
4. Keep an evaluation set with a recorded score. The work of a migration is not changing the string; it is knowing whether the replacement is as good. A set of representative inputs with expected outputs, scored against your current pinned version today, is what turns that from a debate into a measurement you can make in an afternoon.
5. Prove the fallback path before you need it. Point a small share of traffic at the successor model deliberately, and watch. A migration path that has never carried a request is a plan, not a capability.