The pricing grids for image models talk in dollars per million tokens. Yet a token was supposed to be a fragment of a word. Charging for a photograph in the same unit as a paragraph looks like an accounting oddity. It isn't one: it's the exact description of what the model handles.
We have explained text tokens without ever covering their visual equivalent. Let's fix that, because it's what explains all image billing.
A token was never a word
That's the initial misunderstanding. A token is simply the elementary unit of data that the model processes, whatever its nature.
For text, it is split into fragments of around four characters. This splitting is anything but obvious: it results from an algorithm that identifies the most frequent sequences. That is why the same content does not consume the same number of tokens depending on the language, as we saw with the effective rise in Sonnet 5.
For an image, the same principle is applied in two dimensions.
The mosaic
An image is split into small squares, typically 16 or 32 pixels on a side. Each square becomes a token.
The calculation then becomes very simple. A 1024 by 1024 pixel image, split into 32-pixel tiles, gives 32 tiles across and 32 down, or around 1024 tokens.
The model therefore never sees pixels. It sees a mosaic of tiles, exactly as it sees a sentence as a series of fragments. And it processes them with the same mechanism: each tile is compared with all the others to build a representation of the whole.
This is, incidentally, what explains why the techniques developed for language have transferred so well to images: at that level of abstraction, they are the same objects.
The splitting works in both directions, and that is the key to billing. When you supply a reference photo, it is split into tiles and billed as input, at around 8 dollars per million. When the model produces an image, it generates a series of visual tokens, one after another, exactly as it produces words, and a decoder turns them back into pixels. Those tokens are billed as output, at around 30 dollars per million. A retouch therefore makes you pay for the image you send on top of the one you receive. On editing work with several references, you should count on a multiplier of two to three compared with a simple generation.
What resolution really changes
Here is the most useful consequence to understand.
Doubling the width and height of an image does not double its cost: it quadruples it, since there are four times as many tiles. The relationship is quadratic, not linear.
The estimates commonly cited for an image 1024 pixels on a side range from around 0.006 dollars at low definition to around 0.21 at high. At 30 dollars per million output tokens, that corresponds roughly to 200 tokens on one side and 7,000 on the other. Same image, same displayed size, but a much finer split.
This is exactly why OpenAI replaced the "quality" setting with a choice of explicit resolution. Resolution corresponds directly to the number of tokens, and therefore to the price, and you know what you will pay before launching the generation. That is more honest than a slider whose effect on the bill nobody knows.
What this implies in practice
Iterate at low definition. This is the most cost-effective advice. As long as you are looking for a direction, definition adds nothing: you are judging a composition, not a texture. Only move up in resolution once the direction is found.
Resize your references. Sending a twelve-megapixel photo as a reference gets it split into a considerable number of tiles, whereas a reduced version conveys the same information to the model. This is often the biggest saving on editing work.
Use the cache. If you reuse the same reference image across several requests, the cached input rate is around four times lower. It is the same mechanism as the one described in our article on caching.
Count in attempts, not images. Since the price per image is fixed, what decides your bill is the number of attempts. A model that satisfies you in three attempts costs three times less than an equivalent model that needs ten, at an identical rate. This is what we noted about the release of Images 2.5.
What to take away
Billing an image in tokens is not an arbitrary convention: it is the literal description of what happens. The model splits, processes and produces tiles, and you pay for the number of tiles.
Once you have that picture in mind, the whole grid becomes readable. Input costs less than output because reading is simpler than producing. Resolution weighs as the square because it multiplies tiles in two dimensions. And editing costs more because you pay for both images.
It is the same lesson we draw everywhere: the displayed rate does not tell you what you will pay. What decides is the billing unit and what you consume of it without thinking.