Updated August 2026. If you have ever pasted three or four screenshots into a chat with your coding agent just to show it a layout bug, you have probably wondered whether that habit is quietly eating your usage. It is — and the fix is not fewer screenshots, it is a different workflow: narrate, point, and only spend pixels on what actually needs them. The category this sits in is covered in the pillar on visual feedback for AI coding agents.
How do I show Claude Code a UI bug?#
Narrate what's wrong out loud while you point at or circle the exact spot on screen, then hand the agent a transcript plus the one or two frames that actually need pixels — not a folder of full-page screenshots. The narration carries the reasoning ("this button should be centered, not left-aligned"); the image only needs to confirm what words can't fully convey.
This matters more than it sounds like it should, because most people default to the opposite. They screenshot the whole window, then type a paragraph describing what's wrong in it — paying for both the expensive format and the explanation the format was supposed to make unnecessary.
What's the cheapest way to give an agent visual context?#
Talking. A typical narrated review transcript measures about 150 tokens (measured, range 100-200), against 2,691 tokens for a single full 1080p screenshot on the high-resolution tier — Claude 4.7 and later, which caps any single image at 4,784 visual tokens. Dividing 2,691 by 150 gives roughly 18, so the same review costs about 18 times more as pixels than as speech.
The reason is structural, not incidental: text is nearly free to send an LLM, while images are billed by pixel area regardless of how little visual detail matters to the fix. Anthropic's vision documentation states the rule exactly — an image costs ceil(width / 28) x ceil(height / 28) visual tokens — which is why a full screen capture costs so much more than the bug it is illustrating. You can run your own dimensions through the token calculator.
Should I paste a screenshot or describe the bug in words?#
Describe it in words first, and only add an image when the bug is genuinely visual — a color that's wrong, a spacing issue, an element out of alignment. Words are cheap, specific, and easy for the agent to act on directly; a screenshot sent with no narration is expensive and ambiguous about which part of the frame you actually care about.
The two aren't rivals — they're complementary. The mistake is defaulting to the image when a sentence would do, or sending an image with no words attached at all.
A quick gut check before you screenshot anything: could you fix this bug yourself from a sentence, without looking at it? If yes, the agent probably can too — send the sentence. If the bug only makes sense once you see it (a shadow that's too heavy, a corner that isn't quite rounded enough), that's when a targeted image earns its cost.
How many screenshots can I paste before I run out of usage?#
Four full-page 1080p screenshots already cost 10,764 tokens, with zero narration attached. On a capped plan, three or four screenshots per check-in, several times a day, adds up fast against a five-hour or weekly usage window.
Worse, you do not pay only once. Anthropic's Claude Code cost guidance makes the mechanism explicit: Claude Code sends your full conversation with every request, so anything already in the session is paid for again on the next turn.
The table below compares that habit against the cheaper alternatives, using only measured or calculated figures:
| Workflow | What it includes | Token cost | Type |
|---|---|---|---|
| Screenshot pile | 4 full 1080p screenshots, no narration | 10,764 tokens | calculated |
| Raw narrated transcript only | ~15-second spoken walkthrough, no bundling | ~150 tokens | measured |
| Full review bundle | Transcript + pointed frames + written summary | ~3,500 tokens | measured |
| 30s screen recording frame-dumped at 1fps | 30 full screenshots, no narration | 80,730 tokens | calculated |
Even the modest four-screenshot habit costs more than three times a complete review bundle — and unlike the bundle, it arrives with none of the "why this matters" context a reviewer would normally say out loud.
Does pointing at something help the agent more than describing it?#
Yes. Pointing — a cursor dwell, a circled region — turns a vague "the button looks off" into something anchored to an exact location, which removes the guesswork an agent otherwise has to do when a prose description could plausibly match two or three elements on screen. It's the difference between "somewhere in this feature" and "right here."
Describing without pointing still works for simple bugs, but for anything with more than one plausible target on screen, pointing resolves the ambiguity in a way adjectives can't.
Think of it as the difference between a bug ticket that says "the header is broken" and one that says "the header, right here, is broken." Both are valid English sentences; only one saves the agent a guessing pass before it can start fixing anything.
What is a review bundle?#
A review bundle is a compact package — a spoken-narration transcript plus a small number of frames captured only at the moments you pointed at something, plus a short written summary — assembled into one document the agent can read in seconds. It replaces a raw screen recording (which most agents can't open anyway) or a loose pile of screenshots as the actual artifact you hand over.
A complete bundle measures about 3,500 tokens — transcript, frames and summary together — against 80,730 tokens (calculated) for the same 30 seconds frame-dumped at one frame per second with no narration at all. The idea is not unique to any one tool; it is a workflow pattern. For what a bundle contains file by file, see what is inside a REVIEW.md bundle; for the full token-cost breakdown, see what a screenshot costs an AI coding agent and the visual context token cost research.
What's a concrete step-by-step workflow for cheaper visual feedback?#
Here's the practical version, whether or not you're using a tool built specifically for it:
- Narrate what's wrong out loud instead of typing a paragraph — say it the way you'd explain it to a teammate looking over your shoulder.
- Point at or circle the exact spot on screen as you talk, so the reference is unambiguous rather than described in prose.
- Capture a frame only at the moment you're pointing, not a screenshot of the whole session or every state along the way.
- Let the transcript carry the reasoning. Images should carry only what genuinely needs pixels — color, alignment, spacing — nothing the words already covered.
- Bundle it before you send it. A short transcript plus two or three targeted frames beats either a wall of screenshots or an unstructured video dump.
- Skip the video for the handoff. Most coding agents can't decode a raw screen recording anyway, so recording is scaffolding — the bundle is the actual deliverable.
You can run all six steps by hand — record a Loom, transcribe it yourself, crop your own frames, write your own summary. It's slower, but the economics hold regardless of tooling: narration is cheap, pointing removes ambiguity, and full-page screenshots are the most expensive way to say the least.
Tools exist that automate this end to end. Walkie, for instance, records your screen and voice while you point at what is wrong, then hands your coding agent a bundle built from exactly that — about 3,500 tokens measured, instead of a video it cannot open or a pile of screenshots that costs more and says less. It is one implementation of the workflow above, not the only way to run it. Clipy turns a recording into markdown with a transcript, frames and click coordinates, free for your first 15 recordings and $9 a month after; Cobalt Capture pairs screenshots with dictated notes and is free today. The full priced field is in tools for giving AI coding agents feedback, compared.
Does this only matter on a capped usage plan?#
It matters most on a capped plan, where tokens spent on redundant pixels are tokens not available for the actual fix — but the workflow pays off even on usage-based billing, since fewer tokens per review means a lower bill per review, and a bundle that states the reasoning clearly tends to produce a correct fix on the first pass instead of a second round of screenshots.
Either way, the math doesn't change: a spoken sentence costs a handful of tokens, a full screenshot costs thousands, and that gap is the whole argument for narrating and pointing before you ever reach for a screenshot. Screenshots aren't wrong to use — they're wrong to use as the default.
None of this requires new software to start practicing. The next time you're about to paste a screenshot into a review, try saying the bug out loud first and typing that instead — you'll usually find the sentence was enough on its own, and the screenshot would only have confirmed what you'd already said.
