{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibpoaqkk5vong4kdho4pi524kmpaq6cqpt7d54ledociov2w6figa",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3moh6hx44j5e2"
  },
  "path": "/t/gpt-5-mini-image-input-token-calculation-discrepancy-with-official-faq-formula/1344040#post_3",
  "publishedAt": "2026-06-17T01:06:06.000Z",
  "site": "https://community.openai.com",
  "textContent": "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.\n\nMethod: 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)`.\n\n**image** | **patches** | **image input tokens** | **tokens ÷ patch**\n---|---|---|---\n256×256 | 64 | 77 | 1.20\n512×512 | 256 | 308 | 1.20\n768×1024 | 768 | 922 | 1.20\n1280×720 | 920 | 1104 | 1.20\n1024×1024 | 1024 | 1229 | 1.20\n2048×768 | 1536 (at cap) | 1844 | 1.20\n\nSo 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).\n\nOne 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.",
  "title": "GPT-5-mini image input token calculation discrepancy with official FAQ formula"
}