What a Screenshot Costs an AI Agent: 25,457 Tool Results Measured

A screenshot handed to an agent cost me a median of 2,054 tokens. Reading one file cost 2,085. That is a difference of one percent, and it is the opposite of what everybody assumes.

The assumption is understandable. Open a transcript and a screenshot looks enormous — about 123 KB of base64 sitting in the middle of your conversation, dwarfing every other line. So people avoid vision, scrape the DOM instead, and pipe text into the model because text feels cheap.

I measured 25,457 tool results across 329 sessions, six weeks of real billed work, and text is not cheap. It is unbounded, which is worse. A screenshot's cost is set by pixel area, so it lands in the same narrow band every time. A file read is set by how long the file happens to be, and files have no upper limit.

That difference does not show up in the average. It shows up in the tail, and the tail is what wrecks a context window.

What a tool result actually costs

Each row below is the median growth in the prompt of the assistant turn that follows that kind of tool result. That is where a tool result is actually billed: not in its own line, but in every prompt after it.

Read the last column before the first. It is the ratio between a typical result and a bad one, and it separates the tools you can budget for from the ones you cannot.

Is a screenshot expensive?

No. At the median it costs the same as reading a single file, and at the tail it costs one fifth as much. Screenshot p99 is 6,140 tokens; file read p99 is 29,824.

The mechanism is not subtle. An image is billed by area, and a screenshot of a browser window is always roughly the same area, so the cost lands between 1,800 and 3,600 tokens over and over. There is no screenshot that is fifty times larger than a normal screenshot.

Text has no such governor. cat a 40-line config and you pay for 40 lines. cat a 4,000-line lockfile and you pay for 4,000. Same tool, same call, two orders of magnitude apart — and nothing in the call site tells you which one you are about to get.

That is why screenshots came out as the most predictable tool in the entire set, at 1.7× between median and p90. File reads were the least predictable, at 5.5×.

Then what is actually running up the bill?

Bash, by sheer volume. It was 64% of all tool results — 16,293 of 25,457 — at the second-lowest median in the table.

This is the same shape I found measuring 23,968 turns of prompt-to-output ratio and again measuring what delegation actually costs. The bill is not built from a few dramatic events. It is built from thousands of small ones that never get deleted, because every one of them stays in the prompt for the rest of the session.

Charging the first cache write only — the conservative floor — bash accounted for roughly $183 of about $319 across the window. Screenshots accounted for $21. The thing people avoid is six percent of the problem.

The three traps in measuring this

Every one of these produced a confident wrong number before it was caught, and two of them would have inverted the article's conclusion.

Base64 length is not token count. A screenshot occupies about 123 KB of base64 in the transcript. Taking that as the cost makes an image look roughly fifty times more expensive than it is, because the model bills images by pixel area and never sees the base64 as text. This one is seductive: the raw file makes vision look catastrophic, and that matches what everybody already believes.

Key signatures, not key guesses. Classifying results by "does this dict contain content" put 635 Write results into the Read bucket alongside 605 real reads. The headline of this article is a comparison between screenshots and file reads, so a bucket that is half writes is not a rounding error — it is a different article. Classify on the exact key signature (file for reads, structuredPatch+content for writes, stdout for bash).

Streaming repeats message.id. Counting rows instead of unique message ids multiplies turns and every per-turn figure derived from them.

And one that is not a data trap but a thinking one. The first version of this measurement asked "how much more do screenshot turns cost than normal turns" and got 1.59×, below the threshold I had set for the finding to be worth publishing. The correct response was to drop the thesis, not to soften the threshold. The article you are reading exists because the answer to a different comparison — screenshots against file reads specifically — turned out to be interesting in the other direction.

What to do about it

Cap the tools that have no ceiling, and stop rationing the one that does.

Read ranges, not files. A file read's p99 was 29,824 tokens, fourteen times its own median. Passing an offset and a limit converts an unbounded cost into a bounded one. When you only need to know whether a symbol exists, grep for it — search has a higher median than a read but a far shorter tail, 14,833 against 29,824 at p99.

Do not read the same file twice. In this window there were 325 redundant reads against 717 unique files, a 45% overhead on top of a tool that is already the most volatile in the set. Re-reading a file you edited is the common case, and it is almost never necessary — the edit already told you what changed.

Take the screenshot. It is the cheapest way to find out what a page actually looks like, it cannot surprise you by being twenty times larger than expected, and the DOM dump you were going to use instead lands in the unbounded column.

Delegate before your context is huge, not after. A tool result costs its listed price once and then rides along in every later prompt. Work handed to a subagent leaves nothing behind in the parent, which is why a subagent turn cost a third of a main-loop turn — it carries less, not because it is billed differently.

Watch bash output, not bash count. Sixty-four percent of results came from bash. A command that prints a whole file is a file read wearing a different hat, and it does not show up in anybody's mental model of "I just ran one command."

How I measured this

Every Claude Code session writes a JSONL transcript under ~/.claude/projects/, and every assistant record carries a usage block with real token counts. A tool result does not carry its own price, so the cost is derived from what happens next: the growth in the following turn's prompt.

p = (u["input_tokens"] + u["cache_creation_input_tokens"]
     + u["cache_read_input_tokens"])
if prev is not None and pending_tool_kind:
    delta = p - prev            # what this result added to the prompt

Results are classified by the exact key signature of toolUseResult: stdout means bash, file means a read, structuredPatch with content means a write, an image block inside tool_result means a screenshot. Turns are deduplicated by message.id. Deltas above 400,000 tokens are dropped as session boundaries rather than tool results.

The window is 2026-07-16 to 2026-08-28: 329 sessions, 25,457 classified tool results, 1,351 screenshots. Dollar figures use list pricing with the 1.25× cache-write multiplier and count only the first write.

Three limits worth stating. This is one developer's tool mix, and a heavier browser-automation practice would shift the screenshot share well above 5.3%. Screenshot cost depends on capture resolution, so a 4K display would move that row and not the others. And the delta method attributes the whole prompt growth to the preceding tool result, which slightly overcounts when the user typed something in the same gap — that inflates every row roughly equally, so the ranking holds even though the absolute numbers are soft.

FAQ

How many tokens is a screenshot?

Measured across 1,345 screenshots, the median added 2,054 tokens to the prompt, with a p90 of 3,588 and a p99 of 6,140. The base64 blob in the transcript is around 123 KB, but that is storage, not billing — images are priced by pixel area, so capture resolution sets the cost.

Is computer use expensive compared to reading files?

No. A screenshot and a single file read cost almost exactly the same at the median, 2,054 against 2,085 tokens. At the 99th percentile the file read costs nearly five times more, because an image's size is bounded by the screen and a file's is not.

What makes an AI agent's context fill up fastest?

Volume of ordinary results, not size of dramatic ones. Bash was 64% of all tool results here, at a median of 1,278 tokens each. Nothing gets removed from a prompt once it is in, so thousands of small outputs outweigh a handful of large ones.

Should I use screenshots or scrape the DOM for browser agents?

Screenshots, on cost grounds. A DOM dump is text with no upper bound and lands in the same category as an unbounded file read, whose p99 was 29,824 tokens. A screenshot cannot exceed roughly 6,000 tokens at the same percentile.

Does reading a file with an offset and limit actually help?

Yes, and the size of the win is the gap between a file read's median and its tail: 2,085 tokens against 29,824 at p99. Ranged reads convert an unbounded cost into a bounded one, which matters more than the average saving.

How do I measure this on my own machine?

Parse the JSONL transcripts under ~/.claude/projects/, deduplicate assistant turns by message.id, and take each turn's prompt total minus the previous turn's. Attribute that delta to whichever tool result arrived in between, classifying by the key signature of toolUseResult rather than by guessing on field names.

The part worth keeping

The instinct that images are heavy comes from looking at bytes on disk. Bytes on disk are not what you are billed for, and the tool that looks alarming in a text editor turned out to be the only one in the set whose cost you can predict before you call it.

Predictability is the property that matters when a budget is finite. A tool with a known ceiling can be planned around. A tool without one can only be regretted afterwards, and the one people reach for to avoid the expensive option is exactly that tool.