Contents
Google is shutting down every Imagen 4 endpoint today. imagen-4.0-generate-001, imagen-4.0-ultra-generate-001, imagen-4.0-fast-generate-001, and every legacy gemini-3-image variant stop responding as of August 17, 2026. If your backend still calls client.models.generate_images(), that call does not degrade gracefully or throw a deprecation warning. It returns a hard error, in production, the moment the shutdown lands.
This matters beyond the immediate outage risk. It is the clearest sign yet that Google has stopped treating Imagen as a separate product line and folded image generation entirely into the Gemini model family, the one marketed as “Nano Banana.” That consolidation changes the API shape, the pricing model, and a few features developers have quietly relied on. None of it is a drop-in swap.
What actually breaks
The method itself is gone. generate_images() does not exist on the Gemini image models. The replacement is the same generate_content() call you would use for text, just pointed at gemini-3.1-flash-image. That is a bigger change than a renamed function: your prompt now goes in as contents instead of prompt, and the config object that controlled batch size and aspect ratio no longer applies the same way.
The response shape changed too. Imagen 4 gave you a clean response.generated_images array. Gemini image models return images as content parts inside response.candidates[0].content.parts, mixed in with any text the model decides to return alongside the image. You now have to loop over parts and check for inline_data rather than just reading an array. Code that assumed one shape will silently mishandle the other.
Batch generation in a single call is gone. The number_of_images parameter has no equivalent on Gemini image models. Each call produces exactly one image. If your product let users generate four variants and pick a favorite, that is now four calls instead of one, which is the kind of change that is easy to miss in code review and expensive to miss in production, since it multiplies both latency and cost.
A few smaller features do not carry over at all: negative prompts are gone, output format is fixed to PNG, and the SynthID watermark is now mandatory and cannot be disabled.
The pricing shift nobody budgeted for
Imagen 4 billed per image, flat: $0.02 fast, $0.04 standard, $0.06 ultra. Predictable, easy to put in a spreadsheet. Gemini image models bill per token, and token count scales with resolution. At standard 1K resolution, gemini-3.1-flash-image comes out to roughly $0.067 per image synchronously, about 67% more than Imagen 4 Standard. Push to 4K output and a single image runs closer to $0.15. The Batch API brings the per-image cost down to around $0.034, which actually undercuts Imagen 4 Standard, but only if your workload can tolerate batch latency instead of a synchronous response.
That distinction, sync versus batch, is now a real product decision rather than an optimization you can defer.
Try it: what does your migration actually cost
Punch in your current monthly image volume and which Imagen 4 tier you were on. This compares your old flat-rate bill against Gemini 3.1 Flash Image at standard 1K resolution, both synchronous and batch.
About the demo
Uses the published per-image rates above. It is an estimate for planning, not a live pricing lookup.Enter your volume and click Compare.
Where this leaves you
If you have not migrated yet, the useful move right now is not reading the docs end to end, it is grepping your codebase for generate_images and imagen-4.0 and finding every call site before the shutdown finds them for you. Update the method call, rewrite the response parsing, and replace any loop that relied on number_of_images with an actual loop. Then run the new calls against your real prompts in staging, since safety filtering differs between model families and can reject prompts that used to pass cleanly.
The pricing change is the part worth flagging to whoever owns your budget, not just your on-call rotation. A 67% jump on synchronous calls is easy to miss until the invoice arrives, and the fix, moving to the Batch API, is a genuine architecture decision about whether your product can tolerate the added latency. Teams with data residency requirements should also check regional availability before assuming this is a same-day swap. My take: this is the shape most of these API consolidations will take going forward, a fast timeline, a non-trivial code migration, and a pricing model change that looks small per unit and adds up fast at production volume. Worth auditing which of your other integrations are still on a deprecation clock you have not checked recently.