Summary: OpenRouter’s September 9, 2026 Nano Banana tutorial reduces an image edit to one request containing source references and a prompt. It recommends public URLs for hosted images, base64 for private files, and stepwise edits because prior prompts are not retained. That shape makes editing testable like any API call, though model quality, formats, latency, and catalog durability still require local evaluation.
Most image features start life as a demo and then run into a wall: the point where one element in a photo has to change without rebuilding the whole scene. OpenRouter’s tutorial of September 9, 2026, on the Nano Banana API frames that wall as a problem of request shape, and the shape it arrives at is compact enough to fit on a single screen.
One request, two fields that matter
One call is all an edit takes, according to the guide. The source image is placed in input_references, the instruction is placed in prompt, and the edited image comes back in data[0].b64_json, which you decode to disk. google/gemini-3.1-flash-image serves as the default model, identified by the tutorial as Nano Banana 2 — the default fast model in Google’s Gemini image family.
That is the entire contract. There is no separate upload step, no job to poll, no asset ID to carry between calls. What should interest a builder is not the model’s name, but the fact that the request body looks the same whether you write Python or TypeScript, and that the response is base64 you can write straight to a file.
Inputs: base64 or a plain URL
For input_references, either a base64 data URL or an HTTP(S) URL will do. Where an image is already hosted publicly, the tutorial favours the URL, since the request body stays small; base64 is what you reach for with local or private files. On the input side Gemini takes image/png, image/jpeg, image/webp, image/heic, and image/heif, though the guide warns that the supported set differs from one model to the next, so the model page is worth a look before you send anything.
That split carries more weight than it first appears. A pipeline that already keeps its images behind a CDN can skip encoding altogether. A pipeline that handles user uploads which never leave your own infrastructure can hold them locally with base64.
Editing in steps instead of one big prompt
Editing in small steps is the tutorial’s most practical piece of advice. Every returned image goes back in as the source for the next call, one instruction per call, so the changes stack up. Three calls are chained in the sample: add a scarf, make it navy blue, then add soft morning light from the left.
One constraint is worth taking to heart: earlier prompts leave no trace in the model’s memory, so every new prompt has to restate whatever should stay the same. That costs prompt tokens and review effort — but it also makes each step independently checkable and redoable. Should step three come back wrong, step two is still sitting on disk.
The guide also draws a line between generation prompts and edit prompts. A generation prompt paints a whole new image; an edit prompt leads with the change, then names what must stay as it is. An object swap, a background change, a style transfer, and a text fix are among its examples. Writing the prompt as a small JSON block with edit, preserve, and style keys is possible, it notes, but the API reads that as ordinary text rather than as a special mode.
Swapping models and handling failures
A model swap is a one-field change: put a different value in model, and leave the source image, the prompt, and the response handling exactly as they were. Four members of the family are listed as current, with google/gemini-3.1-flash-lite-image the cheapest and fastest, google/gemini-3-pro-image slower but higher quality, and the original google/gemini-2.5-flash-image still working against the same request shape. openai/gpt-5-image also appears, as a cross-provider comparison, with the caveat that all of this holds only for models that accept image input and support the same input_references shape.
If model choice already lives in configuration rather than in code for you, this fits the pattern set out in Config-as-Code for LLM Calls, where per-environment model settings sit outside the request logic.
The failure modes the guide flags deserve a place in your plan. An unsupported format or an unreachable URL may simply be rejected. Oversized images can time out, so the source should be shrunk first. And a question such as “what’s in this photo?” can push the model into answering with text instead of producing an image — the API reports that as a 400 error, not as an empty response. Write an instruction rather than a question, and check the HTTP status before you decode anything.
Whenever usage data is available, cost is reported per request in USD, so logging usage.cost buys you spend tracking without standing up a separate meter. For batch work, the tutorial suggests retrying 429 and 5xx responses with growing delays, limiting concurrency, and saving every returned image before its next edit begins, so that a single failure cannot take finished work down with it.
What to take from this
The request shape is the part that earns its keep: one endpoint, one source image, one instruction, one image back. Image editing thereby becomes something you can wrap in a function and test the way you test any other API call, instead of maintaining it as a separate subsystem. The limitation is that quality and format support still vary by model, and beyond noting that models get added, deprecated, and repriced, the supplied tutorial says nothing about how the editing-capable catalog will shift over time. Pin a slug, but keep the model field easy to change.