Nano Banana 2.1 Day-One Measurements: What the Spec Does Not Tell You

A model launch gives you a list of improvements and a price. What it rarely gives you is a measurement. So the AICU API team in Japan did the obvious thing the day after Nano Banana 2.1 shipped: they pointed 19 requests straight at the Gemini API, varied resolution, thinking level, and reference count, and wrote down the tokens and the wall clock.

The announcement itself is short. Google published Nano Banana 2.1 on October 6, 2026 under the model ID gemini-nano-banana-2.1, describing improvements in image quality, realism, prompt adherence, text rendering, and multi-turn character consistency. It is the recommended migration target for gemini-3.1-flash-image. There is no announced shutdown date for the older model yet.

The rest of this is the interesting part.

What changed in the published spec

Four things are worth noting before the numbers:

• Output resolutions are 1K, 2K, and 4K.
• Extreme panorama ratios are supported: 1:4, 4:1, 1:8, and 8:1. Banners, wide hero images, and signage no longer need a crop step.
• Generation takes an explicit thinking level: minimal, medium, or high, defaulting to medium.
• Reference input goes up to 14 images, with consistency described for up to 4 characters and high-fidelity preservation for up to 10 objects. Grounding is available through both Google Web Search and Google Image Search.

Read the thinking level as the model's new dial. You are no longer choosing only between draft and final quality. You are choosing how much reasoning happens before the first pixel.

The measured numbers

All of this comes from one ratio and three resolutions on the same day:

• 1:1 at 1K with minimal thinking: 1,312 output tokens, 10.9 seconds.
• 2K: 1,892 output tokens, 17.9 seconds.
• 4K: 3,979 output tokens, 25.5 seconds.
• Thinking tokens at 1K: 909 for medium, 981 for high. Both add roughly 5 seconds on top of minimal.

Two readings from that block. Resolution scales tokens and time at different rates: 1K to 4K is 3.03x the output tokens for 2.34x the wall clock, which suggests a meaningful fixed overhead per request that you stop noticing as you scale up. And on a 1K render, medium thinking costs about 69% of the base image tokens. The model is spending most of a second image's worth of budget deciding what to draw.

That second number has a design consequence. Letting the model think harder is not free, and it buys something you cannot measure from a token count: fewer wasted renders, presumably. If you iterate a lot at 1K, minimal thinking plus more attempts may beat medium thinking plus fewer attempts. That is worth testing on your own prompts, because the answer depends on how often your first attempt lands.

The price list uses a different unit, and it shows the same story from another angle. On the AICU API, a 1K render starts at 1,200 AP, 2K at 1,750, 4K at 3,600. Raising the thinking level moves 1K to 1,500 and 4K to 3,800, so the cheaper call absorbs proportionally more of the thinking cost. Reference images bill separately at 60 AP each. Fourteen of them add 840 AP, which is 70% of a 1K render and 23% of a 4K one. A reference-heavy 1K call is not a cheap call.

14 reference images is a limit, not a promise

This is where the published spec and the working reality separate.

The team fed six AiCuty character references into one prompt at 2K with medium thinking and got six recognizable characters in a single image in about 40 seconds. At four references, the individual traits survived cleanly: one character's green palette, another's pink, another's side ponytail and star hairpin, another's purple. They also published the failures, which is the part I trust most. Not every attempt came back with the cast intact.

Google's guidance covers up to 4 characters for consistency. Six worked in one test. Both things are true at the same time, and neither one is a specification you can build a client deliverable on.

If your cast is bigger than one, the useful test is not "does it work at my maximum." It is "where does it break." Add one subject at a time at your working resolution, keep the prompt and every setting identical, and find the count where someone loses their face, their wardrobe color, or their hair. That number is your real cast limit for that model, and it will move when the model changes.

There is existing groundwork for this on the Phosphene blog if your group shots are drifting: the character consistency system covers identity anchors, and the face consistency guide walks through what actually holds a face together across renders. The same test method applies to a new model on day one.

Keep the sample size honest

The same team ran a Japanese text test. They generated a poster with several specified strings placed in specific spots at 2K, once with medium thinking and once with high, and both renders spelled the text correctly and put it where it was asked to be.

Then they refused to call it an improvement, because the same prompt had also worked on the previous generation. Their claim is narrow: this layout, with these strings, in these two attempts, came out right. Long copy, vertical writing, and small type are all still untested. That restraint is rare in launch coverage, and it is the correct instinct. A single render is one sample, not a capability. If you write text in images, keep your own test set with the strings you actually need, because a model that nails a short headline can still fall apart on a two-line caption. The Ideogram text rendering guide covers the failure modes to include in that set.

Read the alias before it reads you

Two migration details matter more than they look.

First, gemini-3.1-flash-image has no announced shutdown date, but Nano Banana 2.1 is the recommended target for new work. Google's own deprecation page is the source of truth here, not a blog post.

Second, and this is the operational risk, AICU scheduled the nano-banana alias to point at 2.1 starting October 21, 2026 at 05:00 UTC. Anyone who wrote the alias into production gets a new model under the same string, with no deployment and no diff to review. That is how silent quality shifts reach a live product. Pin the versioned ID, and treat an alias as a convenience for experiments.

Phosphene ships this model as gemini-nano-banana-2.1, a versioned ID rather than a moving alias, so a future revision is a deliberate switch and not a surprise. The same logic applies inside your own code: if your prompts depend on a model's behavior, the model ID is part of your input contract.

What to run this week

Before you change a default, run a baseline:

1. Collect 8 to 12 prompts you actually use. Include one multi-character shot and one text-heavy layout.
2. Render them on your current model with identical settings (include a seed only if your provider exposes one), and save the references alongside those settings.
3. Re-render the same prompts on Nano Banana 2.1, same settings, medium thinking.
4. Score blind on identity retention, text accuracy, and prompt adherence. Do not look at which model made which image while scoring.
5. Only then move the default, and note which prompts regressed.

Pick resolution by deliverable rather than habit. 1K for iteration, 4K for final output, and the default thinking level unless a specific shot justifies the extra latency and tokens. If you use a panorama ratio, generate it at the ratio you need instead of cropping a 16:9 later, since the crop costs you the pixels you paid for.

The reason to measure on day one is that habits are cheaper to set than to correct. A model update that quietly costs you 70% more per reference-heavy call is not a dramatic failure. It is just a line on your bill you stopped questioning.