Google retires every Imagen model on June 24 — and the Gemini image migration fails silently in 4 places

On June 24, 2026, Google shuts down every remaining Imagen model on the Gemini API:

• imagen-4.0-generate-001
• imagen-4.0-ultra-generate-001
• imagen-4.0-fast-generate-001

(imagen-3.0-generate-002 already went dark on November 10, 2025 — if you somehow survived that one, you were already on borrowed time.)

The recommended replacement is gemini-2.5-flash-image — the model Google markets as "Nano Banana" — or gemini-3-pro-image-preview.

Here is the part that makes this dangerous. The retirement itself is loud: after June 24, a request to imagen-4.0-generate-001 returns an error, your pipeline throws, someone gets paged. That's fine. Loud failures get fixed.

The migration is not loud. Imagen and Gemini's image generation are not the same API with a different model string — they are two different request shapes, two different endpoints, and two different parameter vocabularies. And Gemini's image endpoint will happily accept a request full of Imagen-era parameters, ignore the ones it doesn't recognize, and return 200 OK with an image. Not the image you asked for. An image.

That's the trap. Teams will migrate under deadline pressure, see images come back, see green status codes, and ship. The defects land downstream, weeks later, with no error attached.

Here's the silent-fail surface.

1. The endpoint and response shape changed — and a half-migrated parser fails quiet

Imagen runs on the :predict endpoint. You send instances and parameters, and you get back:

{ "predictions": [ { "bytesBase64Encoded": "...", "mimeType": "image/png" } ] }

Gemini image generation runs on :generateContent. You send contents with parts, and the image comes back at:

{ "candidates": [ { "content": { "parts": [ { "inlineData": { "data": "...", "mimeType": "image/png" } } ] } } ] }

If you point your code at the new model but keep calling :predict, you get a loud error — good. But the failure that actually ships is the half migration: you move to :generateContent, and a downstream helper still reaches for response.predictions[0].bytesBase64Encoded.

That path doesn't exist on a Gemini response. In JavaScript it evaluates to undefined. In Python it's a KeyError only if you index hard — and most image-handling code doesn't, because it was written defensively:

img = resp.get("predictions", [{}])[0].get("bytesBase64Encoded")
if img:
    save(img)

predictions is missing, so img is None, so the if is skipped. No exception. No image written. 200 OK logged. The function returns cleanly. You find out when someone notices the asset bucket stopped filling — and by then you can't tell which day it started.

2. sampleCount is gone — your batch silently collapses to one image per call

This is the sharpest one.

Imagen's :predict request takes a sampleCount parameter: ask for up to 4 images in a single call (imagen-4.0-generate-001), or 1 at a time on the Ultra tier. Plenty of pipelines lean on this — generate 4 candidates per prompt, score them, keep the best. The sampleCount: 4 is load-bearing.

Gemini's image API has no sampleCount. It generates one image per call, and Google's own documentation is blunt about it: "The model won't always follow the exact number of image outputs that the user explicitly asks for."

So when your migrated request carries sampleCount: 4 — or you ask conversationally for "four variations" — Gemini doesn't error. It returns one image, 200 OK. Your candidate pool just dropped from 4 to 1. The "pick the best of 4" step still runs; it's now picking the best of 1. Output quality quietly degrades, throughput math is off by 4×, and nothing in the response says "you asked for four and got one."

If any part of your system reasons about how many images it gets back, that assumption is now wrong, and it's wrong silently.

3. Aspect ratio moved namespaces — and became a suggestion

Imagen takes aspectRatio as a top-level entry in parameters, and it's a hard constraint: ask for 16:9, get 16:9.

On Gemini image generation, aspect ratio is not a top-level parameter. It lives nested inside an image-config block on the generation config. Carry the Imagen-style top-level aspectRatio field straight over and it lands nowhere — it's an unrecognized key, silently dropped, and Gemini falls back to its default (square, or whatever it infers from the prompt).

Result: 200 OK, a perfectly valid image, in the wrong dimensions. Every downstream consumer that assumed a fixed aspect ratio — a CSS grid, a video frame, a thumbnail cropper, a print layout — now gets a shape it wasn't built for. Best case it looks wrong. Worst case the cropper "fixes" it by cutting the subject's head off, automatically, with no error.

And even when you do nest the field correctly, treat it as a strong hint rather than a guarantee. There are documented reports of Gemini image models returning a 1:1 square for an explicit 16:9 request. Validate the dimensions of what comes back; don't trust that you got what you asked for.

4. personGeneration has no clean equivalent — your safety posture shifts without a diff

Imagen exposes a personGeneration parameter: dont_allow, allow_adult, allow_all. Teams set this deliberately — a kids' education product pins dont_allow; an internal tool runs allow_all. It's a compliance decision, often written down in a review somewhere.

Gemini's image API doesn't have a personGeneration knob in that shape. It folds people-generation behavior into the general model safety stack. So personGeneration on a migrated request is — you'll notice the pattern by now — an unrecognized key, silently dropped.

What you're left with is Gemini's default people-generation behavior, which is not guaranteed to match the Imagen setting you carefully chose. A pipeline pinned to dont_allow may start returning images with people in them. A pipeline that relied on allow_all may start refusing prompts it used to honor. Either way, 200 OK, no warning, and a safety/compliance posture that changed without anyone editing the line that used to control it. This is the surface a security review would actually care about, and it has no error and no schema diff to catch.

5. The two things to also budget for

Prompt rewriting. Imagen runs an LLM-based prompt rewriter by default — it silently expands your terse prompt before generating. Gemini handles prompts natively and differently. Migrate, send the byte-identical prompt, and the image style, composition, and detail level shift — because the prewriting layer your results were implicitly tuned against is gone. Nothing breaks; your outputs just drift. If you have a brand or style baseline, re-approve it after migrating.

Mask-based editing has no replacement. This is the migration some teams can't actually make. Imagen's capability/editing model does precise, programmatic mask-based inpainting and outpainting — you supply a reference image plus a mask, and edits land exactly inside the mask. Gemini 2.5 Flash Image does conversational editing: you describe the change in words. There is no pixel-precise mask parameter. If you have a pipeline that does deterministic mask-driven edits — product photography, automated retouching, compositing — there is no drop-in path. Find this out now, in June, not in a sprint planning meeting in July.

What to actually do

1. Grep for the dead model IDs across everything — app code, IaC, notebooks, prompt configs, batch-job definitions:

   git grep -nE "imagen-(4\.0-(generate|ultra-generate|fast-generate)-001|3\.0)"

1. Treat this as a rewrite, not a string swap. The endpoint, request shape, and response shape all change. Budget for it like the API migration it is.

2. Audit every Imagen-era parameter against the new API. Make a literal checklist: sampleCount, aspectRatio, personGeneration, prompt-rewrite behavior. For each, confirm it either has a real equivalent you've wired up, or accept — explicitly, in writing — that you're losing it. The danger is the parameter you neither migrate nor consciously drop.

3. Assert on the response, don't assume it. After migrating, check the count of images returned and the dimensions of each one against what you requested. Both can silently differ. A three-line assertion catches sections 2 and 3 of this post.

4. Re-approve your output baseline. Prompt rewriting is gone and the underlying model is different. Whatever "looks right" meant for your product, re-establish it against real Gemini output before June 24 — not after.

The model retirement is the loud part, and the loud part will get handled. The migration is the quiet part. Plan for the quiet part.

FlareCanary watches your third-party APIs and SDKs for breaking changes like this one — model retirements, response-shape changes, and silently-dropped parameters — and surfaces them before they reach production. Free tier monitors 5 endpoints.