Imagen Is Retired: Migrating Your Prompts to Nano Banana

TL;DR: Google shut down the Imagen 4 endpoints on the Gemini API on August 17, 2026 and points migrations at the Nano Banana models. It is an API retirement, not a product-wide one, and it does not touch images you already generated. The hard part is not the model string. It is that Imagen prompt style does not transfer.

Most of the coverage of this retirement told you to swap imagen-4.0-generate-001 for a Gemini model ID and move on. That is the easy ten minutes. The part that eats a week is the prompt library you built against Imagen, because Imagen and Nano Banana read prompts in fundamentally different ways, and half your parameters no longer exist. This guide is the conversion table.

What is the Imagen replacement?

The Imagen replacement is the Gemini 3.x image family, which Google markets as Nano Banana. Google's own deprecation table names gemini-3.1-flash-image as the recommended replacement for all three retired Imagen 4 endpoints (Gemini deprecations, accessed August 26, 2026).

Three models carry the brand, and the naming is genuinely confusing, so here is the mapping in one place:

Source: Gemini API models and the API changelog, both accessed August 26, 2026.

What exactly shut down on August 17, and what did not?

Three endpoints on the Gemini API shut down: imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001. Google announced the deprecation in the API changelog on June 15, 2026 and set the shutdown for August 17, 2026.

This is the detail most write-ups skipped, and it matters if you are trying to work out whether you are affected. Imagen retired on more than one track, with more than one date:

The Gemini API (ai.google.dev). Deprecation announced June 15, 2026. Shutdown date August 17, 2026. This is the dated event everyone wrote about. Google's models page now labels the entry "Imagen 4 (Deprecated)".

Firebase AI Logic. Broader scope and softer wording: "All Imagen models are deprecated and will shut down as early as August 17, 2026" (Firebase migration guide, accessed August 26, 2026). Note "as early as", which matches Google's stated policy that published shutdown dates are the earliest possible retirement date, not a guaranteed one.

Vertex AI, now Gemini Enterprise Agent Platform. A separate and earlier notice. The Vertex release notes carry a March 24, 2026 entry deprecating the older image generation endpoints, including imagegeneration@002 through @006 and the imagen-3.0 and imagen-4.0 variants, with the recommendation to update endpoints "before June 30, 2026" (Vertex AI release notes, accessed August 26, 2026). If you are on Vertex, your deadline was two months before the one in the headlines.

One nuance worth holding onto, because it changes how you should read every future date on that page. Google's deprecation policy says the published dates "indicate the earliest possible dates on which a model might be retired" and that it will "communicate the exact shutdown date to users with advance notice". So August 17 was a floor, not a promise. In practice that means two things: do not build a plan that assumes you get extra time, and do not assume an endpoint is definitely dead just because the listed date has passed. Test it, rather than reasoning about it.

Consumer surfaces are a different question entirely. Nano Banana Pro has been available "across Google products like the Gemini app, Google Ads, and Google AI Studio" since launch (Google blog). Those surfaces migrated as product updates, not as a dated shutdown, and there is no published retirement notice for Imagen inside Google Labs tools. If you generate images by typing into the Gemini app, nothing happened to you on August 17.

Are my already-generated Imagen images affected?

No. Google defines a shutdown narrowly: "Once a model is 'shutdown', it is completely turned off, and the endpoint is no longer available." The definition covers the endpoint. It says nothing about output, and Google has published nothing suggesting previously generated images are revoked, relicensed, or deleted.

Files you downloaded are yours and are unaffected. Files sitting in a bucket you control are unaffected.

One real exception: anything you left in the Gemini Files API. That service deletes uploads after 48 hours by design, on every model, retirement or not. If your pipeline generated images and left them in Files rather than persisting them, you lost those to the retention policy long before you lost the endpoint.

How do I know whether I was affected?

Three checks, in order, and none of them take longer than a few minutes.

Check what you call, not what you think you call. Search your codebase and your infrastructure for the literal string imagen-. Pinned model IDs hide in config files, environment variables, Terraform, and notebooks that nobody has opened since spring. A retired model ID typically fails at the request layer rather than degrading, so a single missed call site is a broken feature, not a slightly worse image.

Check which platform you are on. The same Imagen model name existed on both the Gemini API and Vertex AI, and they ran on different retirement schedules. If your credentials are a Google Cloud service account and your endpoint is a Vertex regional URL, the March 2026 notice and its June 30 deadline were yours. If you authenticate with a Gemini API key, August 17 was yours.

Check whether you inherited Imagen indirectly. If you build on Firebase AI Logic, a wrapper SDK, or a low-code tool that generates images for you, the Imagen dependency may not appear anywhere in your code. Ask the vendor which model backs their image endpoint and what date they migrated. That answer is worth having in writing.

Which Nano Banana model replaces which Imagen model?

Google publishes an explicit one-to-one mapping in the Firebase migration guide, and it is the closest thing to an official answer:

Source: Migrate from Imagen to a Gemini Image model, accessed August 26, 2026.

The interesting move is that Imagen's Fast and Standard tiers collapse into one model, separated by a thinking_level parameter rather than a separate endpoint. Your old speed-versus-quality decision is now a request field. That is strictly better for A/B work, because you can flip it per call instead of maintaining two code paths.

It also has a cost consequence people miss. On Imagen, moving from Fast to Standard doubled the per-image price, from $0.02 to $0.04. On gemini-3.1-flash-image, both settings sit on the same per-image rate for a given resolution, and thinking is spent as reasoning tokens rather than as a different sticker price. So the honest test order is: try MINIMAL first, raise to HIGH only where the output visibly needs it, and only reach for Nano Banana Pro when a specific capability demands it. A surprising share of migrations jump straight to Pro on the assumption that Ultra maps to Pro and everything else should follow, then wonder why the bill roughly tripled.

How do Imagen prompt patterns translate to Nano Banana?

This is the migration that actually costs time. Imagen was a dedicated text-to-image model that responded well to comma-separated descriptor stacks, the same dialect you use in Midjourney. Nano Banana is a Gemini model doing image generation. It parses grammar, follows instructions, and can reason before it renders. Feed it a keyword pile and you have handed a capable model a vague brief.

Here is the conversion table. Left column is the habit, right column is what to do now.

Sources: Firebase migration guide, Gemini image generation docs and the Nano Banana Pro developer post, all accessed August 26, 2026.

The single highest-leverage change is the first row. Here is what that looks like in practice on a product shot.

BEFORE (Imagen dialect, will underperform on Nano Banana):

matte black ceramic coffee mug, product photography, studio lighting,
softbox, seamless white background, 85mm lens, shallow depth of field,
commercial, 8k, ultra detailed, award winning, hyperrealistic

AFTER (Nano Banana dialect):

A matte black ceramic coffee mug photographed on a seamless white
sweep. A single large softbox sits camera-left at 45 degrees, producing
one soft highlight down the left edge of the mug and a gentle falloff
into shadow on the right. Shot on an 85mm lens at f/4, so the rim of
the mug is sharp and the background falls away cleanly. The handle
faces camera-right. No props, no text, no reflections on the sweep.

The second version is longer, which feels wrong if you came from keyword-stack prompting. It works better because every clause is doing a job the model can act on. If you want the underlying method for turning a reference image into a brief like that, our guide on reverse-engineering an AI image into a reusable prompt walks through the interrogation order.

Here is a reusable skeleton. Keep it as a prompt template and refill the bracketed fields.

[SUBJECT: one sentence, concrete nouns, no adjective pileup]

[SETTING: where it sits, what surface, what is behind it]

[LIGHT: source, direction, quality, where the highlight and shadow land]

[CAMERA: lens length, aperture, height, angle relative to subject]

[MATERIAL: how each surface should read: matte, brushed, wet, worn]

[TEXT: exact string in quotes, and where it appears. Omit if none.]

[EXCLUSIONS as positives: state the clean version of what you don't want]

And the call itself, which is where most migrations break:

# OLD: Imagen. This endpoint is gone.
response = client.models.generate_images(
    model="imagen-4.0-generate-001",
    prompt=prompt,
    config=types.GenerateImagesConfig(
        number_of_images=4,
        aspect_ratio="16:9",
        person_generation="allow_adult",
    ),
)
image = response.generated_images[0].image

# NEW: Nano Banana Pro.
response = client.models.generate_content(
    model="gemini-3-pro-image",
    contents=prompt,
    config=types.GenerateContentConfig(
        response_modalities=["IMAGE"],
        image_config=types.ImageConfig(
            aspect_ratio="16:9",
            image_size="4K",
        ),
    ),
)
# Response is content parts, not a generated_images list.
for part in response.candidates[0].content.parts:
    if part.inline_data is not None:
        image_bytes = part.inline_data.data

Three things changed at once there: the method name, the config object, and the response shape. Your parser, your tests and your error handling all sit downstream of that third one.

What does not carry over from Imagen?

Four losses are worth planning around, because no amount of prompt rewriting recovers them.

Multiple images per call. Google is explicit: "Gemini Image models always return a single generated image." The suggested workaround is to loop. If your creative review process depended on picking one from four, you now pay four calls and manage four round trips. Budget for it.

Negative prompts. Gone, and Google notes they were already legacy and unsupported since imagen-3.0-generate-002. Any negativePrompt field in your library is dead weight.

Output format control. Imagen let you pick the encoding. Gemini image models return PNG. If a downstream service expected JPEG at a specific quality, that conversion is now your job.

Watermark opt-out. SynthID is applied to every image, with no flag to disable it. Google frames this as provenance rather than a setting.

There is a fifth item that is less a loss than a re-architecture. Imagen split generation and editing across separate endpoints, and Google's migration table maps the editing and customization model, imagen-3.0-capability-001, onto the same gemini-3.1-flash-image that replaces plain generation. One model now does both. If your pipeline branched on "am I generating or am I editing" and routed to different Imagen endpoints with different request shapes, that branch collapses into a single call where the difference is whether you attach an input image. Simpler to maintain, but it is a rewrite rather than a swap, and it is the piece most likely to be missed in an inventory that only greps for generation calls.

What does the migration cost?

More than Imagen did, in every configuration. This is the part vendors tend to leave out, and it is worth knowing before you commit.

Source: Gemini API pricing, accessed August 26, 2026. Batch API pricing runs at half the standard rate.

The like-for-like jump from Imagen 4 Fast to Nano Banana 2 at 1K is roughly three and a third times the per-image cost. Combine that with losing four-images-per-call and a high-volume pipeline can see a meaningfully larger increase than the sticker price suggests. Two mitigations are real: run non-interactive generation through the Batch API at half rate, and drop to 0.5K for thumbnails and internal previews, which Imagen never offered.

What do you actually gain?

Enough that the migration is worth doing properly rather than mechanically.

Text that renders. Google calls Nano Banana Pro's text rendering "state-of-the-art", producing "clear, accurate text integrated in your images". Every workaround you built to keep words out of Imagen output can be deleted, and a whole class of work you previously did in Figma moves into the prompt.

4K output. Imagen 4 capped at 2K. Nano Banana 2 and Nano Banana Pro both accept 4K. Note that "4K" is not one number: Google publishes a separate 4K pixel size for each of the ten aspect ratios, from 4096x4096 at 1:1 to 6336x2688 at 21:9. Size your output from the table, not from the square. Google frames it as meeting "resolution standards required for professional production".

Grounding with Google Search. Nano Banana Pro can retrieve real-time web content before generating. That turns a class of prompt that was previously impossible, such as a chart or infographic reflecting current data, into a single call.

Reference images at scale. Up to 14 standard inputs, with roughly six high-fidelity shots, and consistent resemblance for up to five individuals. Imagen 4's generate endpoint gave you prose and nothing else.

If you write descriptor-stack prompts because that is the dialect Midjourney taught you, the same rethink applies there in reverse: our Midjourney style modifier reference and its companion 50 tested v7 prompt examples are the right tools for a parameter-driven model, and our post on why Midjourney prompts fail covers the keyword-pile failure mode that Nano Banana punishes even harder. For structured, machine-parseable briefs, JSON prompting still applies to the text half of a multimodal request.

What should you do this week?

A five-step order of operations, cheapest first:

1. Inventory. Find every call site and every stored prompt that names an imagen- model. Include notebooks and cron jobs, not just application code.
2. Grep for the dead fields. negativePrompt, numberOfImages, sampleCount, personGeneration, addWatermark, plus any imageFormat assumption of JPEG.
3. Fix the response parser first. generate_images returns a generated_images list. generate_content returns content parts. This is the change that breaks silently in a try block and ships a null image.
4. Rewrite prompts in tiers. Your ten highest-volume prompts get the full sentence treatment from the table above. The long tail can run as-is and be fixed on complaint.
5. Re-baseline cost and quality together. Compare against the pricing table, and re-test thinking_level MINIMAL versus HIGH on gemini-3.1-flash-image before you assume you need Pro.

Step four is where a prompt library earns its keep. If your Imagen prompts live in scattered notebooks, Slack threads and a Notes file, you are rewriting from memory and you will miss half of them. If they live somewhere versioned and searchable, this migration is an afternoon of find-and-replace plus a review pass. That is the honest lesson of every model retirement, and there will be another one: gemini-2.5-flash-image has an October 2026 date on it already.