I’ve noticed a potential inconsistency between the results from the Image Token Calculation Reference algorithm and those from the calculation tool provided in the official FAQ for gpt-5-mini image inputs.
The inconsistency is:
The multiplier given
D. Apply a multiplier based on the model to get the total tokens.
Model Multiplier gpt-5-mini1.62 gpt-5-nano2.46 gpt-4.1-mini1.62 gpt-4.1-nano2.46
Expanding the calculator on the bottom of the Public Pricing (not platform, which says nothing), these figures are found used:
Model Multiplier gpt-5-mini1.2 gpt-5-nano1.5
If the models have the same input multiplier and same patches algorithm, then any reasoning shouldn’t affect input cost, and a difference should be transparent. My own calculator loaded with the documentation:
Playground input token cost
5-nano – 2334t:
4.1-nano – 3814t
(2 message containers and text: overhead of 35 text tokens with gpt-4.1-nano)
1536 tokens x 1.5 = 2304 tokens if going by the OpenAI calculator, vs 2334 billed for context. 1.5 is right.
BAD DOCUMENTATION
Like everything else, one has to make calls over and snoop the wire to even see how the API actually is working, because platform documentation is wrong.
Independently confirming this — I measured gpt-5-mini image input tokens directly off the API and get ~1.20 tokens/patch, matching the pricing calculator, not the docs’ 1.62.
Method: send the same text prompt with and without one image, then subtract the text-only usage.input_tokens from the image request’s — that isolates the image’s contribution. Patch count is ceil(w/32) × ceil(h/32).
| image | patches | image input tokens | tokens ÷ patch |
|---|---|---|---|
| 256×256 | 64 | 77 | 1.20 |
| 512×512 | 256 | 308 | 1.20 |
| 768×1024 | 768 | 922 | 1.20 |
| 1280×720 | 920 | 1104 | 1.20 |
| 1024×1024 | 1024 | 1229 | 1.20 |
| 2048×768 | 1536 (at cap) | 1844 | 1.20 |
So for everything up to and including the 1536-patch cap, the billed/reported tokens are ceil(w/32) × ceil(h/32) × 1.20 — the documented 1.62 over-states actual usage by ~35% (1.62 ÷ 1.20 ≈ 1.35).
One thing I haven’t pinned down: the >1536-patch regime, where the image is resized to fit the cap before the multiplier. The at-cap point (2048×768 = exactly 1536 patches) is clean at 1.20, but I haven’t characterized larger images precisely — and the 1800×1200 figure above (~2334) doesn’t land neatly on either 1.20 (≈1843) or 1.62 (≈2488), so that resize step may behave differently. Curious if anyone has clean numbers for images well over 1536 patches.