Do low, medium and high mean the same on every Sume image model?

No. A quality word has no common meaning across Sume's image models, and most models do not take it at all. ChatGPT Image 2, ChatGPT Image 2.5 and Ideogram 4.5 list low, medium and high; ChatGPT Image 2.5 also lists auto, xhigh and max; Ideogram V3 is the same, with the tier mapped onto the provider's rendering speed. Seedream, FLUX.2, Nano Banana, Grok, Qwen, Imagen, Recraft and Soul list no quality field and return 400 unsupported_parameter if you send one.

Even where the word is shared, the money is not. The same medium costs $0.0165 on ChatGPT Image 2.5 at 1024x1024, $0.075 on Ideogram 4.5 and a very different figure on ChatGPT Image 2. Treat the tier as a per-model setting, never as a portable one.

Who accepts what

The catalog descriptor quality is present only when the model has tiers. The table summarises the current rows.

When you read someone else's benchmark of two models at medium, remember that the word names a setting on each model's own scale. Compare prices and your own output, not the label.

Defaults are different too

If you omit quality, ChatGPT Image 2.5 on Sume defaults to high, which is $0.0659 per 1024 square image; auto reserves the max price. Ideogram 4.5's listed price is for medium. A pipeline that omits quality therefore behaves differently per model, and the bill follows the default. The safest habit is to set quality in every request where the model lists it, and omit it everywhere else.

A worked example shows the stakes. Ten thousand images with quality omitted cost $658.75 on ChatGPT Image 2.5 at 1024 square, against $165.00 at medium. The difference, $493.75, is the cost of not typing one field. The same omission on Seedream or FLUX.2 changes nothing, since they have no tier.

For Ideogram, Sume maps the public low, medium and high values onto the provider's rendering-speed settings, and it advertises only the public words in the catalog.

What the tier moves, model by model

On ChatGPT Image 2.5 the tier moves the token count, so the price ladder at 1024 square runs from $0.007375 at low through $0.0165, $0.0659 and $0.1171 to $0.2635 at max. On Ideogram 4.5 the three tiers are three price points, $0.0375, $0.075 and $0.275 billed. On ChatGPT Image 2 they select a per-image price. In none of these does the word say anything about how the picture will look relative to another model's medium.

That is why a portable abstraction over quality is usually a mistake. If you must have one, map your own names, such as draft and final, to a per-model dictionary and test each model's mapping separately.

A portable request pattern

Keep a per-model dictionary of extras, and merge it with the shared body. Do not carry a quality value from one model to another by habit; it either fails or means something else.

import os, requests
EXTRAS = {
    "openai/gpt-image-2.5": {"quality": "medium"},
    "ideogram/ideogram-v4.5": {"quality": "medium"},
    "bytedance-seed/seedream-5-lite": {},
}
for model, extra in EXTRAS.items():
    r = requests.post("https://api.sume.com/v1/images",
        headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]},
        json={"model": model, "prompt": "A paper crane", **extra},
        timeout=120)
    print(model, r.status_code)

Checking before you send

If you use more than one model in a product, store the tier per use case in config, with a comment that says which model it applies to. A review of that file is faster than reading call sites, and a new model is a new key and not a new branch of code.

The catalog tells you which models take quality. This one-liner lists them. Run it again after a model is added, because the answer is the catalog's, not this page's.

One more habit helps with both. Log the model id, tier and billed cost with every finished job, then review the log weekly for a mismatch between the tier you meant and the cost you paid. A mismatch is the earliest sign of a missing field or an unintended default.

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