Image Generation
Rewriting the prompt gives you a different picture, not an edit of the one you had. Since no provider promises the same prompt returns the same image, store the result along with the prompt, the model and the interaction ID.
Generation is a different shape of request from a text call
An image request looks like a text request and behaves like a different thing.
It is slower, usually by seconds rather than milliseconds. It is priced per image rather than per token, so the cost model you built for text does not transfer. And it returns bytes, which means the response is something you have to put somewhere rather than something you can hand straight to a template.
That last point drives most of the engineering. A text response can be regenerated cheaply if you lose it. An image cannot be reliably regenerated at all, for reasons covered below.
Editing an image is not regenerating one
There are two operations that look similar and are not.
Generating takes a description and produces an image. Editing takes an existing image plus an instruction and produces a modified version of it.
Rewriting the prompt is not editing. "A city skyline at dusk" followed by "a city skyline at dusk, but darker" gives you two unrelated skylines. The subject, the composition and the details all move, because nothing connected the second request to the first.
Providers that support editing do it by referencing the earlier image, either by uploading it or by pointing at a previous interaction. Nano Banana API covers one provider's version, where multi-turn conversation is the documented way to iterate.
If your product lets someone refine an image, you need the editing path, and you need to keep whatever identifier it depends on.
What you have to store, and why
Assume you cannot regenerate a result.
No provider I read promises that the same prompt returns the same image, and generation is sampled in the same way text is, so treating reproducibility as available is a bet you do not need to take. The safe design is to store the image you were given, along with the prompt, the model, and any reference or interaction IDs that produced it.
That has consequences beyond a storage bill. If a user can come back to an image tomorrow, it needs a durable URL. If they can edit it, you need the identifier the editing path uses. If you ever need to explain how an image was produced, the prompt and model have to have been recorded at the time, because they cannot be recovered from the pixels.
None of this is difficult. It is easy to skip while the feature is a demo, and expensive to retrofit once people have images they care about.
Moderating both ends
Image generation has two surfaces to check rather than one.
The prompt is user input that becomes a request you pay for and are responsible for. The result is output your product displays, and a prompt that passes inspection can still produce something you would not publish.
Content moderation APIs covers running those checks and makes the case that checking one side and not the other leaves the gap open. Providers also apply their own filtering, which is not the same as yours and which you should not assume matches your policy.
Plan for refusal as an ordinary outcome. A generation request that returns nothing because it was blocked is a state your interface has to handle, the same way Google Gemini API describes blocking arriving in a field rather than as an exception.
What ships with the image
Generated images may carry provenance marking. Google documents that "All generated images include a SynthID watermark" on its image models, as of 2026-09-16.
Treat this as a per-provider question rather than an industry default, and settle it before shipping rather than after. The question to answer is whether your use allows it, and whether anywhere your images end up requires it. Both answers are easier to get before you have a library of images.
The rights questions around generated imagery are not settled. What you can do is know what your provider's terms say about ownership and permitted use, and record enough about each image to answer a question about it later.
Further reading
- Google, Image generation: one provider's documentation for generation, editing and watermarking.
- Nano Banana API: the vendor specifics for that endpoint.
- Multimodal AI: images as input, which is the opposite direction.
- Content moderation APIs: checking the prompt and the result.
Knowledge check
Question 1 of 4
Sign in to save your progress and pick up where you left off.