Gemini image_size 1k rejected: use 1K, and Sume resolution tiers

Gemini's image generation page says image_size must use an uppercase K, and that lowercase values such as 1k will be rejected. Write 1K, 2K or 4K. On Sume the field is resolution, a normalized tier, and a model only accepts the values its catalog lists.

Google's rule is from its image generation page; Sume's from Image generation, read 2026-10-01.

What does Google say about image_size?

Gemini 3 image models generate 1K by default and can also output 2K, 4K and 512px (written 0.5K in the page's text, for Gemini 3.1 Flash Image only). You set image_size in the response format. The page notes that the 3.1 Flash Lite image model supports only 1K, and repeats the casing rule: uppercase K.

How does Sume spell the tiers?

The Sume docs list resolution as a normalized tier: 512, 1K, 2K, 4K. The OpenAPI schema also accepts 0.5K as a legacy alias for 512. Because spellings differ, read the model's supported_parameters before hard-coding a value.

What happens if I send a value the model does not list?

The docs say a request that sets a parameter the selected model does not list is rejected with 400 unsupported_parameter rather than silently dropped. A model only accepts the values its catalog descriptors list, so a tier that a model lacks fails loudly instead of rendering at another size.

How do I avoid the casing trap?

Define tiers once as constants with an uppercase K, and pass them through unchanged. Do not lowercase user input before it reaches either API. For the Sume tiers per model, see Nano Banana 512px to 4K.