How do I ask Sume for 2K? Only 5 of 19 image rows list resolution

On Sume you can only ask for a resolution tier on five of the 19 image rows listed in the catalog on 2026-10-10: Nano Banana 2.1 (512, 1K, 2K, 4K), Nano Banana Pro (the same four), Imagen 4 Ultra (1K, 2K), Ideogram 4.5 (1K, 2K) and Higgsfield Soul (720p, 1080p). Send resolution to any other row and the request fails with 400 unsupported_parameter.

This matters when you port a pipeline that always sends resolution: "2K". The error is deliberate: the Image API docs say Sume does not silently drop a parameter that a model does not list.

The five rows, side by side

Each row publishes its own enum, and the values differ, so a single constant in your code will not work across all five. Soul uses 720p and 1080p, not 1K. Nano Banana lists 512, which the docs say is the public spelling of the 0.5K tier and accepts either.

The billed price changes by tier on only some of these rows. Nano Banana 2.1 scales from $0.075 at 0.5K to $0.20 at 4K, Nano Banana Pro costs $0.1875 except at 4K where it is $0.375, and Soul is $0.005 at 720p and $0.0075 at 1080p. Imagen 4 Ultra is the same billed price at 1K and 2K in the pricing code, and Ideogram 4.5 prices by quality rather than by resolution.

What to do on the other 14 rows

For GPT, Seedream, FLUX, Qwen, Grok, Recraft and Imagen 4 Fast, choose the shape with aspect_ratio and read the returned file to learn its size. The docs also say size is shorthand for a resolution tier and that explicit pixels on size are not served in v1, and that target_pixels is never applied, so do not plan on an exact pixel count from the request.

If you need a bigger image than a row returns, use a row that lists a tier, or run an upscale as a separate step. Sume's upscale is a separate paid step with its own price, which is the clean way to go from a 1K-class generation to a larger one without changing the model.

• Read supported_parameters.resolution from the catalog before you send it.
• Keep one resolution setting per row in config instead of a global default.
• Handle the 400 in CI: a test that sends your default body to every row you use will catch a missing field before a batch does.

A guard you can add in five lines

Before sending, look up the row's descriptor and drop or translate the field. If resolution is absent from supported_parameters, remove it from the body and pass a matching aspect_ratio instead. If it is present, check that your value is in the enum, because 2K is valid on Ideogram 4.5 but not on Soul.

Log the row, the field and the value whenever the guard changes a request. That log is the fastest way to see which of your callers still assume every row works the same way.

Why the request fails instead of being ignored

A silent drop would be worse than an error. If Sume ignored resolution on FLUX, your code would believe it had asked for 2K, pay for a 1K-class image and ship it to a screen that needed more. The 400 tells you at the first call that the row does not offer the choice, and the error body names the parameter so you can find it in logs.

The same rule applies to every field in the catalog: quality, mask_url, background, n outside its range, and aspect_ratio values the row does not list. Treat the catalog as the contract and your request body as something you validate against it, not as a wish list the server will interpret.