The last morning of every month is when I count the model IDs in my code. Ever since I wired Gemini into the image classification pipeline for the wallpaper apps I run as a solo developer, model and endpoint expiry dates stopped being something I discover by accident. I have been burned before — a StoreKit 2 migration and a Firebase SPM move both finished uncomfortably close to their deadlines — so anything with a date attached now gets checked once a month, on my schedule rather than Google's.
Today, August 31, 2026, that monthly inventory happens to double as a status report. gemini-robotics-er-1.6-preview shuts down today, and the next deadline on the calendar is September 30, when the gemini-omni-flash-preview endpoint is retired. There is also a pricing milestone waiting at the end of the year. Let me walk through all of it.
The Deadline Table, August 17 Through December 31
Conclusion first. As of the end of August 2026, the Gemini-related deadlines worth tracking fit in five rows.
| Date | What | What happens | What to do |
|---|---|---|---|
| August 17, 2026 (already done) | imagen-4.0-generate-001 / -ultra / -fast | Already shut down | Any remaining calls have been failing for two weeks. Replace them immediately |
| August 31, 2026 (today) | gemini-robotics-er-1.6-preview | Shutdown | Move to the gemini-robotics-er-2-preview family |
| September 30, 2026 | gemini-omni-flash-preview | Endpoint retired | Switch to the GA model, gemini-omni-1.1-flash |
| No date (ongoing) | temperature, top_p, top_k | Deprecated; 3.x Flash models accept and silently ignore them | Find every call site and move output control into system instructions |
| December 31, 2026 | Gemini 3.7 Flash introductory pricing | The limited-time price ends | Multiply your monthly token usage by the standard rate and budget for next year |
The top three rows are the urgent ones. The bottom two will not break anything today — but that is exactly what makes them tricky. Changes that fail loudly get fixed; changes that fail silently get discovered months later.
What Stopped Today: gemini-robotics-er-1.6-preview
The robotics-focused experimental model gemini-robotics-er-1.6-preview shut down today, roughly one month after the July 30 announcement. Nothing about that is surprising for a model with a preview suffix, but if you left experiment code pointing at it, that code stopped working sometime today.
The successors are gemini-robotics-er-2-preview and gemini-robotics-er-2-streaming-preview, both released to public preview on the same July 30 date. They improve spatial reasoning, multi-step tool orchestration, and finding relevant moments inside video, and the streaming variant handles bidirectional input over the Live API. Note, though, that the successors are still previews. Migrate today and you are simply resetting the same clock.
If this past year taught me one operating assumption, it is this: treat any preview-suffixed model as having a retirement date that gets written the moment a GA version ships. The Omni case below is a textbook example of the interval — GA on August 27, preview retired on September 30.
September 30: From gemini-omni-flash-preview to gemini-omni-1.1-flash
Omni Flash, the conversational video generation and editing model, reached general availability on August 27 as gemini-omni-1.1-flash. With that, the preview endpoint gemini-omni-flash-preview retires on September 30. The grace period is exactly one month.
In most codebases the swap really is just a name change. Two things are worth checking, though.
First, the default resolution. GA formalized a resolution parameter with four options — 360p, 720p (the default), 1080p, and 4k — and the documentation states plainly that 1080p and 4K are upscaled outputs, not native generation. If your preview-era code relied on implicit behavior, the newly explicit default can change the file sizes you receive and how the output looks. The question of which side of the pipeline should own upscaling is one I explored in Should Omni Flash Hand You the 4K, or Should You Upscale at the Last Step?
Second, decide deliberately whether to adopt the new GA features during the migration or after it. GA added extend, which generates a continuation onto the end of an existing clip, and interpolation, which accepts up to 2 images in an image_to_video request and generates the transition between them. Mixing the endpoint swap and new-feature experiments into the same commit makes any behavior change hard to attribute. My own approach: finish the pure rename and verify behavior by mid-September, then treat the new features as separate work. That leaves a two-week buffer before the endpoint disappears, which is enough to catch a surprise in a staging environment without turning the last week of September into a scramble.
One more planning note: if you generate videos as part of a batch pipeline rather than interactively, budget a little verification time for output size. With the default now pinned at 720p and the higher tiers documented as upscales, storage and bandwidth estimates made against preview-era outputs may need a second look before you re-enable the batch.
The Deprecation With No Date: temperature, top_p, and top_k
Row four of the table is the easiest to overlook precisely because it has no deadline. The sampling parameters temperature, top_p, and top_k are deprecated, and the 3.x Flash models accept them and then ignore them. Requests return 200. No warnings appear anywhere.
A change that produces no errors always loses the prioritization battle against a change with a date on it. But if any of your code passes temperature: 0 and expects deterministic output, that assumption has already quietly stopped holding. The first step is mechanical: search your codebase for the parameter names and cross-reference the model IDs used at each call site. There is also a quick empirical check that beats re-reading documentation: send the same prompt several times with different temperature values and compare the spread of the outputs. If the spread does not change, the parameter is being ignored for that model, and you have confirmed it with your own eyes. I wrote about what actually broke for me first in When Sampling Parameters Were Deprecated, Diversity Broke Before Determinism Did.
A Minimal Monthly Inventory Routine
Handling each deadline as its own emergency costs more than deciding on one search procedure and running it monthly. Mine has exactly three steps.
| Step | Action | Rough time |
|---|---|---|
| 1. Enumerate | Mechanically extract every model ID and endpoint reference from the codebase | About 5 minutes |
| 2. Cross-reference | Check each ID against the official deprecation announcements and flag anything with a date | About 10 minutes |
| 3. Schedule | Put a start-work date on the calendar 30 days before each retirement | About 2 minutes |
For enumeration, a single line is enough:
grep -rnE "gemini-[a-z0-9.-]+|imagen-[a-z0-9.-]+" src/ --include="*.swift" --include="*.kt"Any ID containing -preview is your top-priority hit. The reason I schedule work 30 days ahead of each retirement, rather than the week before, is app review and staged rollouts: once a replacement build has to travel through store review and a phased release, reaching all of your users takes more calendar days than you expect. That habit predates Gemini — it has saved me on SDK migrations of every kind.
One Thing to Do Before September Starts
Today's action item is a single command. Run the grep above on your own repository and see whether any -preview IDs come back. If none do, the September 30 deadline is not your problem. If some do, the migration target is already sitting in GA, waiting.
One last note: after a retirement date passes, requests from old shipped clients keep arriving anyway. The risks of silently rewriting those requests to a newer model on the server — and the case for returning an explicit refusal instead — are covered down to the implementation in the premium article Why Shipped Clients Deserve a Refusal, Not a Silent Model Substitution. I hope this table makes your own month-end inventory a little shorter.