Nano Banana 2 is retired on Sume: same price on Nano Banana 2.1?

Yes, the price is the same. Sume retired Nano Banana 2 and accepts both google/nano-banana-2 and the bare id nano-banana-2 as spellings that run as Nano Banana 2.1 (google/nano-banana-2.1). The 2.1 price card is the same as the old one: $0.08 list at 1K, which is $0.10 billed after Sume's 1.25 multiplier, with 0.5K, 2K and 4K tiers around it.

If you have a script or a saved Format that still sends nano-banana-2, it keeps working. What changes is bookkeeping: the job stores the successor id, and the catalog no longer lists the retired one.

The retirement rule

Sume's image docs describe retired models as accepted in both spellings that run as their successor. The catalog from GET /v1/images/models does not list them, and a job created from one stores the successor id. For Nano Banana 2 that successor is google/nano-banana-2.1. The response model field echoes the id you requested, so your request log still shows what you sent while the stored job shows 2.1.

That split is the thing to plan around. If you report spend by model id from stored jobs, old and new calls land in one 2.1 bucket, which is usually what you want. If you diff your config against the live catalog, a config value of nano-banana-2 will look unknown, so update the pin even though nothing breaks.

Price by tier on the successor

The 2.1 list prices by resolution tier come from Sume's image price tables. The billed column is list times 1.25.

What else is the same and what is not

Nano Banana 2.1 lists these aspect ratios: auto, 21:9, 16:9, 3:2, 4:3, 5:4, 1:1, 4:5, 3:4, 2:3, 9:16, plus the extreme banners 4:1, 1:4, 8:1 and 1:8. That is the Banana Pro set plus the banners, and it matches the retired model's enum. It accepts up to 4 images per call and edit references through input_references.

Nano Banana Pro is a separate model, not a rename: $0.15 list ($0.1875 billed) at 0.5K, 1K and 2K, and $0.30 list ($0.375 billed) at 4K, with ten ratios and no 4:1 or 8:1 banners.

What a batch costs on the successor

Because the card did not change, your old budget still holds. A hundred 1K images are 100 times $0.10, or $10.00 billed. The same hundred at 2K are $15.00 and at 4K are $20.00. At the 0.5K draft tier they are $7.50, so a draft pass at 0.5K followed by a 2K rerun of the ten keepers costs $7.50 plus $1.50, or $9.00 for the whole flow, against $15.00 if you had rendered everything at 2K.

Compare that with the sibling model: Nano Banana Pro at 2K is $0.1875 billed per image, so the same hundred cost $18.75, and its 4K tier at $0.375 makes a hundred 4K images $37.50. The 2.1 row is the cheaper way to reach 4K, at $0.20 per image, and it is the only one of the two with the 4:1 and 8:1 banner ratios.

Those totals are straight multiplication of the billed column, one image per request line, so they hold for any n that your calls add up to.

What to change in your code

Replace the id in your config with google/nano-banana-2.1, keep your resolution values, and run one 1K call to confirm usage.cost reads 0.1. Nothing else needs to move: aspect_ratio, n and input_references keep the same shapes. If a nightly job compares your pinned ids with the catalog, add the successor now so the check stays quiet.

Do not expect a different model to appear behind the old name. The retired id is an alias, not a second endpoint, so there is no way to keep calling the previous weights. If your outputs shifted at the same time as the retirement, compare a fixed prompt set at a fixed resolution before blaming your own code.