Nano Banana Pro

What "Nano Banana" refers to

The nickname started as a community label for Google's Gemini image models and stuck. Internally the model IDs are gemini-2.5-flash-image (the original Nano Banana), gemini-3.1-flash-image-preview, and gemini-3-pro-image-preview (Nano Banana Pro).

On PlugNode's Image node they show up with their real labels in the dropdown so you know which tier you are calling. Nano Banana Pro is the largest and most capable of the three. Gemini 3.1 Flash Image is the balance option. The original Nano Banana is the fastest and cheapest.

Picking between them is a dropdown change, and the rest of the flow does not care which model ran inside the Image node.

Why edit-by-description matters

Nano Banana Pro accepts an image plus a text instruction and returns an edited image. On PlugNode you express this as: File Input feeds the image, the Image node takes a prompt like "replace the background with a studio white cyclorama, keep the product lighting", and the output is the edited asset.

Because the edit is text-driven, you can publish the flow as an API and expose the "what to change" field as a JSON parameter. A marketing team hitting POST /api/trigger/{secret}/{nodeId} with a product image and a copy description gets back a composited asset without touching Photoshop. That is a pipeline move, not a chat interface.

The brand-asset-generator use case walks through the full flow end to end.

Multi-image composition and caption hints

The Image node in PlugNode interleaves caption text with each reference image when calling Gemini. The model reads the caption immediately before each image as a role hint (for example: "product on white", "background plate", "logo overlay"), which steers the composition.

This is the difference between "generate a product shot" and "place this specific product in this specific environment with this specific lighting". For brand studios and e-commerce teams, the caption-hint model is often the reason to pick Gemini over a single-reference-image model.

Publishing an image pipeline behind a URL

A shipped Nano Banana Pro flow looks like this: HTTP Trigger receives a JSON body with a product reference image URL and a brief. File Input pulls the image. Image (Nano Banana Pro) generates or edits. Image Resize fans out to 1080×1080, 1200×628, and 1200×627. Respond to Webhook returns all variants.

The whole thing is a single POST your backend calls whenever a new product hits the catalog. Rotate the secret from Settings when you need to. Roll back to a previous version when a prompt change regresses downstream. Read per-node latency and token counts from the execution log.

See the publish-as-API pillar and the social-media-content-pipeline use case for the same fan-out pattern on social variants.

Where Nano Banana Pro sits next to Flux, Ideogram, and Recraft

Flux Kontext, Ideogram 3, and Recraft V3 are competing image models that each have a distinct strength: Flux for photoreal fidelity, Ideogram for in-image typography, Recraft for brand-vector output. None of them is a native PlugNode node today. The current Image node runs Google's Gemini image models exclusively.

If your flow requires one of those vendors specifically, the honest answer is that they are on the roadmap rather than already wired. If your brief is "generate or edit a brand-appropriate image from a prompt or reference", Nano Banana Pro is a capable choice today on the shipped node.