Nano Banana reference limits: Gemini slots vs Sume input_references

Google splits reference images into slots by kind. Its Gemini image docs (read 2026-10-06) give the Pro model 6 object references and 5 character references, the Flash model 10 object references and 4 character references, and a Lite tier 14 object references. Sume does not copy that split. Each Sume row publishes one input_references range, and you read the maximum from the catalog.

The Sume rows for Nano Banana are google/nano-banana-2 and google/nano-banana-pro. Read the range for each row before you plan a reference set.

Two ways of counting

What changes in the call

On Sume you send a plain list of image_url entries under input_references. There is no field that labels an entry as an object or a character. If the identity of a person matters, say so in the prompt and put that image first.

Every URL must be public HTTPS. Sume rejects localhost, private-network and non-HTTPS URLs before it submits the job, so a link that only works on your network fails early.

How to pick the number to send

• Send fewer than the maximum. More references means more things for the model to blend, and each one adds weight to the prompt.
• Put the most important image first. Ideogram 4.5 edits the first image; for other rows, name the image to change in the prompt.
• Name each reference's job in the prompt, such as the product to keep, the style to match, the scene to place it in.
• If the call returns 400 unsupported_parameter, the row does not take that field. Read its descriptors again.

A note on provenance

Google's docs state that all outputs carry SynthID, a watermark. Sume's docs do not describe how Sume handles that for Nano Banana rows, so do not promise your client a particular result when you pass the files on.