GPT Image 2.5 quality ladder: price multiplier from low to max on Sume

On Sume, ChatGPT Image 2.5 at 1024x1024 costs $0.007375 at low, and every step up multiplies that: medium is 2.2 times, high 8.9 times, xhigh 15.9 times and max 35.7 times the low price. Against medium, high is 4.0 times, xhigh 7.1 times and max 16.0 times. These multipliers hold for any ratio only approximately, so treat them as the 1024 square ladder.

The figures come from Sume's price tables: output image tokens at $30 per million, a short text prompt, no references, with list rounded up to $0.0001 and Sume's 1.25 margin on top.

The ladder

Multipliers are computed from the list prices and rounded to one decimal place. The billed column is the amount Sume charges for one image.

The ladder is not linear in anything a user can see. Low to medium is a 2.2 times step, medium to high is 4.0 times, high to xhigh 1.8 times and xhigh to max 2.2 times. The biggest single jump is medium to high, so if you must choose only one step to avoid, avoid that one unless a test shows you need it.

Use the multipliers as a sanity check on a bill. If your average cost per image is near $0.0165, your jobs are running at medium. If it is near $0.0659, they are at high, and that is usually the unset default. A number between tiers means a mix, which is normal when drafts and finals share a pipeline.

For budgeting, keep one line per tier and a count of images at each. A table of five rows with counts multiplies out to the monthly total, and a change in the mix is visible at once.

What the ladder means for a batch

A batch of 1,000 images costs $7.38 at low, $16.50 at medium, $65.88 at high, $117.13 at xhigh and $263.50 at max. The step that hurts is medium to high, which quadruples the bill. If a job does not need the high tier, staying on medium is the largest saving available on this model.

The default matters here. Omitting quality gives high, and auto reserves the max price until the job settles. Both are the expensive end of this table, so set the tier on every request.

A tiered workflow

The multiplier view helps with forecasting. If your plan is based on the low price and a developer leaves quality off, the bill is 8.9 times the plan. If the plan is based on medium and the job runs at max by mistake, the bill is 16 times. Put a cap on usage.cost per job in your logging and alert when it exceeds the tier you meant.

A common pattern is to draft at low, pick the candidates, and re-render the finalists at high or xhigh. Fifty low drafts and five xhigh finals cost $0.37 plus $0.59, a total of $0.95. Fifty finals at xhigh would have cost $5.86. The saving is real, but it assumes the low draft predicts the high output, which you should verify on your own prompts.

Ratio changes the price too. The 1024 square is the top of the range; a 16:9 or 4:5 image at the same tier costs less, so the multipliers stay and the base moves.

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-image-2.5",
    "prompt": "Concept sketch of a rooftop garden",
    "aspect_ratio": "1:1",
    "quality": "low"
  }'

Verify the live price

Read the endpoint record for the model and divide the tier prices to confirm the ladder on today's catalog. If the ratio changes, the numbers change, but the endpoint always shows the billed amount.

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/openai/gpt-image-2.5/endpoints \
  -H "Authorization: Bearer $SUME_API_KEY" | jq '.endpoints[0].pricing'