Nano Banana 2.1 0.5K: Google says unsupported, Sume lists 512

Google's image guide says the 512px (0.5K) tier is not supported on Gemini Nano Banana 2.1 and belongs to Gemini 3.1 Flash Image. The Sume catalog, read from code on 2026-10-09, still lists 512 as a resolution value for google/nano-banana-2.1. Treat the live catalog as the answer for what Sume accepts and test one call before you rely on it.

What do the two sources say?

The facts below disagree, so they are shown side by side.

How do I check what Sume accepts?

Read the descriptors, not a blog post. GET /v1/images/models returns each row's supported parameters, and a resolution enum lists the tiers it takes. A parameter the row does not list returns 400 unsupported_parameter. The docs do not say which error an out-of-list value gets, so test that yourself.

curl https://api.sume.com/v1/images/models \
  -H "Authorization: Bearer $SUME_API_KEY"
# look for the nano-banana-2.1 row, then supported_parameters.resolution

Should I use 512 for cheap drafts?

Maybe, but price it first. The 512 line on Sume bills $0.075 per image against $0.10 at 1K, but no document describes how a tier the provider calls unsupported behaves. If you need a cheap draft, generate at 1K ($0.10 billed) or pick a cheaper model from the image models docs.

If the 512 call works, record the output width and height and compare it with a 1K call before you adopt it in a pipeline.

Does this change my crop math?

Only for the 512 tier. The sizes for 1K, 2K and 4K in Google's table are unchanged, and the other posts in this series use those.

The practical rule is simple: Google's page describes what Google supports, and the Sume catalog describes what Sume will accept and route. When they disagree, believe your own test call. Save the response size and the billed amount from it, and rerun the test after any announcement about the model, since a catalog row can change without a post like this one noticing.