GPT Image 2.5 at 2560x1440: 4x the pixels of 720p, about 2x the price

Moving from 1280x720 to 2560x1440 gives four times the pixels, but the GPT Image 2.5 output price rises by only about 1.9x. That is because the token estimate does not grow in proportion to the pixel count.

If your thumbnails are shown on retina or large displays, the larger box is cheaper per pixel than you might expect.

The comparison

List prices below are output tokens at OpenAI's $30.00 per 1M rate, from the estimator in Sume's repo. Sume bills the provider list price times 1.25, as this worked-examples post shows.

When the bigger box is worth it

At medium the extra cost is $0.0070 list per image. If you would otherwise generate at 720p and upscale, compare against the upscale step in your pipeline; the upscaler API post covers that route.

The tradeoff is latency. Bigger and higher-quality renders take longer, and Sume's /v1/images route waits up to 30 seconds before it answers with a 202 job; read the status code, not just the body.

What stays the same

Both sizes are legal: 2560 and 1440 are multiples of 16, and the pixel count is under 8,294,400. Quality still dominates the bill. Moving from medium to high at either size costs more than moving from 720p to 1440p, so choose quality first and size second.

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.