Which Sume image models accept aspect_ratio auto on an edit?

On Sume, aspect_ratio: "auto" is accepted only by the models whose catalog list contains it: ChatGPT Image 2, 2.5 and 2.5 Sunburst, Nano Banana 2 and Pro, and Seedream 4.0. On Grok Imagine, Seedream 4.5, Seedream 5.0 Lite and FLUX.2 Pro or Flex the same value returns 400 invalid_request, so an edit that must keep the source photo's shape needs a ratio you pick yourself.

The Image API docs tell you to prefer auto on edit calls and note that omitting the field is not the same as sending auto. That advice only works where the model lists auto. This post is the cross-model table that single sentence leaves out.

Which models list auto?

The table is read from the aspect-ratio catalog in the Sume repo, which is the same list GET /v1/images/models publishes under supported_parameters.aspect_ratio. Check the live response before you depend on it, because the catalog changes when models are added.

What does the 400 look like?

The error names the model and the rejected value, and carries the accepted list in supported, so you can read the fix from the failure. For x-ai/grok-image the message is x-ai/grok-image does not accept aspect_ratio "auto". with the thirteen Grok ratios in the details. Nothing is generated and nothing is billed, because the request is rejected during validation and failed generations are not billed.

Grok is the one to watch in an edit pipeline. xAI documents image editing with up to 5 source images, sent as public URLs or base64 data URIs (xAI image generation guide), but the page I read does not list aspect ratios, so Sume's catalog is the list to trust here.

How do I keep the source shape on a model without auto?

Read the source image's width and height, then pick the closest ratio from the model's own list. The helper below fetches the list from the catalog so it does not drift when a model gains a ratio. It compares ratios on a log scale, so 4:5 and 5:4 are equally far from 1:1.

import math, os, sys, requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}

def closest_ratio(model, width, height):
    r = requests.get("https://api.sume.com/v1/images/models", headers=H, timeout=30)
    r.raise_for_status()
    row = next(m for m in r.json()["data"] if m["id"] == model)
    values = row["supported_parameters"]["aspect_ratio"]["values"]
    if "auto" in values:
        return "auto"
    want = math.log(width / height)
    def dist(v):
        a, b = v.split(":")
        return abs(math.log(float(a) / float(b)) - want)
    return min(values, key=dist)

if __name__ == "__main__":
    print(closest_ratio(sys.argv[1], int(sys.argv[2]), int(sys.argv[3])))

What happens if I omit aspect_ratio instead?

Omitting the field never raises an error, but the docs are explicit that it is not the same as auto: you get the provider default for that model rather than a match to your reference. On a model without auto that default can be a different shape from your photo, and the result then looks cropped or stretched even though the call succeeded.

A second trap is sending a pixel size where a ratio belongs. A string such as 1080x1350 in aspect_ratio is not rejected on every model; some rows snap it to a native ratio instead. The 4:5 on Grok post covers that case, so do not rely on a 400 to catch a bad size.

What should I do in practice?

Use the helper on every edit call, then send the result as aspect_ratio next to your input_references. If the model returns auto, send it as is. If it returns a ratio, the output shape will be close to the source but not identical, so crop or pad afterwards if the exact framing matters.

If you want the output to follow the reference without any arithmetic, pick a model that lists auto. Which Sume image model to edit a photo compares the edit-capable rows, and the GPT Image 2.5 auto-versus-omitted post shows what happens when you omit the field on that model.

• Models with auto: GPT Image family, both Nano Banana rows, Seedream 4.0.
• Models without it: Grok Imagine, Seedream 4.5 and 5.0 Lite, FLUX.2, Qwen Image, Ideogram V3.
• Always read supported_parameters.aspect_ratio.values instead of hard-coding the table above.

How do I test a model before I rely on it?

Run one cheap call per model in your shortlist with the exact parameters your job uses, and keep the response. A single call tells you the status code, whether the shape matches your source, and what usage.cost reports. Do that again whenever your catalog diff shows a new or changed row, because the lists in this post are a snapshot of the catalog on 2026-10-02.

Keep the check in code, not in a runbook. The failures here are all 400s that arrive before generation, so they are cheap to catch in a smoke test that sends one tiny prompt to every model you route to. A test that expects auto to fail on Grok and succeed on Nano Banana is a short, useful guard against a model swap that changes behavior without anyone noticing.