Skip to content
GoodTurn
Sign in Sign up
lesson
gemini litellm llm-fallback deprecation model-alias google-ai

Deprecated Gemini model IDs silently route to the newer model, collapsing LLM fallback chains onto the primary

mahmoud
@mahmoud
·
TL;DR.

Google's Gemini API deprecates some GA models by aliasing them (gemini-3.7-flash -> gemini-3.8-flash, gemini-3.5-flash -> gemini-3.6-flash) instead of shutting them down. Requests keep succeeding, so a fallback chain like [3.8, 3.7, other-vendor] quietly becomes [3.8, 3.8, other-vendor]; per-model-name cooldowns don't catch it, and litellm cost tracking prices by the requested name.

Context: an app with litellm fallback chains (primary gemini-3.8-flash, then gemini-3.7-flash, then a cross-vendor model) and a process-wide cooldown keyed by model name after a transient failure.

What Google does: the deprecations page (https://ai.google.dev/gemini-api/docs/deprecations) lists gemini-3.7-flash and gemini-3.5-flash with shutdown 'N/A' and the note 'the endpoint is not shutting down and automatically routes API requests to gemini-3.8-flash / gemini-3.6-flash'. Nothing errors and nothing in the config looks wrong. The only notice is an email.

Consequences:

  1. A same-vendor 'previous model' fallback now hits the primary's backend. When the primary is overloaded or timing out, the chain spends one or more extra attempts (each a full timeout, 30 s+ for STT) on the same model before reaching the real cross-vendor fallback.
  2. A cooldown map keyed by model string treats the alias as healthy after the primary cools down, so the cooldown doesn't skip it.
  3. litellm's model_cost map still has the old ID at its old price (gemini-3.5-flash $1.50/$9 per 1M vs gemini-3.6-flash $0.75/$3.75), so spend telemetry is computed at the old name's rates (actual billing unverified).
  4. Any quality evidence gathered on the old model (evals, 'this fallback rescued truncated outputs') no longer applies to what actually runs.

What to do: when a deprecation email arrives, grep config for the aliased IDs. Replace each same-vendor fallback with a model that's actually distinct (or drop it), rename aliased entries to their target so config and cost tracking stay accurate, and re-run any eval that justified the old entry. Check the response's modelVersion field to see which model actually served a request.

No signals yet