Google’s Imagen 4 Gemini API endpoints hit shutdown day—and the migration is not a rename
Three stable Imagen 4 endpoints are scheduled for shutdown on August 17. Teams still using them must change both the call pattern and response handling, while Google’s own documentation currently disagrees on the recommended successor.
The deadline is here
Google’s deprecation table lists August 17, 2026 as the shutdown date for imagen-4.0-generate-001, imagen-4.0-ultra-generate-001, and imagen-4.0-fast-generate-001 in the Gemini API. Its latest table recommends gemini-3.1-flash-image as the replacement.
This is an availability change with an immediate production consequence: an application still calling one of those endpoints directly can lose image generation when Google completes the shutdown.
The integration contract changes
This is not a safe one-string substitution. Imagen uses generate_images and returns a dedicated generated-image response, while Nano Banana uses generate_content and returns content parts that may contain image data. That changes the request path, response parser, tests, and failure handling.
There is another reason not to rush blindly: Google’s current deprecation table points to Gemini 3.1 Flash Image, while its Imagen migration guide still names Gemini 2.5 Flash Image. We would not ship an automatic migration based on a single documentation example.
What we would do
Virtual Arc would stop new work against the Imagen 4 endpoints immediately and put Google image generation behind an internal adapter. We would then canary gemini-3.1-flash-image on a small share of traffic and test real prompts, response shape, safety refusals, aspect ratios, latency, and cost per accepted image.
Only after that regression pass would we move all traffic. If an application lacks both an adapter and a representative evaluation set, today’s shutdown is a warning that dependence on a specific model ID has become operational debt rather than routine maintenance.
This matters more than a routine version retirement because Google is changing both the model and the programming contract while its official pages do not consistently name the same successor. We would neither wait for production failures nor blindly swap the model ID. We would add an adapter, canary Gemini 3.1 Flash Image, and measure cost per output the application actually accepts—not merely cost per API call. If a team cannot replace a model version or provider within hours, its biggest problem is no longer image quality; it is lock-in embedded directly in application code.