Google Veo and Imagen sunsets, and what replaced them

Two model families went dark on Google's Gemini API this summer, and the second one finished dying two days before this post went up. If you built anything directly against veo-2.0-generate-001, veo-3.0-generate-001, veo-3.0-fast-generate-001, or the imagen-4.0 family, those endpoints either already return errors or are about to. If you never touch a raw API and just use these models through a product, the story is different — and the gap between those two situations is the actual lesson here.

What Google announced, and when

Google's own Gemini API changelog is the record of record for this, and it shows two separate cleanup events on two separate clocks.

Veo 2.0 and 3.0, announced June 15, dead June 30. Google gave itself and everyone else just two weeks: veo-2.0-generate-001, veo-3.0-generate-001, and veo-3.0-fast-generate-001 were all marked for shutdown on June 30, 2026, with the changelog directing traffic to Veo 3.1. That's an unusually short runway for a production model family — enough time to swap a model string in a script, not enough time to requalify a whole pipeline against a new model's quirks if you hadn't already started.

Imagen 4.0, announced June 15, dead August 17. The imagen-4.0-generate-001, imagen-4.0-ultra-generate-001, and imagen-4.0-fast-generate-001 endpoints got the same announcement date but a much longer runway — deprecated June 15, shut down August 17, per the same changelog. That shutdown date is two days before this post publishes, which is the reason for writing it now instead of in June: the Veo cut was old news by the time most teams noticed it, but the Imagen cut is still fresh enough that pipelines are breaking this week.

Two different lead times for two families announced on the same day is worth noting on its own — nine weeks of runway for a widely embedded image model, two weeks for a video family Google clearly wanted off its books fast.

What's replacing them

The same changelog that announces the shutdowns also shows the landing spots. Video traffic gets pointed at Veo 3.1 directly. On the image and multimodal side, two replacements went generally available the same week the Veo cut landed: Nano Banana 2 Lite reached GA on June 30, 2026, alongside a Gemini Omni Flash preview, both logged in the same changelog entry. That's Google's consolidation story in one sentence — fewer standalone model families, more capability folded into the Nano Banana and Gemini Omni lines.

If you're deciding where to point traffic that used to go to Veo 2.0 or the old Imagen 4.0 endpoints, that's the shortlist: Veo 3.1 for video, and either Nano Banana 2 or Gemini Omni for image and multimodal generation, depending on which one your use case actually needs.

The part that surprises people: what's still live

Here's the gap. Google deprecating a Gemini API endpoint is a statement about Google's own first-party surface. A product catalog can lag that statement. Versely still listed an imagen-4 card after 17 August 2026. That is catalog lag, not a stay of execution. Do not start a new stills job on Imagen 4. Google's Imagen page (17 September 2026) says the family is shut down. The live Google still is Nano Banana 2. VEO 3.1 is the live Veo row. Imagen 4 is shut down. Use Banana 2 is the stills cutoff.

Conflating "Google deprecated a model" with "I lost access to a model" still matters for video: Veo 3.1 is the replacement, and it is in the catalog. It does not matter as an excuse to keep clicking Imagen 4. If a leftover slug still returns a file, that is serving lag. It is not a recommendation.

Versely's catalog also carries the consolidation targets directly: Gemini Omni Video and Nano Banana 2. If you want the models Google is steering traffic toward, that is a model-picker change, not a migration project, and it is not Imagen 4.

A five-minute pipeline audit worth doing today

Whether or not you were directly affected, this is a good prompt to check for the failure mode before it finds you:

1. Grep your own repos for hardcoded model strings. Search for veo-2.0, veo-3.0-generate, veo-3.0-fast-generate, and imagen-4.0-generate (and the ultra/fast variants) across any script, cron job, or notebook that calls Google's API directly. A hardcoded model ID in a scheduled job is the classic silent-failure pattern — it doesn't error until the job runs, and by then a report or a client deliverable is missing.
2. Separate "I call Google directly" from "I call a product." If the failing call goes straight to generativelanguage.googleapis.com, you're exposed to every future Gemini API deprecation on Google's clock, not yours. If it goes through a product's own API or UI, check that product's own model list. A leftover Imagen 4 card is lag, not a stay of execution. Veo 3.1 is the live video swap. Nano Banana 2 is the live stills swap.
3. Test the replacement side by side before committing. Don't just swap the model string and hope. Run the same prompt through the old target's replacement and eyeball the output difference — Veo 3.1's audio handling and shot-consistency behavior aren't identical to Veo 2.0's, and Nano Banana 2's rendering isn't a drop-in match for Imagen 4.0's either. A same-prompt comparison on a text-to-image job costs a few minutes and catches the surprises before a client does.
4. Build a standing habit, not a one-time fix. Google has now run this exact pattern twice in one summer — announce, give a runway measured in weeks, shut down. Whatever ships next (and something will) will follow the same shape. Bookmark the changelog, or just check the models hub periodically for anything you rely on that shows signs of being on its way out.

The pattern to expect going forward

Read the two 2026 cuts together and a cadence emerges: Google is willing to give a widely-integrated model family months of runway (Imagen 4.0's nine weeks) but will cut a less-embedded one in two weeks flat if the replacement is ready (Veo 2.0/3.0). The lesson isn't "Google is unpredictable" — it's that the runway length tracks how confident Google is that the replacement is already good enough to absorb the traffic immediately. Veo 3.1 was clearly ready on day one of the Veo cut; the longer Imagen runway suggests more caution about Nano Banana 2 and Gemini Omni fully covering every Imagen 4.0 use case on day one.

Either way, the practical takeaway is the same one every API consumer eventually learns the hard way: don't build anything load-bearing directly on a model ID string you don't control the lifecycle of, and know which layer of the stack actually owns your access before you panic-migrate something that was never going to break.

FAQ

Did Google shut down Veo 2.0 and Veo 3.0?

Yes. Google's Gemini API changelog shows veo-2.0-generate-001, veo-3.0-generate-001, and veo-3.0-fast-generate-001 were announced for shutdown on June 15, 2026, and taken offline June 30, 2026, with traffic redirected to Veo 3.1.

When did Imagen 4.0 get deprecated from the Gemini API?

Google deprecated the imagen-4.0-generate-001, imagen-4.0-ultra-generate-001, and imagen-4.0-fast-generate-001 endpoints on June 15, 2026, with the shutdown taking effect August 17, 2026 — a nine-week runway, longer than the two weeks given to the Veo 2.0/3.0 family announced the same day.

Is Imagen 4 still available anywhere after the Gemini API shutdown?

The specific imagen-4.0 endpoints on Google's own Gemini API are gone. Firebase's migration guide (17 September 2026) says the shutdown applies across Google, including the Agent Platform Gemini API. A leftover catalog card is lag, not availability. Start stills on Nano Banana 2, not Imagen 4.

What is replacing Veo 2.0, Veo 3.0, and Imagen 4.0?

Google's changelog points video traffic to Veo 3.1. On the image and multimodal side, Nano Banana 2 Lite reached general availability and a Gemini Omni Flash preview launched the same week, June 30, 2026 — the two models Google is consolidating image and multimodal generation around.

How do I avoid getting caught by the next model sunset?

Audit for hardcoded model ID strings in anything you run on a schedule, know whether your calls hit Google's API directly or go through a product's own serving layer, and test a replacement model side by side on a real prompt before switching anything load-bearing.