IMAGE_OTHER — Gemini API image blocked for unspecified reasons (Nano Banana finishReason)

Published 2026-09-23

finishReason Retry depends on cause

The exact error

IMAGE_OTHER

IMAGE_OTHER is the least specific of the image finish reasons on Gemini image models. The model stopped without an image, and Google does not say why.

What it means

Google documents it in two places, with slightly different framing. The Gemini API reference lists IMAGE_OTHER in the FinishReason enum as image generation stopped “because of other miscellaneous issue”. The API errors page lists the Interactions API code image_other under Generation blocked codes, described as unspecified reasons blocking image generation. So officially it is a block, sitting next to image_safety, image_prohibited_content and image_recitation, but without a stated category.

Everything more specific comes from users, not from Google:

Users describe it as intermittent. In forum thread 106818, the reporter using gemini-2.5-flash-image-preview says it happens sometimes, not always, and that the same input that worked five minutes earlier then fails. Another poster in that thread sees it on about 20% of identical requests in staging and production.
Images with people seem to fail more. In thread 106674, users inserting a logo into a scene report failure rates as high as 75%, and two of them say it happens more with faces or people in the picture. A poster in thread 106818 believes it is a safety filter aimed at face transfer. That is their opinion, not something Google has confirmed.
Gray areas may land here. One developer in thread 106818 reports that clearly inappropriate prompts return IMAGE_SAFETY, while borderline ones return IMAGE_OTHER.
A MIME type mismatch can trigger it. Two users in thread 106818 traced their case to a reference image sent with mime_type image/png when the file was a JPEG. One lists gemini-2.5-flash-image and gemini-3-pro-image-preview as affected.

How to confirm it’s this

candidates[0].finishReason is IMAGE_OTHER and the candidate has no image part.
The thread 106818 reporter saw no other message and no prompt_feedback. If promptFeedback.blockReason is set, the prompt was blocked instead.
On the Interactions API, the code is lowercase image_other. Do not compare the two surfaces by string without normalizing.
Send the same request a few times and log the results. Failures that come and go on identical input match the community pattern above.

Fix

Check your input images first. Make sure every inline image’s declared mime_type matches the real file format. It is the one reported cause you can check and fix entirely on your side.
Handle it as a terminal result per attempt. Read the finish reason before decoding image data, and do not treat a missing image as success.
Log the inputs that fail. Keep the model name, timestamp and whether the input included people. That is what you need to spot a pattern or file a report.
Report persistent false positives to Google with those details, so the report can be reproduced.
Tell the user plainly. An agent should say the provider declined to produce the image for an unspecified reason, not return an empty result.

Retry or not

It depends. Google’s errors page groups image_other with the other generation-blocked codes and says to modify your input before retrying. But the community reports above describe identical inputs that fail and then succeed, so a small, bounded retry is defensible. Allow one or two retries at most, with backoff. The poster seeing 20% failures said retries with 1 to 4 second delays did not fix it, so do not expect retries to hide a persistent problem. If the same input keeps returning IMAGE_OTHER, stop and surface it.

If you fix a MIME type mismatch, the corrected request is a new request, not a retry.

When it’s not this

IMAGE_SAFETY or IMAGE_PROHIBITED_CONTENT: specific block reasons. Do not retry those automatically.
NO_IMAGE: the model was expected to produce an image and did not. Google lists no_image as a generation error, not a block.
STOP with text and no image: the model answered in text, sometimes to decline. See the NO_IMAGE page for how that happens.
HTTP 429 or 503: quota or capacity, not content. Those are safe to back off and retry.

Error text last verified against the sources below on 2026-09-23.