Which Sume image models accept image_size for custom pixel dimensions?

Eleven of the 19 image models in Sume's catalog accept image_size with a width and a height: the three ChatGPT Image rows, the three Seedream rows, both FLUX.2 rows, both Qwen Image rows and Recraft V4. Eight do not: both Nano Banana rows, both Imagen 4 rows, Grok Imagine, both Ideogram rows and Higgsfield Soul. On those eight, use aspect_ratio and, where listed, resolution instead.

The split matters because it decides how you write the calling code. A pipeline that hard-codes exact pixels is tied to the eleven models that take image_size; a pipeline that sends only aspect_ratio can move between all 19. Most portable code sends the ratio and resizes locally when exact pixels are needed.

If you send image_size to a model that does not list it, Sume returns 400 unsupported_parameter and does not bill.

The two groups

The grouping below follows the catalog. The right column gives the control you use when image_size is not available.

Last, remember that a model accepting image_size does not guarantee every pixel pair is valid. Each family has its own minimum, maximum and rounding rules, and the API checks them. A 400 on a size is a signal to read the model's note in the endpoints record, not to retry the same body.

Rules that still apply

Even when image_size is accepted, it has to pass the model's own limits. For ChatGPT Image 2.5, sizes land on a short-side grid of multiples of 16, and a stored post covers a validator for it. For the other families, check the width and height against the model's note in the endpoints record before you build a batch.

Price can depend on size. ChatGPT Image 2.5 is token-billed, so a smaller short side costs less; Seedream is a flat price per image, so its pixel count does not move the price. Read the endpoints record for the model you use.

When to use a ratio instead

Use aspect_ratio when you need a shape and not a number of pixels. It is accepted by every model in the catalog, with different value lists, and it is the choice that travels best across models. Use image_size only when a layout needs exact pixels, such as a 1200x628 social card or a 1080x1350 portrait.

A practical rule is to keep image_size out of shared helpers. Put it in a per-model override, in the same dictionary that holds quality and resolution. Then adding a model that does not take it is a config entry, not a code change, and a typo fails on the first test call and does not bill.

To get the exact pixel size from a model without image_size, request the nearest ratio and resize on your side.

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "bytedance-seed/seedream-5-lite",
    "prompt": "A clean product banner, soft gradient",
    "image_size": {"width": 1200, "height": 628}
  }'

Check a model before you send

The descriptor appears in the catalog only for models that accept the field, so the check is a one-liner. Run it when you add a model to your pipeline.

Keep in mind that every figure here is a billed price from Sume's catalog on the date in the table caption. Prices and limits can change, so before a large run, read the endpoint record for the exact model id and compare it with your plan. A one-minute check costs nothing, and it is the only way to be sure the number in your budget is the number on the invoice.

curl -s https://api.sume.com/v1/images/models \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq -r '.data[] | select(.supported_parameters.image_size) | .id'