Updated July 2026. If you've ever pasted three or four screenshots into a chat with your coding agent just to show it a layout bug, you've probably wondered whether that habit is quietly eating your usage. It is — and the fix isn't fewer screenshots, it's a different workflow: narrate, point, and only spend pixels on what actually needs them.
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 runs about 150 tokens (measured, range 100–200), against 2,691 tokens (calculated) for a single full 1080p screenshot. That's roughly an 18x gap for the same information — your voice describing what's wrong, versus a static image the agent has to interpret cold.
The reason is structural, not incidental: text is nearly free to send an LLM, while images are billed by pixel count regardless of how little visual detail actually matters to the fix. (Source: Anthropic, 2026) Anthropic's published high-resolution image-token formula prices an image by its width times height, which is exactly why a full screen capture costs so much more than the bug it's illustrating.
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 (calculated) — and that's with zero narration attached, just the raw pixels. On a capped plan, a habit of three or four screenshots per check-in, repeated several times a day across a real review cycle, adds up fast against a weekly or five-hour usage window, often before the actual coding work has burned a token.
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 runs about 3,500 tokens (measured) — transcript, frames, and summary together — against 80,730 tokens (calculated) for the same 30 seconds of screen time frame-dumped at one frame per second with no narration at all. The idea isn't unique to any one tool; it's a workflow pattern. For what a bundle actually contains file by file, see what a review bundle actually contains, and for the full token-cost breakdown behind these numbers, see the full cost breakdown.
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's wrong, then hands your coding agent a bundle built from exactly that — around 3,500 tokens (measured) instead of a video it can't open or a pile of screenshots that costs more and says less. It's one implementation of the workflow above, not the only way to run it — Clipy and Cobalt Capture take a similar narrated-recording-to-markdown approach, and a fully manual version works too if you're willing to assemble it yourself each time.
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.