Aspect ratio auto on Sume: 6 image models list it, 8 edit models don't

Which Sume image models accept aspect_ratio auto when you edit a photo, which edit models reject it with a 400, and how to pick a ratio in code instead.

4 min readSume
All posts

Six models in the Sume image catalog list auto as an aspect_ratio value: openai/gpt-image-2, openai/gpt-image-2.5, openai/gpt-image-2.5-sunburst, google/nano-banana-2.1, google/nano-banana-pro and bytedance-seed/seedream-4. Eight other models can edit a photo but do not list it, so a request with aspect_ratio: "auto" to them fails with a 400 instead of matching your source image.

That matters because the Image API docs say that on edit and image-to-image calls, auto matches the reference, and that leaving the field out is not the same thing. If your pipeline sends auto everywhere, it works on six models and breaks on the rest.

The six that list auto, and the eight that do not

The split below comes from the capability descriptors in the Sume image catalog, read on 2026-10-10. A model is an edit model here if its input_references range allows at least one reference.

Edit-capable Sume image models and whether aspect_ratio lists auto (catalog read 2026-10-10)
Model idLists autoMax references
openai/gpt-image-2yes10
openai/gpt-image-2.5 and -sunburstyes16
google/nano-banana-2.1yes10
google/nano-banana-proyes10
bytedance-seed/seedream-4yes10
bytedance-seed/seedream-4.5no10
bytedance-seed/seedream-5-liteno10
black-forest-labs/flux.2-pro and flux.2-flexno10
ideogram/ideogram-v3no10
ideogram/ideogram-v4.5no5
qwen/qwen-imageno10
x-ai/grok-imageno10

What the failure looks like

When a model has an aspect_ratio list and your value is not in it, Sume answers 400 invalid_request. The message names the model and the value, and details.supported holds the full list for that model. This is different from unsupported_parameter, which means the model does not advertise the field at all. Sume does not silently swap in a nearby value.

So the error is cheap to handle: catch the 400, read details.supported, choose again. It is better to avoid the round trip by reading the list from GET /v1/images/models before you send.

What to send for the eight

For Ideogram 4.5, the docs state that an edit without aspect_ratio keeps the shape of the source image, so leaving the field out is the right move there. For the other seven, the docs do not promise that an omitted ratio follows the source, so pick a ratio on purpose.

The simple rule is to measure your source image, find the nearest ratio in the model list, and send that. A landscape photo at 4000 by 3000 is 4:3, which every one of the eight lists. A 1080 by 1350 portrait is 4:5, which all of them except Grok Image list; there the nearest entry is 3:4.

def nearest_ratio(width, height, supported):
    target = width / height
    best = None
    for value in supported:
        if value == "auto":
            continue
        w, h = (float(x) for x in value.split(":"))
        gap = abs(w / h - target)
        if best is None or gap < best[0]:
            best = (gap, value)
    return best[1]


supported = ["1:1", "16:9", "9:16", "4:3", "3:4", "4:5", "5:4", "3:2", "2:3"]
print(nearest_ratio(4000, 3000, supported))
print(nearest_ratio(1080, 1350, supported))

Why the field exists on only some models

The Image API publishes what each model accepts as a capability descriptor: an enum for discrete values, a range for integers, a boolean for presence. For aspect_ratio the enum is the model's real list, and auto is one entry in it, not a universal switch. The same catalog entry tells you whether references are accepted at all, so one call to the models endpoint answers both questions before any money is spent. See the Image API docs for the descriptor format.

When the nearest ratio is not close enough

A nearest-ratio pick changes the shape a little. For a 1000 by 1100 source, 1:1 is the closest entry on most lists, and the result is a square. If you must keep the exact frame, the choice is a model that lists auto, then crop or resize afterwards in your own step.

A second option is to stop trusting one request shape. Keep a small table in your code of ratio support per model, filled from the catalog at start-up, and build each edit request from it. That way a model swap, for example from Seedream 4 to Seedream 4.5, changes the ratio field in the same commit as the model id instead of failing in production on the first photo.

Also note the order of choices. Do not pick a model for its price and then discover it lacks auto. Put the ratio requirement in the filter at the start, with the reference count, as a capability check against the catalog.

  • If the source shape must be preserved with no crop, choose from the six that list auto.
  • If you have chosen Ideogram 4.5, omit the field on edits.
  • For the other seven, compute the nearest listed ratio and send it.
  • Log the ratio you sent next to the source size so a reviewer can see why the shape changed.

Sources

Related posts

More in Models

All Models posts

Written by Sume