Imagen 4 shut down today: which target to migrate to, and why the newest API blocks the cheapest price
The three imagen-4.0 endpoints stopped serving on August 17. Google's docs point at three different replacements across three pages, and the per-image prices between them differ by about 4x. The migration that looks most current also gives up the Batch API and explicit caching, which is where the discount lives. Here is the decision, with verified code for both paths.
If you call image generation on the Gemini API, three model IDs stopped serving today:
imagen-4.0-generate-001
imagen-4.0-fast-generate-001
imagen-4.0-ultra-generate-001
Google's changelog puts the deprecation on June 15, 2026 and the shutdown on August 17, 2026. Shutdown means the request fails. There is no degraded tier, no automatic reroute to a successor, and no grace behavior where an old ID quietly resolves to a new model.
The part worth ten minutes of your afternoon is not the date. It is that the replacement is not a string swap, the docs name three different successors depending on which page you land on, and the per-image price between the plausible targets varies by roughly 4x.
The method disappears, not just the model
The first thing that breaks is one level below the model ID. Imagen on the Gemini API is reached through a dedicated method:
response = client.models.generate_images(
model='imagen-4.0-generate-001',
prompt='Robot holding a red skateboard',
config=types.GenerateImagesConfig(
number_of_images=4,
)
)
That is the sample still printed on Google's Imagen page, and it names one of the models that shut down today. Check the models list for what is left to pass into that method: the only Imagen entry on it is the deprecated Imagen 4 row. Every current image model on the Gemini API is a Gemini model, and Gemini models are not reached through generate_images.
So a migration plan that consists of finding a new model ID has nothing to put in the call. The call itself goes away.
Three pages, three answers
This is where a straightforward afternoon turns into a migration you do twice. Each of these is live Google documentation as of today:
- The Imagen page carries the banner "This model is deprecated and will be shut down on August 17, 2026; migrate to Nano Banana for image generation," and its replacement example uses
gemini-2.5-flash-imagethroughgenerate_content(). - The deprecations table lists all three Imagen 4 variants with a single replacement column:
gemini-3.1-flash-image. - The image generation page documents neither of those call styles. It uses
client.interactions.create(), and aboutgemini-2.5-flash-imageit says: "While it has been a reliable workhorse, we strongly recommend that customers transition to Nano Banana 2 Lite to experience enhanced quality, faster generation speeds, and lower API pricing."
Follow the banner on the Imagen page and you land on a model that the image generation page tells you to leave, through a method that the current docs no longer teach. That is the migration you get to redo in a quarter.
The four current image models, with the marketing names the docs use interchangeably with the IDs:
| Model ID | Docs name |
|---|---|
gemini-3.1-flash-lite-image | Nano Banana 2 Lite |
gemini-3.1-flash-image | Nano Banana 2 |
gemini-3-pro-image | Nano Banana Pro |
gemini-2.5-flash-image | Nano Banana |
Run the price before you pick
Imagen 4 was billed per image, flat: $0.02 for Fast, $0.04 for Standard, $0.06 for Ultra. The Gemini image models are billed per million output image tokens, and the pricing page publishes the per-image equivalents alongside, which is what makes the comparison checkable rather than a guess.
Per image at 1K resolution, standard and batch:
| Model | Standard | Batch |
|---|---|---|
gemini-3.1-flash-lite-image | $0.0336 | $0.0168 |
gemini-3.1-flash-image | $0.067 | $0.034 |
gemini-3-pro-image | $0.134 | $0.067 |
Two things fall out of that table. The replacement named in the deprecations column, gemini-3.1-flash-image, costs $0.067 per 1K image, which is more than three times what Imagen 4 Fast cost and about 1.7x Imagen 4 Standard. The cheapest correct path, gemini-3.1-flash-lite-image submitted through the Batch API at $0.0168, comes in below what you were paying for Imagen 4 Fast. Between those two is a spread near 4x on identical output resolution.
Resolution is a live cost lever too, and it was not one on Imagen 4. On gemini-3.1-flash-image the same model runs $0.045 at 0.5K, $0.067 at 1K, $0.101 at 2K and $0.151 at 4K. If your pipeline resizes generated images down before they are ever displayed, the resolution you request is now a line item.
The newest API is the one that cannot reach the discount
The trade below is the one most likely to get walked into backwards.
The Interactions API went generally available in June 2026 and is what the current image generation docs teach. The Interactions overview is direct about the older surface: "While it is now considered legacy, the original generateContent API remains fully supported." Reading that, migrating a dying integration straight onto the new surface looks like the obvious move.
The same page lists what the new surface does not have yet. Quoted from it, the features supported by generateContent but "not yet available" in the Interactions API:
- Video metadata (clipping intervals and custom frame rates)
- Batch API
- Automatic function calling (Python)
- Explicit caching, with the note that server-side implicit caching is available through
previous_interaction_id - Custom safety settings
Two entries on that list are cost levers. The Batch API runs at "50% of the standard cost" with a target turnaround of 24 hours, and its own docs state the constraint plainly: "This feature is currently only available with the generateContent API." That is the one that decides the price of a bulk image pipeline.
Explicit caching is the second, and it bites a narrower case: image requests that resend a long style guide, a set of brand rules, or the same reference images on every call. Implicit caching still applies through previous_interaction_id, but you no longer control what is cached or for how long. Either way the billing failure is quiet rather than loud, which is the pattern behind prompt cache silent misses.
So the decision is not new-versus-legacy. It splits on whether your image generation is something a user waits for:
Offline or bulk generation — catalog images, thumbnail backfills, variant sweeps, anything a queue can own for a few hours. Stay on generate_content and submit through batches.create. That is the only path to the halved rate, and it is what makes Lite cheaper than the Imagen 4 tier you left.
Interactive generation — a user typed a prompt and is watching a spinner. Batch is irrelevant at 24-hour turnaround, so the Interactions API is the right target and you lose nothing you were using.
Mixed workloads are common and are fine to split. The models are the same either way.
Working code for both paths
Interactive, on the Interactions API. Both SDKs need version 2.3.0 or later (google-genai for Python, @google/genai for JavaScript):
from google import genai
import base64
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.1-flash-image",
input="Create a picture of a nano banana dish in a fancy restaurant",
)
with open("generated_image.png", "wb") as f:
f.write(base64.b64decode(interaction.output_image.data))
import { GoogleGenAI } from "@google/genai";
import * as fs from "node:fs";
const ai = new GoogleGenAI({});
const interaction = await ai.interactions.create({
model: "gemini-3.1-flash-image",
input: "Create a picture of a nano banana dish in a fancy restaurant",
});
const generatedImage = interaction.output_image;
if (generatedImage) {
fs.writeFileSync("gemini-native-image.png", Buffer.from(generatedImage.data, "base64"));
}
Note what replaced what: contents became input, generation settings moved from nested config up to top-level parameters, and the image arrives base64-encoded on interaction.output_image.data rather than as a part you walk to.
Bulk, through Batch on generateContent. Image output is not the default on a Gemini model, so response_modalities has to ask for it:
from google import genai
client = genai.Client()
inline_requests = [
{
'contents': [{'parts': [{'text': 'A big letter A surrounded by animals starting with the A letter'}]}],
'config': {'response_modalities': ['TEXT', 'IMAGE']}
},
{
'contents': [{'parts': [{'text': 'A big letter B surrounded by animals starting with the B letter'}]}],
'config': {'response_modalities': ['TEXT', 'IMAGE']}
}
]
inline_batch_job = client.batches.create(
model="gemini-3-pro-image-preview",
src=inline_requests,
config={'display_name': "inlined-image-requests-job-1"},
)
Images come back off the response parts with part.as_image(). One caution on the model ID: the batch docs run their image example on gemini-3-pro-image-preview, the priciest of the four and a preview string, while the pricing page publishes Batch Output rates for the flash-image and flash-lite-image IDs. Confirm your chosen ID returns a batch job before you queue ten thousand requests against it.
Find the callers before you fix them
The IDs are dead already, so this sweep is triage rather than prevention. Start with the obvious pass:
rg -n "imagen-4\.0|generate_images|generateImages" \
--glob '!node_modules' --glob '!*.lock'
Application code is the easy half. The calls that go unnoticed for weeks are the ones nobody watches: a scheduled job that regenerates assets, a seeding script, a notebook someone runs monthly, an eval harness, a Cloud Function with its own copy of the client. Broaden the sweep to environment variables and config, where a model ID is often a string that never appears next to the word imagen:
rg -n "IMAGE_MODEL|IMAGEN|image_model" --glob '!node_modules'
The general habit of knowing which model IDs your code names, and which retirement dates are already on the calendar, is the one we laid out in model IDs change under you. Today is that pattern arriving with a method removal attached.
One more date from the same changelog while you are in there: gemini-robotics-er-1.6-preview shuts down on August 31, 2026, with gemini-robotics-er-2-preview as the replacement. Two weeks out, and the same rule applies. Confirm the successor's call shape, not only its name.
If you want the wider view of what a published per-token or per-image rate does and does not commit a vendor to, the price per million tokens now carries conditions covers the four kinds of condition that showed up this month. Gemini's tool page tracks the current model line and pricing.
Get the next post when it ships
One email on Sunday with the new post and a short list of what shipped that week — new guides, tool updates, and a couple of links worth reading.