GPT Image 2.5 at 1536x864: high costs 3.8x medium. Is it worth it?

For a 1536x864 image, GPT Image 2.5 high costs 3.9 times as much as medium: about $0.0105 against $0.0404 on Sume. Use medium to explore and high to finish, because the step from medium to high is the biggest jump below the top tiers.

Sume's default when you omit quality is high, so a request that never mentions quality already pays the higher price.

The ladder at 1536x864

1536x864 is an exact 16:9 box, and the blog hero image post shows why 1920x1080 does not work. Output tokens are priced at $30.00 per 1M.

A cheap way to use the gap

Generate options at medium, pick one, and regenerate only the winner at high. With four options at medium and one final at high you spend about $0.0824, against $0.2021 for five at high. The catch is that medium and high are different renders, so a medium pick can look different once rerun. Re-edit the medium image with a reference instead if you must keep its composition (edit API post).

Check it on your own account

Do not budget from a blog table alone. GET /v1/images/models lists every model with its descriptors, and GET /v1/images/models/{id}/endpoints shows the pricing line for one model. Then run one small request and read usage.cost on the response, which is the billed amount in USD; the token counts in usage are reported as 0 on this route.

Run the test at the quality and size you plan to ship, because both move the price. A single test at low quality costs under a cent for most sizes here, so it is a cheap way to confirm your assumptions before a batch.

Sync, async and failures

The /v1/images route waits up to 30 seconds for the image. If the job finishes in that window you get the result directly; otherwise you get a 202 and an async job to poll. Write your client to branch on the status code, since larger sizes and higher quality are the likely cases for a 202.

Requests are strict. A parameter the chosen model does not list returns 400 unsupported_parameter, stream returns a 400, and provider.only or provider.order accept only sume. Treat a 400 as a bug in the request, not a transient error, and do not retry it unchanged.

Caveat

The 'Sume' columns are list times 1.25 before any rounding on the job ledger and before input tokens, so read usage.cost on the response for the amount actually billed.