DevNews

Google Shuts Down Its Imagen 4 API Endpoints

On this page
  1. What is switching off
  2. The rewrite, concretely
  3. The four parameters with nowhere to go
  4. Why losing numberOfImages costs more than it looks
  5. One more date in August
  6. Sources and further reading

The three Imagen 4 endpoints in the Gemini API reach their shutdown date on Monday, August seventeenth, 2026, two months after Google listed them as deprecated in the June fifteenth release notes. The recommended replacement is gemini-3.1-flash-image, and the migration is not a matter of changing a model string. The generate images call is gone, the config object splits in two, and four parameters that Imagen users relied on have no equivalent at all, including the one that returns more than one image per request. If you still have a build calling imagen-4.0-generate-001, here is exactly what breaks.

The short answer

The Imagen 4 standard, fast and ultra endpoints in the Gemini API reach their shutdown date on August 17, 2026, having been marked deprecated in the June 15 release notes. Google recommends gemini-3.1-flash-image. The migration replaces ImagenModel with GenerativeModel and generateImages with generateContent, splits the config into GenerationConfig plus a nested ImageConfig, and drops numberOfImages, negativePrompt, imageFormat and addWatermark with no replacement.

3Imagen 4 endpoints shut down on August 17
4parameters with no equivalent at all
1image per response, where you could ask for several
Answer card: the three Imagen 4 endpoints in the Gemini API shut down on August 17, 2026, with gemini-3.1-flash-image as the recommended replacement, and four parameters removed including numberOfImages, negativePrompt, imageFormat and addWatermark.
The date, the replacement and the four parameters that disappear. Source: the Gemini API release notes and Google's Imagen migration guide. PNG

Most deprecations are a find and replace on a model string, which is why most of us have learned to skim the notice. This one is not, and the part that will surprise people is not the model quality. It is that a single call which used to hand back four images now hands back one.

What is switching off

Three endpoints reach their shutdown date on Monday, August seventeenth: imagen-4.0-generate-001, imagen-4.0-fast-generate-001 and imagen-4.0-ultra-generate-001. Google listed them as deprecated in the Gemini API release notes dated June fifteenth, so the notice period ran roughly two months.

Teams on Vertex AI have already been through this. The equivalent Imagen 4.0 endpoints there passed their deprecation date on June thirtieth, which is why the two platforms have been giving different answers to the same question for six weeks.

The recommended replacement is gemini-3.1-flash-image, part of the Gemini image family. Same provider, same account, different API shape.

The rewrite, concretely

Four structural changes, all of them mechanical once you know they exist.

The model class changes. ImagenModel becomes GenerativeModel, which is the same class you already use for text, so image generation stops being a separate code path in your client.

The call changes. generateImages, or generate_images depending on which SDK you are on, becomes generateContent. That means the response shape changes too, and anything downstream that unpacks an Imagen response by index will need attention.

Configuration splits in two. ImagenGenerationConfig becomes a GenerationConfig that carries a nested ImageConfig, and aspect ratio moves into that nested object rather than sitting at the top level. Safety configuration follows the same consolidation: ImagenSafetySettings becomes the standard SafetySetting class shared with the rest of the Gemini models.

Migration checklist from Imagen 4 to Gemini image models: swap ImagenModel for GenerativeModel, swap generateImages for generateContent, move aspectRatio into a nested ImageConfig, replace ImagenSafetySettings with SafetySetting, loop for multiple images, drop negativePrompt, expect PNG only, and expect a SynthID watermark on every image.
Eight changes between the old call and the new one. The last four have no parameter to migrate, only behaviour to accept. PNG

The four parameters with nowhere to go

This is the part worth reading twice, because none of these produce a helpful error at compile time.

numberOfImages does not exist. Gemini image models always return a single image, and Google's own migration guidance is to run generation in a loop to get the same result. That is a code change and a budget change at once, which we come back to below.

negativePrompt does not exist. There is no replacement parameter, so whatever you were suppressing has to move into the positive prompt or be handled after generation.

imageFormat does not exist, because output is always PNG. If you were requesting a different format and converting on the way to storage, that conversion step is now unconditional.

addWatermark does not exist, because generated images always carry a SynthID watermark rather than making it an option. That is consistent with the direction Google has been moving all year, including the visible watermark toggle it added to the Gemini app. Person generation restrictions also behave differently, permitted by default rather than gated behind a parameter.

Why losing numberOfImages costs more than it looks

The loop is easy to write. The consequences are less obvious.

A call that returned four candidates now becomes four calls, so your request count against quota multiplies by whatever your old numberOfImages value was. Any dashboard, alert or rate limit expressed in requests per minute was calibrated against the old ratio and is now wrong by that same factor.

Latency changes shape too. One response arriving became four responses arriving, which is faster if you fan out in parallel and considerably slower if your client loops serially because that was the smallest diff. Any user facing grid of variants now depends on several requests completing rather than one, which means it also needs a partial failure story it did not need before.

Cost accounting is the third one. If your internal reporting assumes one API request equals one billable generation, that assumption held under Imagen and does not hold now.

One more date in August

Gemini Robotics ER 1.6, the preview model gemini-robotics-er-1.6-preview, shuts down on August thirty first, 2026. The listed replacements are gemini-robotics-er-2-preview and gemini-robotics-er-2-streaming-preview.

The habit worth forming out of all this is small. Read Google's deprecations table rather than the release notes. The notes tell you when something was announced, which is interesting. The table lists earliest possible shutdown dates, which is the column that actually decides whether your build still works on a Monday morning.

Sources and further reading

Frequently asked questions

Which endpoints stop working and when?

Three models in the Gemini API reach their shutdown date on August 17, 2026: imagen-4.0-generate-001, imagen-4.0-fast-generate-001 and imagen-4.0-ultra-generate-001. Google listed all three as deprecated in the Gemini API release notes dated June 15, 2026, which gave roughly two months of notice. The Vertex AI side of the house is already past this point, since the equivalent Imagen 4.0 endpoints there hit their deprecation date on June 30, 2026. Google's recommended replacement is gemini-3.1-flash-image.

Is the replacement a drop-in?

No, and treating it as one is the main way this migration goes wrong. The class you instantiate changes from ImagenModel to GenerativeModel and the call changes from generateImages, or generate_images depending on your SDK, to generateContent. Configuration splits: ImagenGenerationConfig becomes a GenerationConfig containing a nested ImageConfig, and ImagenSafetySettings becomes the standard SafetySetting class used across the rest of the Gemini models. Aspect ratio moves inside that nested ImageConfig rather than sitting on the model config.

Which parameters have no equivalent?

Four. numberOfImages is gone, because Gemini image models always return a single image, so batch generation becomes a loop on your side. negativePrompt is gone with no replacement. imageFormat is gone, since output is always PNG. addWatermark is gone, because generated images always carry a SynthID watermark rather than making it optional. Person generation restrictions also behave differently, being permitted by default rather than gated by a parameter.

What is the practical impact of losing numberOfImages?

It changes your cost and latency model, not just your code. A single Imagen call that returned four candidates becomes four Gemini calls, so the request count against your quota multiplies by whatever your old numberOfImages value was. Anything that assumed one request equals one billable unit needs revisiting, and any user facing flow that showed a grid of variants now depends on parallel requests completing rather than one response arriving. If you paginate or rate limit on request count, check those thresholds before you ship the change.

Are other Google models retiring around the same date?

One more in August. Gemini Robotics ER 1.6, the preview model gemini-robotics-er-1.6-preview, shuts down on August 31, 2026, with gemini-robotics-er-2-preview and gemini-robotics-er-2-streaming-preview listed as replacements. Beyond that, the useful habit is to read the deprecations table rather than the release notes, because it lists earliest possible shutdown dates rather than announcements, which is the column that actually breaks builds.