Image resolution tiers on Sume: Nano Banana 512 to 4K, 400 elsewhere

On Sume the resolution field exists only on a few rows: the two Nano Banana models take 512, 1K, 2K and 4K, and Higgsfield Soul takes 720p and 1080p. Every other image model, including the GPT Image family, Seedream, Grok Imagine and FLUX.2, returns 400 unsupported_parameter when you send resolution, because the model does not list it.

If you wanted a bigger image from one of those, you steer with image_size, aspect_ratio or quality instead, depending on the model.

Which model takes which resolution value?

The values come from the Sume catalog. Nano Banana defaults to 1K when you omit the field, and Soul defaults to 720p. The size field is only a shorthand for a tier, so size: "2K" works where resolution: "2K" does.

What does Google say about the Nano Banana tiers?

Google's image generation page lists resolutions of 512px for the Flash model only, plus 1K, 2K and 4K, and says the Flash Lite image model supports only 1K. Sume's descriptor lists 512 on both Nano Banana rows, including Pro. Because Google labels 512 as Flash only, run one 512 call on google/nano-banana-pro and look at the result before you build on it.

Cost moves with the tier. The Sume catalog note says the list rate is the 1K default and that admission scales for 0.5K, 2K and 4K, and that 4K on Pro is higher than the default. Read the endpoint pricing and your usage.cost after a test, because the price line is per image at the default tier.

What are the common mistakes?

Three show up repeatedly. The first is lowercase k: the value must be 2K, not 2k, and anything outside the list returns a 400 with the accepted values. The second is putting pixels on size. The docs say size is a shorthand for a tier, so size: "1024x1024" returns 400 unsupported_parameter and tells you to use a tier or image_size. The third is sending resolution to a model that has no descriptor, which fails even for a value that looks harmless.

curl -sS https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"google/nano-banana-2",
       "prompt":"Isometric diagram of a coffee roaster, labelled parts",
       "aspect_ratio":"16:9",
       "resolution":"2K"}'
# Same body to openai/gpt-image-2.5 returns 400 unsupported_parameter
# for resolution; use image_size there.

How do I handle many models in one app?

Read supported_parameters.resolution per model and only send the field when it is present. For a model without it, translate your tier into whatever that model lists: a custom image_size on the GPT Image rows, or a ratio on the others. The GPT Image 2.5 resolution post gives the pixel rules for that family, and the size versus image_size post explains why pixels do not go on size.

A last point on the tiers themselves: the Sume docs treat 512, 1K, 2K and 4K as normalized labels, and 0.5K is accepted as an alias for 512. They are not a promise of exact output dimensions, which depend on the ratio you choose.

How do I confirm what I got?

Read the pixel dimensions of the returned file and log them with the tier you requested. Because the tiers are normalized labels, the dimensions depend on the ratio, and a 4K 21:9 image does not have the same width as a 4K 1:1 image.

If a tier changes your cost, you will see it in usage.cost, which is the USD amount billed. Compare it across tiers on one prompt and store the three or four numbers you care about, so your estimate does not depend on a price you read once.