Updated July 2026. If you've ever pasted a screenshot into Claude Code, Cursor, or any AI coding agent to show it a bug, you've spent tokens you probably weren't tracking. A single full-screen capture can cost more than a page of code. This article breaks down exactly how much, using Anthropic's own published formula plus numbers measured directly rather than estimated — including a real 15-second test recording, its transcript, and the resulting review bundle.
The short version: a 1080p screenshot costs about 2,691 tokens to read (calculated), a real measured test screenshot at 1288×811 cost 1,334 tokens (measured), and the same information delivered as a spoken review with pointed frames cost about 3,500 tokens total for an entire review — narration, frames, and a written summary combined (measured). Everything below is labeled measured or calculated, because in a topic this checkable, an unlabeled number is worth nothing.
Here's the comparison that motivated this whole article, five ways of showing an agent the same broken screen, side by side:
| What you send | Token cost | Type |
|---|---|---|
| One 1080p (1920×1080) screenshot | 2,691 tokens | calculated |
| A real measured screenshot (1288×811) | 1,334 tokens | measured |
| A spoken review transcript | ~150 tokens (range 100–200) | measured |
| A complete narrated review bundle (transcript + pointed frames + summary) | ~3,500 tokens | measured |
| A 30-second screen recording frame-dumped at 1 fps | 80,730 tokens | calculated |
Two things jump out. First, a spoken transcript alone is roughly 18× cheaper than a single screenshot, while still carrying an explanation a screenshot can't. Second, the naive move — recording the screen and handing over every frame — is by far the most expensive option on the table, worse than just pasting a stack of screenshots. The rest of this article works through why, one question at a time.
How many tokens does a 1080p screenshot cost an AI coding agent?
A single 1920×1080 screenshot costs about 2,691 tokens for Claude to read, calculated from Anthropic's published high-resolution image-token formula. That's the cost of the agent looking at the pixels once — before any explanation of what's actually wrong in the image, and before it does anything about it.
That number isn't a guess. It comes from applying Anthropic's documented image-token methodology (Source: Anthropic, 2026) to a standard 1920×1080 capture. A smaller, real-world screenshot measures lower: a 1288×811 test capture measured 1,334 tokens on an M-series Mac — almost exactly half the 1080p figure, which tracks, since the pixel count is roughly half. Token cost for images isn't about file size or format; it's about how many pixels the model has to process, tiled into fixed patches.
The practical takeaway: resolution matters more than most developers assume. A screenshot cropped to just the broken component, rather than the full display, can cut its token cost proportionally — but even a tightly cropped image still costs hundreds of tokens before a single word of explanation is attached to it.
Most developers reason about token cost in terms of code — a function is X lines, a file is Y tokens — and never build the same intuition for images, because an image doesn't visibly get longer the way a paragraph does. But 2,691 tokens is not a small number next to code. It's roughly the size of a few hundred lines of a typical source file. Pasting three or four screenshots into a single message can cost more tokens than the bug report, the relevant function, and the fix combined — and none of those tokens contain a line of code the agent can act on directly.
How does Anthropic actually calculate image tokens?
Anthropic's documented formula estimates image tokens as roughly width × height ÷ 750, at the high-resolution tier, with a cap enforced by tiling the image into 28-pixel patches (Source: Anthropic, 2026). In practice this means token cost scales almost linearly with pixel count until an image is large enough to hit the tiling cap, after which additional resolution stops adding proportional cost.
This is worth understanding because it explains a counterintuitive fact: a screenshot and a photo of the same physical size can cost wildly different token counts depending on their pixel dimensions, not their visual complexity. A screenshot of a mostly-blank settings page costs the same as a screenshot of a dense code editor, if both are captured at the same resolution. The model isn't charging you for what's interesting in the image — it's charging you for the image's geometry.
Working the formula by hand makes this concrete. Take the two real numbers from earlier: a 1920×1080 screenshot is 1,920 × 1,080 = 2,073,600 pixels, divided by 750, which lands close to the 2,691-token figure once the patch-tiling adjustment is applied. A 1288×811 screenshot is 1,288 × 811 = 1,044,568 pixels — roughly half the pixel count of the 1080p image, which is why its measured cost, 1,334 tokens, comes out to almost exactly half of 2,691. The formula isn't a black box; it's a straightforward area calculation with a resolution cap on top, which is exactly why it's possible to estimate a screenshot's cost before ever sending it. For a full breakdown of the formula with worked examples at different resolutions, see Claude's image-token formula, explained.
Does Claude charge more for a higher-resolution image?
Yes. Because the formula scales with width times height, a higher-resolution capture of the same screen content costs proportionally more tokens, up to the 28-pixel-patch tiling cap. A full 1920×1080 screenshot (2,691 tokens, calculated) costs roughly double a smaller 1288×811 capture (1,334 tokens, measured) — almost exactly the ratio of their pixel counts.
This has a direct implication for anyone pasting screenshots into a coding agent: capturing at your full display resolution, or on a Retina display without downscaling, is the most expensive way to hand an agent a bug report. Cropping to the relevant window or component, rather than the full screen, is a free lever most developers never pull.
How much does a screenshot cost in dollars, not just tokens?
At $10 per million input tokens, one 1080p screenshot costs roughly $0.027 — trivial on its own. The costs that actually matter show up at volume: a 30-second review frame-dumped at 1 frame per second runs 80,730 tokens, about $0.81 (calculated), against roughly $0.04 for a complete narrated review bundle covering the same 30 seconds (measured).
Four full-page screenshots to cover one longer page, with zero narration explaining what's wrong in any of them, already runs 10,764 tokens (calculated) — nearly $0.11 before the agent has been told what to actually fix. None of these are large numbers in isolation. They add up over a session, a day, or a week of iterative review, especially for developers on a capped usage plan rather than metered API billing, where the cost isn't dollars but how much of the day's usage limit just evaporated on pixels instead of problem-solving.
That distinction matters because most individual developers aren't paying per token — they're on a Claude Pro or Max plan with a rolling usage allowance, where the currency isn't dollars, it's how much of the day or week is left before the limit resets. Dollar figures make the comparison legible, but the real cost for that audience is time: fewer review cycles fit into the same window when each one starts by spending a third of a context window on pixels. A $0.81 frame dump doesn't show up on an invoice for a Pro or Max user — it shows up as the agent running out of room to think three exchanges earlier than it otherwise would have.
Is a screen recording cheaper than a screenshot for an agent to read?
Not on its own — coding agents can't watch video. A raw recording is cheap to store (6.7 MB for a 15-second capture, measured) but has to be converted into individual frames before any agent can read it, and a frame-dumped recording costs far more in tokens than a handful of well-chosen screenshots ever would.
This is the trap: recording feels like the more complete way to show an agent a bug, since it captures everything rather than one static moment. But "everything" is exactly the problem. A 30-second recording, converted at a modest 1 frame per second, produces 30 separate images — each one priced like a full screenshot. That's 80,730 tokens (calculated), which is 23× more than a complete narrated review bundle covering the same 30 seconds (a 96% reduction, calculated). The video itself isn't the expensive part; the naive conversion of it into frames is. For the full mechanics of why agents can't consume video directly and what actually happens when a screen recording gets converted for an agent, see why your agent can't watch a screen recording.
One frame per second is already a generous compromise — most screen activity doesn't change meaningfully that often, so even 1 fps is over-sampling a static settings screen while under-sampling a fast scroll. Push the sample rate up to capture fast-moving UI more faithfully and the token cost climbs linearly with it; pull it down to save tokens and you risk missing the exact moment something broke. There's no frame rate that makes naive frame-dumping cheap — the fix isn't a better sampling rate, it's not sampling blindly at all, and instead selecting frames based on where a person actually pointed or spoke.
How many screenshots can I paste before I burn through my usage limit?
It depends on the size of your context window, but the math moves fast. Four full-page screenshots already cost 10,764 tokens with no narration attached. A 30-second recording frame-dumped at 1 fps costs 80,730 tokens — close to 40% of a 200k-token context window gone (calculated) before the agent has read a single line of your explanation, let alone started fixing anything.
For a developer on a capped Claude plan, that 40% isn't an abstraction — it's a real chunk of the day's usage spent on the agent looking at pixels rather than reasoning about code. A few habits keep this from happening:
- Crop before you paste. Capture just the broken component or window, not the full display — token cost scales with pixel area, so a tighter crop is a direct token savings.
- Batch fewer, better screenshots. Four screenshots at 10,764 tokens with no explanation communicates less than one screenshot plus a sentence of context, at a fraction of the cost.
- Avoid frame-dumping recordings. If a tool converts your screen recording to one frame per second automatically, check how many frames that produces before you send it — 30 seconds becomes 30 full-price images.
- Prefer narration to repetition. A spoken description of what's wrong costs roughly 150 tokens and can replace several redundant screenshots of the same broken state from slightly different angles.
Is a spoken description cheaper than a screenshot for an agent to read?
Yes, by a wide margin. A typical spoken review transcript measures roughly 150 tokens (measured, range 100–200), against 2,691 tokens for a single 1080p screenshot (calculated) — and unlike a screenshot, narration tells the agent why something is wrong, not just what it looked like at one instant.
A real test case makes this concrete: a 15-second spoken walkthrough of a screen transcribed to just 65 tokens (measured) — a fraction of a single screenshot's cost, while adding information a screenshot alone can't carry, like intent, urgency, and which specific part of the screen actually matters. This is the asymmetry most developers haven't priced in: screenshots are expensive and mute, while a few spoken sentences are cheap and explicit.
Transcripts alone aren't a complete answer, though — a spoken review still needs to point at something, or "it's broken over here" carries no more information in text than it did out loud. That's why the measured 65-token and ~150-token figures above are for narration alone, not a full review. Pair the transcript with even one or two frames tied to what was actually said, and the total cost stays close to the transcript's, while the information content jumps back up to screenshot-level or beyond, because the frame is no longer doing all the explaining by itself.
What can I send my agent instead of raw screenshots?
The cheapest and most informative option is a bundle that pairs a short narration with only the frames it actually points to, rather than a pile of full screenshots or a raw recording. A measured example of this — transcript, pointed frames, and a written summary together — runs about 3,500 tokens total for a complete review (measured), against 80,730 tokens for the naive frame-dump equivalent.
This is the idea behind giving your agent visual feedback without burning your usage: instead of showing an agent everything and letting it guess what matters, you narrate what's wrong while pointing at it, and only the frames tied to your voice get included. It's not a new idea — several tools now convert screen recordings into agent-readable bundles this way, and it's worth understanding what a REVIEW.md bundle actually contains before choosing one, since the format determines how much of that 3,500-token budget goes to signal versus noise.
How do I check my own token cost before pasting a screenshot?
You don't need a tool to check this — Anthropic's image-token formula is public, and the arithmetic takes seconds: multiply an image's width by its height, divide by 750, and you have a close estimate of its token cost before you ever paste it. Run that math once on a full-screen capture and the habit of pasting three or four of them per message tends to change on its own. The steps:
- Get your image's pixel dimensions. Most screenshot tools show this in the file's properties or export dialog (e.g., 1920×1080, 1288×811).
- Multiply width by height, then divide by 750. This approximates the high-resolution-tier token cost per Anthropic's published formula (Source: Anthropic, 2026).
- Multiply by the number of screenshots you're about to paste in one message, not per message — agents read everything in a conversation turn together.
- Compare against your budget, whether that's a metered API cost (tokens ÷ 1,000,000 × your per-token rate) or a rough share of your context window (tokens ÷ your model's context size).
- Crop and recount if the number looks high — cropping to the relevant region is the single fastest way to bring the cost down, since it directly reduces the width × height term.
Running this math once tends to change habits permanently. Most developers who paste four or five screenshots into a debugging session have never multiplied those out — 2,691 tokens each stops feeling trivial once it's five of them in a row.
The bottom line
None of this is a case that screenshots are useless — sometimes a single well-cropped image is exactly the right amount of information. The case is narrower: pasting screenshots by habit, or worse, frame-dumping a screen recording, spends tokens on pixels when a sentence of narration plus one pointed frame would have communicated more for less. Several tools now approach this differently — narrated review over frame dump, pointer-selected frames over full captures — and it's worth comparing them directly; see how Walkie compares to Clipy and Loom for how the category's current tools handle this tradeoff, including tools priced as a monthly subscription and at least one, Walkie, priced as a one-time purchase.
Walkie is one entry in that category — a Mac app that records your screen and voice while you point at what's wrong, then hands your coding agent a bundle built for reading rather than watching. It's not the only tool doing this, and it isn't a replacement for a well-cropped screenshot when that's genuinely all a bug needs. It's built for the moment a screenshot alone can't carry enough meaning, and a full recording carries too much.