ChatGPT Image 2 rejects quality xhigh: only 2.5 takes xhigh and max

Sending quality xhigh or max to openai/gpt-image-2 on Sume returns 400. The 2.5 ids accept auto, low, medium, high, xhigh and max. Table and a safe fallback.

5 min readSume
All posts

openai/gpt-image-2 on Sume accepts only low, medium and high for quality. Send xhigh, max or auto and you get 400 invalid_request; the API message reads "auto, xhigh, and max quality require GPT Image 2.5." The two 2.5 ids, openai/gpt-image-2.5 and openai/gpt-image-2.5-sunburst, accept all six: auto, low, medium, high, xhigh and max.

This bites when you migrate a working request by changing the quality word first and the model id second, or when a config file carries one quality value across several models.

Which quality values does each model take?

The values below are the descriptors the Sume catalog publishes under supported_parameters.quality. A model with no quality descriptor at all, such as the Nano Banana rows, answers a quality field with 400 unsupported_parameter rather than ignoring it.

quality values on Sume image models, read 2026-10-02
Model idAccepted quality valuesOmitted quality
openai/gpt-image-2.5, openai/gpt-image-2.5-sunburstauto, low, medium, high, xhigh, maxhigh
openai/gpt-image-2low, medium, highhigh
Models whose catalog entry lists no quality descriptor (check supported_parameters)none (field rejected)not applicable

What does OpenAI say about 2.5 quality?

OpenAI's image generation guide names two current models, gpt-image-2.5-sunburst for editing precision and gpt-image-2.5-flare for fast everyday generation, and lists quality options low, medium, high, xhigh, max and auto. The page I read does not give the same list for the older ChatGPT Image 2, which matches Sume trimming that row to three values.

On Sume the two 2.5 ids are the Flare and Sunburst snapshots, and the Image API docs say omitted quality defaults to high, while auto reserves the cost of max at admission. That reservation is worth remembering: auto is not a cheap default on Sume.

How do I fall back safely?

Do not map a value you are not sure of. Read supported_parameters from the catalog for the model you are about to call, and pick the highest value that is on it. The request below fails on purpose so you can see the error once.

curl -sS https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-image-2",
       "prompt":"Poster with the words OPEN LATE in block letters",
       "quality":"xhigh"}'
# 400 invalid_request: auto, xhigh, and max quality require GPT Image 2.5.

Should I move from ChatGPT Image 2 to 2.5 just for xhigh?

Only if the extra tier fixes something you can see. For dense text, the guide itself says the models are significantly improved at text but can still struggle with precise placement and clarity, so higher quality helps legibility but does not guarantee placement. A cheaper path is to render at medium, check the text, and re-render only the failures at a higher tier.

Cost matters here. The Sume docs give the 1024x1024 output estimates for the 2.5 ids: $0.09366 for xhigh and $0.21072 for max before input tokens and Sume pricing. That is more than double between the top two tiers, so a retry loop that always ends on max is expensive. The xhigh-versus-max post works through the same numbers, and the migration post lists what else changes between the ids.

How do I keep one config across both generations?

Store the quality you want per model id, not per project. A map from model id to the highest accepted value, filled from the catalog, lets a job fall back from xhigh to high when it lands on the older row. Log the final value with the job, since a fallback that nobody sees looks like a quality regression later.

Also avoid auto as a default for cost-sensitive work. On the 2.5 ids it is accepted, but the Sume docs say it reserves the cost of max at admission, which can hold more of your balance than a medium job needs while it runs.

Sources

Related posts

More in Models

All Models posts

Written by Sume