◉GEMINI LABJP
●ARGON — gemini-4-argon is generally available as of 10/13, aimed at complex coding, agents, math and science●DEEP RES — deep-research-pro-preview-12-2025 shuts down 10/23, 6 days left. Move to deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 is GA (10/06). gemini-3.1-flash-image is deprecated with no shutdown date yet●MCP — One write-up cut an 85,000-token tool result to 310 tokens by wrapping it in an ADK FunctionTool●FLASH — gemini-3.7-flash and 3.5-flash now route automatically to newer Flash models (10/08)●NEW — Stop Re-Reading Every Crash Report: Gre…●ARGON — gemini-4-argon is generally available as of 10/13, aimed at complex coding, agents, math and science●DEEP RES — deep-research-pro-preview-12-2025 shuts down 10/23, 6 days left. Move to deep-research-preview-04-2026●NANO — gemini-nano-banana-2.1 is GA (10/06). gemini-3.1-flash-image is deprecated with no shutdown date yet●MCP — One write-up cut an 85,000-token tool result to 310 tokens by wrapping it in an ADK FunctionTool●FLASH — gemini-3.7-flash and 3.5-flash now route automatically to newer Flash models (10/08)●NEW — Stop Re-Reading Every Crash Report: Gre…
Articles/Dev Tools
⟐ Dev Tools/2026-06-17Advanced

Catching Deprecated Gemini Models in CI ― A Guard for Back-to-Back Shutdown Deadlines

When shutdowns and deprecations pile up, build a CI check that mechanically finds stale Gemini model strings across your repo. Includes a deprecation registry, a scanner, and a days-remaining warn/fail tier you can copy and run.

gemini119gemini-api286cideprecation9devops3

✦ Premium Article

Last week I found an embarrassing miss in my own code. A thumbnail-generation script for one of my wallpaper apps ― one that runs only once a month ― still pinned an old image model I was sure I had migrated away from. The code I touch regularly was already on the new model, but a one-off script that never goes through CI sat unseen, quietly waiting to return 404s the moment its shutdown date passed.

June is a stretch where Gemini shutdowns land one after another. The personal tier of the CLI and Code Assist stops accepting requests, and two preview image models are about to be turned off. The migration guides are written carefully, but a guide tells you what is shutting down, not which line of which of your files is about to break. As long as you leave the latter to human memory and ad-hoc grep, references buried in code you rarely open will slip through.

I run four technical blogs and a handful of my own iOS and Android apps, all solo. Each one pins a slightly different model, so manually checking every repo on each shutdown isn't realistic. So I built a small mechanism that fails fast in CI on stale model strings. This article shares that deprecation registry and scanner in a form that actually runs.

Why "just read the migration guide" isn't enough

When you migrate by hand, three things usually leak through.

First, shutdown dates are scattered. When something dies on the 18th, something else on the 25th, and a third next month, a human only keeps the nearest deadline in mind. The rest get remembered on the day they arrive.

Second, references are scattered. You migrate the active app itself, but old model IDs linger in doc code samples, past examples, ops scripts that never hit CI, and comments in .env.example. None of these pass your normal tests, so you learn they broke from a user report or a crash log.

Third, a model ID is just a string. No type, no schema ― neither the compiler nor the linter says a word. "gemini-3.1-flash-image-preview" can sit in your code, and nothing in that code records that it disappears in eight days.

All three are exactly the kind of work machines are good at and humans are bad at. So let the machine do it.

Start with a single "deprecation registry" file

The first step is to gather the canonical list of shutting-down models into one JSON file. This becomes the single source of truth. Each entry ties together the model ID, its shutdown date, its replacement, and the source.

{
  "$schema_note": "Canonical list of Gemini models scheduled for shutdown. Dates are YYYY-MM-DD (judged conservatively against UTC).",
  "deprecations": [
    {
      "model": "gemini-3.1-flash-image-preview",
      "shutdown": "2026-06-25",
      "replacement": "gemini-3.1-flash-image",
      "note": "Preview image generation. Move to GA.",
      "source": "ai.google.dev/gemini-api/docs/deprecations"
    },
    {
      "model": "gemini-3-pro-image-preview",
      "shutdown": "2026-06-25",
      "replacement": "gemini-3.1-pro-image",
      "note": "Preview image generation. Move to GA.",
      "source": "ai.google.dev/gemini-api/docs/deprecations"
    },
    {
      "model": "gemini-2.0-flash",
      "shutdown": "2026-09-30",
      "replacement": "gemini-3.5-flash",
      "note": "Default progressively moving to 3.5 Flash.",
      "source": "ai.google.dev/gemini-api/docs/changelog"
    }
  ]
}

The key here is to always attach a shutdown date. It's the raw material for later varying the warning's strength by days remaining. For a model whose shutdown date isn't known yet, put in a tentatively close date and lean conservative. Treat the official deprecations page as the source of truth, and when a new shutdown is announced, update only this file. Never hard-code dates in the script.

Ideally you don't copy this registry into each repo ― you place one in a shared location and reference it. I share a single file across all four sites. When a new shutdown shows up, fixing one place makes every repo's verdict current at once.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
✦Catch the old model string sitting inside a script you almost never open ― the kind of reference reading the migration guide never surfaces
✦Get a copy-and-run deprecation registry plus a scanner that flips between warn and fail based on how many days remain until shutdown
✦Even with several repos and several shutdown dates in flight, reach a state where you can see exactly where each landmine is and how many days are left
Secure payment via Stripe · Cancel anytime
✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Gemini Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

Related Articles

⟐ Dev Tools2026-10-06
Three Veo 3.1 previews stop on Oct 22. I started with an inventory of every call site
Three Veo 3.1 preview models shut down on Oct 22, with gemini-omni-1.1-flash as the listed replacement. Before swapping model names, here is a search script that finds every call site in a repo, and a config pattern that stops loudly after the deadline instead of drifting to another model.
⟐ Dev Tools2026-08-21
Why My Length Limit Only Failed on the English Notifications, and the Width-Based Fit That Replaced It
I had Gemini write push notifications in Japanese and English, and only the English ones came out truncated on real devices. The culprit was measuring length in characters. Here are the measured widths and the post-generation fitting code that fixed it.
⟐ Dev Tools2026-08-10
Finding the questions your help docs never answer, by asking Gemini to write the quiz
When support keeps asking something your help page already covers, generate questions from that page and check whether the page alone can answer them. A two-pass audit pipeline with call design and cost math.