AI & Automation
LLM Image Token Costs: How Many Tokens Does an Image Use?
4 min read · Published June 7, 2026 · Updated October 16, 2026
There is no single answer to how many tokens an image uses in an LLM; it depends on the provider, the model, and the image's pixel dimensions, never its file size. As of October 2026: Anthropic's Claude counts 28×28 px visual patches, so a 1-megapixel (1000×1000 px) image costs 1,296 tokens, capped at 1,568 on standard models and 4,784 on Claude 4.7 and later. OpenAI's current models (GPT-5.4 through GPT-6) count 32×32 px patches with a 1.2× multiplier, so the same image costs 1,229 tokens; the older GPT-4o and GPT-4.1 use 85 base tokens plus 170 per 512 px tile (765 tokens). Google's Gemini charges 258 tokens per 768×768 px tile, so a 1-megapixel image is 1,032 tokens. Generating an image is billed separately as output tokens: 196 to 7,024 per 1024×1024 image on GPT Image 2.5 depending on quality, and 1,120 per 1K image on Gemini 3.1 Flash Image. The practical takeaway for anyone building agents is the same everywhere: inline image bytes burn through a context window fast, so the established fix is to pass file paths or URIs into the model, not the raw bytes.
Published June 2026 by the Mochify Engineering Team. The per-image figures below are drawn from each provider's current vision documentation; tokenization rules change with model releases, so dates are noted throughout.
Per-image token cost by provider
The numbers below come from each provider's current vision documentation. Tokenization rules change with model releases, so treat these as 2025–2026 figures and re-check the linked doc before you rely on a number.
| Provider | Formula | 1 MP image (1000×1000 px) | Typical photo (1920×1080 px) | Caps |
|---|---|---|---|---|
| Anthropic / Claude, standard tier (models before Claude 4.7) | ceil(width / 28) × ceil(height / 28) visual tokens, after downscaling to a 1,568 px long edge | 1,296 tokens | 1,560 tokens (downscaled to 1456×819) | 1,568 tokens per image; long edge ≤1,568 px |
| Anthropic / Claude, high-resolution tier (Claude 4.7 and later) | Same formula, downscaled only beyond a 2,576 px long edge | 1,296 tokens | 2,691 tokens (not resized) | 4,784 tokens per image; long edge ≤2,576 px |
OpenAI GPT-5.4, 5.5, 5.6 and GPT-6 (detail: high) | ceil(width / 32) × ceil(height / 32) patches, fitted to the detail level's limit, × 1.2 | 1,229 tokens (1,024 patches × 1.2) | 2,448 tokens (2,040 patches × 1.2) | 2,500-patch budget at high; 30,000 patches rejects the request |
OpenAI GPT-5.1 (detail: high) | 70 base + 140 per 512 px tile (shortest side scaled to 768 px) | 630 tokens (4 tiles) | 910 tokens (6 tiles) | detail: low is a flat 70 tokens |
OpenAI GPT-4o / GPT-4.1 (detail: high) | 85 base + 170 per 512 px tile (shortest side scaled to 768 px) | 765 tokens (4 tiles) | 1,105 tokens (6 tiles) | detail: low is a flat 85 tokens |
| OpenAI GPT-4.1-mini (patch model) | ceil(width / 32) × ceil(height / 32) patches, capped at 1,536, × 1.62 | ~1,659 tokens (1,024 patches × 1.62) | Scales to ≤1,536 patches, then × 1.62 | 1,536-patch cap before the multiplier |
| Google Gemini | Both sides ≤384 px → 258 tokens flat; otherwise 768×768 px tiles at 258 tokens each | 1,032 tokens (4 tiles) | 1,548 tokens (6 tiles) | No per-image cap stated; Google documents the tile cost, not the scaling rule |
Sources: Anthropic Claude vision docs, OpenAI vision docs, and Google Gemini token docs, all re-read October 9, 2026 (Google's token page last updated September 23, 2026). The 1920×1080 figures assume no downscaling except where the provider documents it (Claude's standard tier); Google documents the per-tile cost but not its scaling rule, so the Gemini figures are tile counts at native size.
How many tokens does generating an image use?
Generating an image is billed on a different meter from reading one. On OpenAI's GPT Image 2.5 models a generated image is charged as image output tokens at $30 per million (October 2026 rate), and the count depends on the quality setting far more than on the size: a 1024×1024 image is 196 tokens at low quality, 439 at medium, 1,756 at high, 3,122 at xhigh and 7,024 at max, which is $0.006 to $0.21 per image before any text or image input tokens. Streaming partial images adds 100 output tokens per partial. Google prices Gemini's image models per output token too: Gemini 3.1 Flash Image counts 1,120 tokens for a 1K image, 1,680 for 2K and 2,520 for 4K at $60 per million ($0.067, $0.101 and $0.151 per image), and the cheaper Nano Banana 2.1 counts 1,120 tokens per 1K image at $30 per million ($0.0336). Anthropic's API does not generate images, so there is no Claude figure.
| Model (October 2026) | Tokens per generated image | Price per image (standard rate) |
|---|---|---|
| OpenAI GPT Image 2.5, 1024×1024, low / medium / high | 196 / 439 / 1,756 | $0.006 / $0.013 / $0.053 |
| OpenAI GPT Image 2.5, 1024×1024, xhigh / max | 3,122 / 7,024 | $0.094 / $0.211 |
| Google Gemini 3.1 Flash Image, 1K / 2K / 4K | 1,120 / 1,680 / 2,520 | $0.067 / $0.101 / $0.151 |
| Google Nano Banana 2.1, 1K | 1,120 | $0.0336 |
Two things follow for agent builders. First, "how many tokens does an image use" has two answers, and the output one is the expensive one: reading a 1-megapixel photo costs about 1,000 to 1,300 input tokens on every current model, while generating a high-quality image can cost five times that in output tokens priced six to ten times higher. Second, the image you generate is a file the moment it lands on disk, and sending it back into the conversation as bytes pays the input price all over again; pass its path instead, which is the pattern the rest of this guide is about.
Sources: OpenAI image generation guide and API pricing, Google Gemini API pricing, all read October 9, 2026. Prices are USD list rates and change with model releases; re-check before relying on a number.
Why this matters for local and agent workflows
The cost is small for one image and dangerous at scale. Claude allows up to 100 images per API request on its 200k-context models, and OpenAI allows 500 image inputs per request, but the context window fills long before those hard limits bite.
It is worse on local and open-weight models. Consumer hardware typically runs models at an 8k–32k token context window. At Claude's rate of 1,296 tokens per 1 MP image, just 6 to 24 full-resolution images inline would exhaust the entire context before the model does any work. The bottleneck on memory-constrained hardware is rarely compute; it is context saturation. The same ceilings decide what a chat window does to a photo you attach: we measured what happens when you ask a chatbot to compress a photo, and the resize came first.
The fix: pass file paths, not image bytes
The durable pattern is to keep binary out of the context window and hand the model a reference instead. The Model Context Protocol resources specification is built around exactly this: resources are identified by a URI (file:///…, https://…), so an agent receives a path or identifier rather than the encoded image. Anthropic's own guidance echoes the idea, noting that referencing uploaded images by file_id keeps request payloads small regardless of how many images accumulate in a conversation.
This is where Mochify's local MCP server fits a token-cost argument cleanly. Run as mochify serve, it returns file paths and metadata to the agent, not image bytes, so a compression step never injects a multi-thousand-token blob into the model's context. You drive it in plain English, for example: compress the PNGs in ./screenshots to WebP and give me the new paths. The encoding itself runs on Mochify's API (api.mochify.app), where files are streamed into memory and wiped immediately with zero retention; the image data travels to the API to be encoded, so it is not processed on your own machine, but it also never lands in the agent's context window. The hosted MCP server follows the same principle from the other direction, returning a short-lived download URL rather than inline binary. If you're working directly in Claude Code, see our guide to how to compress images in Claude Code without bloating the context window. For a full local-workflow setup on constrained hardware, see the On-Device AI Agents guide.
Documents behave the same way. The reference-not-blob pattern extends to PDF pages in an agent pipeline, where extracting or converting a page returns a path and leaves the rendered bytes outside the model's context entirely.
Keep image bytes out of your context window
Mochify's local MCP server returns file paths, not binary, so a compression step costs a handful of tokens instead of thousands. Just describe the job - for example "compress the PNGs in ./screenshots to WebP and return the paths".