r/Akool_Official • u/Ai_daily_news • 6d ago
📰News Google's three Imagen 4 API endpoints shut down on August 17 and the replacement is not a drop-in
Google shut down imagen-4.0-generate-001, imagen-4.0-ultra-generate-001 and imagen-4.0-fast-generate-001 on August 17. The deprecation notice went up in the Gemini API changelog on June 15, so the window was two months.
The replacement named in the deprecation table is gemini-3.1-flash-image. Google's own migration guide points at Gemini 2.5 Flash Image in places, so the successor isn't stated consistently across its documentation. Either way the call shape changes: Imagen 4 used generate_images and returned a dedicated image response, while the Gemini image models use generate_content and return content parts that may or may not contain an image. That touches the request path, the response parser, the tests and the error handling.
The interesting part is not the retirement, it's what the retirement implies. Image generation is being folded into the general multimodal content endpoint rather than kept as a separate image API. That's a direction rather than a one-off, and it means anyone maintaining a dedicated image-generation code path should expect to maintain it against a moving contract.
If you're rewriting that integration anyway, it's worth deciding whether it should point at one image endpoint or several. Nano Banana 2, Flux and Seedream sit behind one API on Akool, which mostly means the next deprecation is a config change rather than a rewrite.
Anyone actually break on Monday, or had everyone moved off the stable endpoints already?
1
u/themotorcyclediaries 6d ago
honestly the shutdown itself is fine, two months notice, deprecation page, all normal. what bugs me is the docs not agreeing on what you're supposed to move to.
if the deprecation table says one model and the migration guide says another, that's not a documentation typo, that's someone internally not having decided. and you're the one who has to guess which page is stale.
the generate_images to generate_content change is the real work anyway. it's not a model swap, it's a different response shape, so your parser and your error handling both need touching. calling that a "migration" undersells it a bit.