A 2MB screenshot costs the same as a 623-byte one: 3,135 tokens

Everything else on this site measures text. This is the first measurement of what a picture costs, and the answer contradicts the two things most people assume: that a big file costs more than a small one, and that a higher-resolution screenshot buys the model more detail.

Neither is true.

File size is completely irrelevant

Three images, all 1568x1568, all read the same way:

Image	File size	Cost
Flat colour PNG	623 bytes	+3,135
Detailed noise PNG	2,096,644 bytes	+3,140
Detailed noise JPEG	1,480,602 bytes	+3,138

A 3,366x range in file size produces a 5-token difference, which is inside the run-to-run noise. Compression ratio does not matter. Format does not matter. Visual complexity does not matter. Only the pixel dimensions matter.

That is worth internalising, because the instinct to pngquant a screenshot before handing it over is pure superstition as far as context goes. It will make the file smaller and cost you exactly the same.

The cost stops growing at 2000px

Reading an image wider or taller than 2000px causes Claude Code to resize it before it leaves your machine, and to tell the model it did:

[Image: original 3072x3072, displayed at 2000x2000.
 Multiply coordinates by 1.54 to map to original image.]

The long edge is clamped to 2000, aspect ratio preserved. Below that, images pass through untouched: a 1568x1568 and a 1024x1024 produce no such note.

The consequence is a hard ceiling on what an image can cost you:

Sent	Pixels reaching the model	Cost
1024x1024	1,048,576	+1,370
1568x1568	2,458,624	+3,135
2048x2048	4,000,000 (resized to 2000x2000)	+4,804
3072x3072	4,000,000 (resized to 2000x2000)	+4,798
3840x2160	2,250,000 (resized to 2000x1125)	+2,994

A 3072x3072 image costs the same as a 2048x2048 one. It has 2.25x the pixels and every one of the extra ones is discarded before the request is sent. Anything you render above 2000px on the long edge is work your machine does for nothing.

Aspect ratio matters more than resolution

Look at the last row again. A 4K 16:9 screenshot, 8.3 million pixels, costs 2,994 tokens. A 2048x2048 square, half as many pixels to begin with, costs 4,804.

The 4K image is 38% cheaper than the smaller square, because after the long edge is clamped to 2000 a 16:9 frame holds 2.25M pixels and a square holds 4M. Once you are above the cap, the shape of your image decides the price and the resolution is irrelevant.

Retina screenshots cost 1.69x for the same picture

This is the part with an actual fix attached. macOS captures at the display’s backing scale, so a full-screen grab on a 1470x956 retina display is a 2940x1912 file.

What you captured	Cost
1470x956 (logical)	+1,850
2940x1912 (same screen, retina 2x)	+3,132

1.69x for identical content. The retina version does not contain more information about your terminal or your browser window, it contains the same information at a scale factor. And because the 2x version is over the cap, it is downscaled anyway, just to 2000x1301 rather than to something you chose.

sips -Z 2000 shot.png before you hand it over, and you keep everything the model can actually resolve.

Some rough conversions

Reading text into context costs about 0.35 tokens per byte. Against that:

Image	Roughly equivalent to
1024x1024	3.8 KB of source
1568x1568	8.8 KB of source
4K 16:9 screenshot	8.4 KB of source
2000x2000	13.5 KB of source

So a screenshot is not the expensive item people fear. A full 4K capture costs about what a medium source file costs. What makes it expensive is the round trip: that image is re-sent with every subsequent tool call for the rest of the session, so a 4,800-token screenshot taken early in a twenty-call session is not 4,800 tokens, it is 4,800 tokens twenty times over.

Cost tracks pixels, at roughly one token per 750 to 830

Across every size measured, dividing pixels by the token cost lands between 672 and 834, drifting upward as images get larger. The published guidance of one token per 750 pixels is a good approximation at the small end and increasingly generous at the large end.

I am not going to claim a formula from this. The ratio is not constant, the drift is monotonic but I did not establish why, and the measurement I can defend is the cost, not the mechanism. If you want a planning number, one token per 800 pixels of what actually reaches the model is within 6% everywhere I measured.

Practical upshot

1. Stop compressing images to save context. It saves nothing.
2. Stop capturing above 2000px on the long edge. It is discarded.
3. On a retina display, downscale before sending and pay 59% of the price for the same picture.
4. Prefer a wide crop to a square one. Above the cap, 16:9 is materially cheaper than 1:1.
5. Take the screenshot late rather than early, because everything in context is re-sent on every round trip.

Method

Eleven configurations, each measured twice, each against a 1x1 PNG baseline read in the same batch through an identical prompt with an identical filename length. Cost is the context size of the final API call, from usage.iterations. Every arm returned the same one-word answer in the same number of turns, so nothing here is a difference in how much the model chose to say.

Reproducibility was strong: the largest gap between the two rounds of any configuration was 9 tokens.

Two harness failures are worth naming, because both produced clean-looking numbers that were entirely fake. In the first, a shell variable expanded inside a subshell after a cd, so every run was asking for a path that did not exist. The model politely said so and the token counts came out beautifully consistent, because they were measuring nothing. In the second, the file sat outside the working directory and every read was denied. Both runs looked like data.

What caught them was a control that had to succeed: an image with a word rendered into it, where the model had to return the word. It did, twice, which is the only reason I believe the pixels ever reached the model. A measurement of a thing you never verified happened is not a measurement of zero, it is not a measurement.

All figures against Claude Code 2.1.224, headless mode, usage from --output-format json.