An image sent to Claude is billed as input tokens, and the count is a function of its pixel dimensions rather than its file size. Anthropic publishes the arithmetic, which means you can price a vision workload before you send a single request.
The documented formula
Anthropic’s vision documentation gives the estimate as width in pixels multiplied by height in pixels, divided by 750:
tokens ≈ (width_px × height_px) / 750
File size does not appear anywhere in that expression, and neither does format. A 4 MB PNG and a 300 KB JPEG of the same 1200×800 scene cost the same number of tokens. Compressing an image harder saves upload bandwidth and saves you nothing at all on the bill; resizing it saves both.
The reason the divisor is a round number is that it is an approximation of a patching step. The image is cut into fixed-size patches, each patch becomes a small number of embedding positions, and the total scales with area rather than with either edge. Doubling both edges quadruples the token count, which is the single most useful consequence of the formula: a “slightly bigger” screenshot is not slightly more expensive.
Anthropic describes this as an estimate, not an invoice. The number that is billed is the one that comes back in usage.input_tokens, and the number you can check in advance is the one from the count_tokens endpoint, which accepts image blocks. Use the formula for capacity planning and the endpoint for anything that has to be right.
Formula and limits as documented by Anthropic on its vision page at the time of writing. See Anthropic’s vision documentation. Image handling is an area vendors revise; re-check before you build a budget on it.
Three real images, worked
Three sizes you actually encounter: a small UI screenshot, a web-resolution photograph, and a photo straight off a phone camera.
A. 640 × 480 screenshot
640 × 480 = 307,200 px
307,200 / 750 = 409.6 → ~410 tokens
B. 1200 × 800 web photo
1200 × 800 = 960,000 px
960,000 / 750 = 1,280 → ~1,280 tokens
C. 4032 × 3024 phone photo (12 MP, 4:3)
4032 × 3024 = 12,192,768 px
12,192,768 / 750 = 16,257 → not what you are charged;
see the resize ceiling below
A and B pass through unchanged: both are under the long-edge limit and both land under the per-image token ceiling. C does not, and that is the case worth understanding, because it is the one most real uploads fall into.
The resize ceiling
Anthropic documents two limits that together cap what one image can cost. If the long edge exceeds 1568 pixels, the image is scaled down before it reaches the model. And an image is scaled so that it does not exceed roughly 1,600 tokens, which working the formula backwards is about 1.15 megapixels.
Apply both to image C. The first limit scales the long edge to 1568, preserving the 4:3 aspect ratio:
1568 / 4032 = 0.3889 scale factor
3024 × 0.3889 = 1176
1568 × 1176 = 1,843,968 px
1,843,968 / 750 = 2,458 tokens → still above the ~1,600 ceiling
So a second reduction applies, down to about 1.15 megapixels. At 4:3 that is roughly 1238 × 928:
1238 × 928 = 1,148,864 px
1,148,864 / 750 = 1,531.8 → ~1,530 tokens
Assumptions labelled: 1.15 MP is derived from the documented
~1,600-token ceiling (1,600 × 750 = 1,200,000 px), and the exact
output dimensions Anthropic picks are its choice, not yours. The
ceiling is the documented figure; the intermediate dimensions here
are a worked illustration of it.
The practical reading: no single image costs much more than about 1,600 tokens, whatever you upload. A 12-megapixel photo and a 2-megapixel photo of the same scene cost roughly the same, because both are flattened to the same ceiling — and the 12-megapixel one costs you the upload time and, more importantly, the detail. Downscaling happens without regard for what you needed to see. If the model has to read small text in a photograph, crop to the region rather than sending the whole frame and hoping.
The corollary for small images is the mirror of it. Below the ceiling you pay in proportion to area, so 640×480 really is a third of the cost of 1200×800. There is no minimum charge that makes small images pointless.
This changes the shape of a document-reading pipeline more than it first appears. Suppose you have an A4 page scanned at 300 dpi, which is about 2480×3508 pixels, and the thing you need off it is a total in the bottom right quadrant. Sending the whole page costs the ceiling, about 1,600 tokens, and the model receives that quadrant at roughly a quarter of the resolution the downscale left, which is a fraction of what you scanned. Sending a 900×600 crop of the quadrant costs 540,000 / 750, about 720 tokens, and the model receives the region at full scanned resolution. You paid less than half and gave the model several times the detail. Every rule of thumb that says “send the whole page, the model will find it” is inherited from tools where resolution was not the binding constraint.
The same reasoning argues against the opposite instinct — stitching several small images into one contact sheet to save on per-image overhead. There is no meaningful per-image overhead to save. Area is area, and a tiled composite of nine screenshots is downscaled as one image, so each tile ends up at a ninth of the resolution it would have had on its own, for the same total token cost as sending them separately. Send them separately.
Turning tokens into money
Image tokens are input tokens and are billed at the model’s input rate. Taking a Sonnet-class input price of $3 per million tokens, which is the figure Anthropic has published on its pricing page for that tier at the time of writing:
Assumption: $3.00 per 1,000,000 input tokens (Sonnet-class).
A. 410 tokens × $3 / 1,000,000 = $0.00123 per image
B. 1,280 tokens × $3 / 1,000,000 = $0.00384 per image
C. 1,530 tokens × $3 / 1,000,000 = $0.00459 per image
At the ceiling, 1,000 images ≈ 1,530,000 tokens ≈ $4.59
plus whatever text accompanies them.
That last line is the one to hold on to. A vision pipeline processing a thousand photos a day costs a few dollars a day in image tokens, and the surrounding prompt — instructions, few-shot examples, tool definitions — is frequently the larger half of the bill. If you are optimising a vision workload and you have not counted the system prompt, you are probably optimising the wrong thing.
Prices change and tiers differ per model. Check Anthropic’s pricing page for the current rate for the specific model id you are calling, not for its family.
Per-request limits, and how to check
- Images per request. The API accepts multiple image blocks in a single user message, with a documented per-request cap that is lower on claude.ai than on the API. If you are building a batch reader, that cap sets your page-per-call size — see multiple images per request.
- File size. There is a documented per-image byte limit as well as the dimension limits, and it is enforced on the base64 payload, which is about a third larger than the raw file.
- Formats. JPEG, PNG, GIF and WebP, supplied either as base64 or by URL. The choice does not affect token cost.
- Caching. Image blocks can sit inside a cached prefix like any other content, which matters a great deal if the same reference image is sent on every request.
The images-per-request cap deserves a moment of planning rather than a retry loop, because hitting it is a validation error and not a throttle. If you are processing a fifty-page scan, the batch size is decided by that cap and by the context window together, and the window is usually the tighter of the two: fifty pages at the ceiling is 80,000 tokens before you have written a prompt. Work out the batch size from the arithmetic once, at design time, rather than discovering it as a 400 in production.
To settle any of this for a specific image, send the exact message array to /v1/messages/count_tokens instead of /v1/messages. It accepts image content blocks and returns the input token count the real call would be billed for, at no charge. That is a better answer than any formula, and it takes one request.
One last thing the formula cannot tell you, and which is the actual cost driver in most vision applications: images are input, and input is the cheap half. A pipeline that sends one 1,530-token image and receives a 900-token structured description is paying more for the description than for the picture at typical output rates. Optimising image size is worth doing and it is not where the money is. Ask for less output.
Top comments (0)