On this page · 11 sections
Summary. Google shuts down all three Imagen 4 models, imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001, on 17 August 2026, twelve days from now. The Gemini API deprecations table names gemini-3.1-flash-image as the recommended replacement. Google's own Imagen documentation page, last updated 16 July 2026, names a different one: "Use gemini-2.5-flash-image instead of Imagen model names." Follow that second instruction and you land on a model with its own shutdown date of 2 October 2026, a second migration 46 days after the first. The code change is three breaking edits: client.models.generate_images() becomes client.models.generate_content(), images arrive as content parts rather than in a generated_images array, and number_of_images (default 4, range 1–4) does not exist on Gemini image models, so one call now produces one image. On cost, gemini-3.1-flash-image bills image output at $60.00 per 1M tokens, which Google works out to $0.045 per 0.5K image, $0.067 per 1K image, $0.101 per 2K and $0.151 per 4K. The batch tier halves that to $0.034 per 1K image, and gemini-3.1-flash-lite-image lists $0.0336 per 1K image on the standard tier. Imagen 4's own prices are no longer published on the Gemini API pricing page at all.
Two other Gemini API shutdowns land in the same window and are easy to miss while you are looking at images: embedding-2-preview on 10 August 2026, and gemini-robotics-er-1.6-preview on 31 August 2026.
Which replacement model is actually correct
This is the part to get right before you write any code, because Google's documentation gives two different answers.
The deprecations page, which is the page Google explicitly designates as the tracker, "the announced earliest shutdown dates are tracked on this page", lists all three Imagen 4 models with a shutdown date of 17 August 2026 and a recommended replacement of gemini-3.1-flash-image. That model has no shutdown date announced.
The Imagen guide page says something else. Its "Migration to Nano Banana" section instructs: "Model name: Use gemini-2.5-flash-image instead of Imagen model names." But the same deprecations table lists gemini-2.5-flash-image with a shutdown date of 2 October 2026 and a recommended replacement of gemini-3.1-flash-image-preview.
| Model | Status per the deprecations table | Shutdown date | Verdict |
|---|---|---|---|
imagen-4.0-generate-001 |
Deprecated | 17 August 2026 | Must move |
imagen-4.0-ultra-generate-001 |
Deprecated | 17 August 2026 | Must move |
imagen-4.0-fast-generate-001 |
Deprecated | 17 August 2026 | Must move |
gemini-2.5-flash-image |
Deprecated | 2 October 2026 | Named by the Imagen guide, do not migrate here |
gemini-3.1-flash-image |
Released 28 May 2026 | No shutdown date announced | The correct target |
gemini-3.1-flash-lite-image |
Listed on the pricing page as the efficiency model | No shutdown date announced | The correct target for high-volume, cost-sensitive work |
Migrate to gemini-3.1-flash-image or gemini-3.1-flash-lite-image. Treat the Imagen guide's gemini-2.5-flash-image line as stale documentation, not guidance. A stale doc page is the most expensive kind of bug on a deadline, because it looks authoritative and it costs you the whole migration twice.
One caveat worth stating plainly. Google's deprecations page carries a note that the listed dates "indicate the earliest possible dates on which a model might be retired" and that "We will communicate the exact shutdown date to users with advance notice." That softens the date in theory. It is not a reason to plan past 17 August.
The three breaking changes
Here is the Imagen 4 call as Google's own documentation writes it, with number_of_images set to 4:
from google import genai
from google.genai import types
client = genai.Client()
response = client.models.generate_images(
model='imagen-4.0-generate-001',
prompt='Robot holding a red skateboard',
config=types.GenerateImagesConfig(
number_of_images=4,
)
)
for generated_image in response.generated_images:
generated_image.image.show()
Three things in that snippet stop working.
The method changes. client.models.generate_images becomes client.models.generate_content. This is not an alias; the Imagen path used a :predict endpoint (https://generativelanguage.googleapis.com/v1beta/models/imagen-4.0-generate-001:predict) with an instances/parameters request body, and the Gemini path uses standard content generation.
The response shape changes. Google states it as "Nano Banana returns content parts, which may include image data, instead of a specific image response object." In practice that means walking response.candidates[0].content.parts and checking each part for inline_data. Code that reads response.generated_images throws an attribute error rather than returning an empty list, so this fails loudly, which is the one piece of good news here.
`number_of_images` is gone. On Imagen 4 the parameter accepted 1 to 4 and defaulted to 4. On the Gemini image models there is no equivalent, and a call returns one image. Every batch of N becomes N calls.
The replacement shape:
import PIL.Image
from io import BytesIO
from google import genai
client = genai.Client()
response = client.models.generate_content(
model="gemini-3.1-flash-image",
contents=["Robot holding a red skateboard"],
)
for part in response.candidates[0].content.parts:
if part.text is not None:
print(part.text)
elif part.inline_data is not None:
image = PIL.Image.open(BytesIO(part.inline_data.data))
image.save("generated_image.png")
Note the part.text branch. Gemini image models can interleave text with images, so a parts loop that assumes every part is an image will crash on the first commentary token. Handle both.
A drop-in replacement for number_of_images
If your pipeline asked for four variants per prompt, you now need a fan-out. This helper keeps the old call signature so the rest of your code does not change, runs the calls concurrently, and returns the images in a list the way generated_images used to.
import concurrent.futures
from io import BytesIO
from google import genai
client = genai.Client()
MODEL = "gemini-3.1-flash-image"
def _one_image(prompt: str, model: str = MODEL) -> bytes | None:
"""Return raw PNG bytes for a single generation, or None if the model
returned only text (a refusal or a safety block)."""
response = client.models.generate_content(model=model, contents=[prompt])
for part in response.candidates[0].content.parts:
if getattr(part, "inline_data", None) is not None:
return part.inline_data.data
return None
def generate_images(prompt: str, number_of_images: int = 4,
model: str = MODEL) -> list[bytes]:
"""Fan-out replacement for the removed number_of_images parameter.
Returns fewer than number_of_images if any call produced no image."""
if not 1 <= number_of_images <= 8:
raise ValueError("keep the fan-out small; each call bills separately")
with concurrent.futures.ThreadPoolExecutor(max_workers=number_of_images) as pool:
futures = [pool.submit(_one_image, prompt, model)
for _ in range(number_of_images)]
results = [f.result() for f in futures]
return [r for r in results if r is not None]
Two deliberate choices there. It returns a possibly-shorter list rather than padding, because a safety block or a text-only response is a real outcome your caller needs to see rather than a silent retry loop. And it caps the fan-out, because the thing that used to be one billable request is now N billable requests and an unbounded loop is how a test script turns into an invoice.
The cost math
The prices below are as listed on the Gemini API pricing page in August 2026.
| Model and tier | Image output rate | Per 1K (1024x1024) image | Text and thinking output | Input |
|---|---|---|---|---|
gemini-3.1-flash-image, standard |
$60.00 per 1M tokens | $0.067 (1,120 tokens) | $3.00 per 1M | $0.50 per 1M (text/image) |
gemini-3.1-flash-image, batch |
$30.00 per 1M tokens | $0.034 | $1.50 per 1M | $0.25 per 1M |
gemini-3.1-flash-lite-image, standard |
$30.00 per 1M tokens | $0.0336 | $1.50 per 1M | $0.25 per 1M (text/image/video) |
gemini-3.1-flash-image, 0.5K (512px) |
$60.00 per 1M tokens | $0.045 (747 tokens) | , | , |
gemini-3.1-flash-image, 2K (2048x2048) |
$60.00 per 1M tokens | $0.101 (1,680 tokens) | — | — |
gemini-3.1-flash-image, 4K (4096x4096) |
$60.00 per 1M tokens | $0.151 (2,520 tokens) | — | — |
Three observations that matter more than the headline rate.
Resolution is the biggest lever you control. Going from 4K to 1K on the same model cuts the per-image cost from $0.151 to $0.067, a 56% reduction, because the image consumes 1,120 output tokens instead of 2,520. Most pipelines generating thumbnails, product tiles or social crops are paying 4K rates for assets that get downsampled anyway. Audit your image_size before you audit anything else.
Batch is half price and most image pipelines are batchable. Standard 1K at $0.067 becomes $0.034 on the batch tier. If your generation is a nightly job, a content pipeline or anything that does not need a synchronous response, that is a 49% saving for a scheduling change.
The fan-out has an input-token cost. Under Imagen 4, one call with number_of_images=4 sent the prompt once. Under the Gemini models, four calls send the prompt four times, each billing input at $0.50 per 1M tokens on the standard tier. For a short prompt that is negligible; for a pipeline that sends a long style guide or reference images with every request, it is four times the input bill for the same four outputs. Where you are generating variants of the same prompt, that repeated input is the line item to check.
Imagen 4's own per-image prices are no longer on the Gemini API pricing page, which lists Imagen only as a navigation link with no rate table. You cannot look up what you are currently paying from the primary source, so pull the actual figure from your billing console rather than a third-party comparison page.
What you lose, and what you gain
The migration is not purely a rename, and some Imagen-specific configuration has no direct successor in the same form.
| Imagen 4 capability | Detail as documented | After migration |
|---|---|---|
numberOfImages |
1 to 4, default 4 | No equivalent; fan out in application code |
imageSize |
1K and 2K, Standard and Ultra models only |
Gemini image models are priced at 0.5K, 1K, 2K and 4K, so 4K becomes available |
aspectRatio |
"1:1", "3:4", "4:3", "9:16", "16:9", default "1:1" |
Check the image generation guide for the current parameter before assuming parity |
personGeneration |
"dont_allow", "allow_adult" (default), "allow_all" |
Verify the equivalent control; "allow_all" was already blocked in EU, UK, CH and MENA locations |
| Prompt length | Maximum 480 tokens, English only | Gemini image models are general multimodal models, not subject to the Imagen text-only limit |
| SynthID | "All generated images include a SynthID watermark" | Verify watermarking behaviour on the target model before shipping regulated content |
| Response object | response.generated_images[].image |
response.candidates[0].content.parts[].inline_data |
The gains are real. You get 4K output, which Imagen 4 did not offer through this API — its imageSize topped out at 2K. You get interleaved text and image responses, which makes conversational editing possible in a way the predict-style endpoint did not. And you get a cheaper per-image floor via the lite model and the batch tier.
The losses are mostly ergonomic. Losing number_of_images is the one that touches real code, and the fan-out above closes it.
A twelve-day plan
Twelve days from 5 August 2026. This is small enough to be done inside one sprint if it is started now.
| Days | Action | Exit criteria |
|---|---|---|
| 1 | Grep for generate_images, generateImages, GenerateImages, imagen-4.0, generated_images and :predict across every repository, notebook and scheduled job |
A list of call sites with an owner each |
| 1 | Pull last month's image counts and resolutions from billing; decide the target model and tier per pipeline | A written before/after cost estimate |
| 2–4 | Swap the method and the response parsing; add the fan-out helper where number_of_images was used; handle the part.text branch |
Unit tests pass against the new response shape |
| 5–7 | Verify the parameters you relied on — aspect ratio, resolution, person generation, watermarking — against the image generation guide on the target model | A parity checklist with a pass or an accepted difference per row |
| 8–10 | Run both paths side by side on a sample workload; compare output quality, latency and per-image cost | Quality signed off by whoever owns the output |
| 11–12 | Cut over, delete the Imagen path, and alert on any non-image response | No imagen-4.0 string anywhere in the codebase |
| Also by 10 August | Check for embedding-2-preview usage — it shuts down that day, replaced by gemini-embedding-2 |
Embedding calls confirmed on a supported model |
The last row is the one that catches people. Teams doing an image migration in the first half of August will not be looking at their embedding model, and embedding-2-preview goes five days before Imagen does.
India-specific considerations
For teams in Gurugram, Bengaluru, Pune and Hyderabad running image generation at volume for D2C catalogues, marketplace listings or ad creative, three points apply.
The batch tier is the single largest saving available and it fits Indian catalogue workflows well. Product imagery for a listing refresh does not need a synchronous response. Moving that generation to batch takes a 1K image from $0.067 to $0.034, and at catalogue scale — tens of thousands of images per refresh cycle — that difference is the entire argument for scheduling the job overnight rather than generating on upload.
Resolution discipline matters more here than in most markets, because marketplace and quick-commerce listing specs are modest. If your target surface renders at 1024px or below, generating at 4K and downsampling costs $0.151 instead of $0.067 for an asset nobody sees at full resolution.
On governance, personGeneration on Imagen 4 had a documented regional restriction — "allow_all" was "not allowed in EU, UK, CH, MENA locations" — and any equivalent control on the target model needs to be verified rather than assumed, particularly if you generate imagery depicting people for campaigns that run across those regions. Where generated imagery is derived from customer photographs or user-submitted references, the Digital Personal Data Protection Act 2023 obligations attached to that source data follow it into the generation pipeline, so keep the reference store governed the same way as the rest of your customer data.
The pattern worth noticing
This is the second image-model migration in roughly a year for anyone who was on Imagen 3, which the same documentation records as already shut down. The Gemini API deprecations page shows the cadence clearly: preview models routinely carry shutdown dates a few months out, and even GA models get them. gemini-2.5-flash-image, released 2 October 2025, has a shutdown date exactly one year later.
The practical response is architectural rather than tactical. Put the model ID in configuration, not in a call site. Wrap generation behind one function with a stable signature — the fan-out helper above is a start — so that the next deprecation is a config change and a parsing tweak rather than a search through six repositories. Teams that did this after the Imagen 3 shutdown will spend an afternoon on 17 August. Teams that did not will spend the week.
FAQ
How eCorpIT can help
We run image and model migrations like this one for teams that discovered the deadline late: inventory the call sites, model the per-image cost against your real resolution mix, swap the call and the parsing, and verify parameter parity before cutover rather than after. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and our senior engineering teams design generation pipelines aligned with DPDP requirements. If 17 August is on your calendar without an owner, talk to us.
Related reading: our AI image generation API cost comparison sets these rates against the other providers, the Nano Banana 2 versus Nano Banana Pro production comparison covers model selection for production work, the Gemini video generation cost guide applies the same per-token arithmetic to video, and the frontier model comparison is the pillar for this cluster.
References
Last updated: 5 August 2026.