Tokens in a 1280x720 GPT Image 2.5 image: 106 to 3,787

A 1280x720 GPT Image 2.5 image is about 106 output tokens at low, 246 at medium, 947 at high, 1,683 at xhigh and 3,787 at max. At OpenAI's $30.00 per 1M output tokens, that is $0.0032 to $0.1136 per image before input tokens.

These counts come from the estimator Sume's repo uses for admission, which follows OpenAI's image-token calculator for the 2.5 models. They are estimates; the billed amount is on the response.

Tokens, dollars and images per million tokens

How the count is built

The estimator uses a grid per quality: 16 for low, 24 for medium, 48 for high, 64 for xhigh and 96 for max. It scales the grid to the short edge, then multiplies by the pixel count. Quality sets the grid, and size changes the count only mildly, which is why a 4x larger image costs far less than 4x more.

For the same math in a script you can run, see the Python cost calculator.

Why bother with tokens

OpenAI's page lists tokens, not images, so a budget needs a size and a quality before it has a number. Sume's response reports usage.cost in dollars and token counts of 0, so the table is for planning, and the response is for reconciling.

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.