Four approaches exist for showing Claude Code your screen: raw video, frame extraction from that video, plain screenshots, and narrated bundles that pair a spoken walkthrough with selected frames. None of them is free of tradeoffs. The real comparison isn't which is fastest to capture. It's what each one costs in tokens, and what each one loses on the way into the agent's context.
Updated August 2026: the numbers below come from Anthropic's published vision-token formula and from measured figures, not vendor marketing, and every competitor price was re-read on that vendor's own page on 16 August 2026. All four approaches land in the same place — Claude Code's context window — and what arrives there differs enormously, from a transcript of your voice down to pixels the agent has to guess about. This is part of the wider picture of the vibe coding workflow, and of visual feedback for AI coding agents generally, where the look-and-react half of the loop gets almost no tooling compared to generation.
| Metric | Tokens |
|---|---|
| Frame-dumping one 30-second review | 80,730 (calculated) |
| The same review as a narrated bundle | ~3,500 (measured, typical) |
| Reduction, bundle vs. frame-dump | 23× fewer tokens |
Here's the same comparison as a table, cost against what gets lost:
| Approach | Cost (30-second review) | What it loses |
|---|---|---|
| Raw video | Not directly readable (the agent can't open the file) | Everything, until something converts it |
| Frame extraction | 80,730 tokens: 30 frames at 2,691, high-resolution tier, 4,784 cap | Your voice, your intent, which frame actually matters |
| Screenshots (cropped, a few) | ~10,764 tokens for four frames, or less | Timing, sequence, the "why" behind the bug |
| Narrated bundle | ~3,500 tokens measured | Almost nothing load-bearing; voice and pointer carry the intent |
Why record at all?#
Screen recording exists because typing a bug report is slow and imprecise. Pointing at broken spacing and saying what's wrong takes seconds; describing the same thing in words, with pixel coordinates, takes paragraphs. Recording clearly helps. The real question is which recorded format actually reaches the agent's context window intact and affordable.
A screen recording captures motion, sequence, and the moment something breaks. Words alone struggle with all three. But a video file, on its own, is a dead end for an agent: it has to become something else before Claude Code can use it, and that conversion is where most of the cost and most of the meaning either survives or doesn't. Text-only bug reports also don't scale well: five paragraphs describing five overlapping issues get harder to parse than a single recording ever would, for either the reader or the agent.
Can Claude Code accept a video?#
No. Claude Code's context is text and images, with no video decoder in the loop. Point it at an .mp4 and it either cannot open the file or an integration silently drops it.
Anthropic's vision documentation lists the supported formats as JPEG, PNG, GIF and WebP, and states that animations are unsupported and only the first frame is used. A raw screen recording never reaches the model as video.
This is the same gap explored in can you feed a Loom video to an AI coding agent: Loom's own AI reads the transcript of your narration, not the pixels. Paste a Loom link into Claude Code and you get answers about what you said, not what's on screen. The video itself, whether it's a Loom recording, a QuickTime capture, or anything else, is scaffolding. The product an agent can actually use is whatever gets extracted from it. In practice this shows up two ways: some integrations throw an explicit unsupported-file-type error, while others silently accept the upload and never reference it again, which is worse, because nothing tells you the review never actually landed.
What about extracting frames?#
Frame extraction turns your video into a stack of screenshots, one per second. It solves the cannot-watch-video problem but inherits the screenshot tax at scale: on the high-resolution tier used by Claude 4.7 and later, which caps any single image at 4,784 visual tokens, every 1080p frame costs 2,691 tokens, so a 30-second review becomes 80,730 tokens before your agent reads a word about what is wrong.
That math is unforgiving. On a 200,000-token context window, 80,730 tokens is close to 40% gone before the fix even starts. A 15-second recording is a modest 6.7 MB on disk, but the frames pulled from it don't shrink to match. Resolution, not duration, drives the per-frame cost. Many of those frames are also redundant: a static screen held for ten seconds still bills for ten separate images, even though nothing on screen changed between them. Clipy is built around exactly this approach: it extracts frames, a transcript and click coordinates into an agent-readable markdown file with its own MCP server, free for your first 15 recordings or 2 hours and $9 a month after. It solves the video-is-unreadable problem. It does not solve the extracted-frames-are-expensive one, because every frame pays the same per-image rate whether or not it shows anything useful. Run your own durations through the token calculator.
What's the cheapest useful format?#
Plain screenshots, cropped to the broken area and pasted with a short caption, are the cheapest useful format for most bugs. Four screenshots covering a page run about 10,764 tokens with zero narration, and for a single obvious visual glitch that's often all an agent needs. This is the free option, and it's genuinely enough a lot of the time.
Tools like Vibeshots, $6.99 once on macOS 14 or later, exist entirely for this workflow: capture, crop, paste, done. There is no shame in that being the right answer. A screenshot loses timing and sequence, and it cannot explain why something is wrong versus showing that it is, but for one clear visual bug a caption fills that gap cheaply enough that a bundle format buys you very little. Vibe Annotations, free and source-available, covers a narrower version of the same job for localhost work in a Chromium browser. The tradeoff shows up the moment a bug needs more than one screenshot to explain itself: stitching a sequence together from stills asks the agent to reconstruct an order of events you already watched happen firsthand.
How does narration change things?#
Narration adds the "why" a screenshot can't carry. A typical spoken walkthrough transcribes to roughly 150 tokens (measured, 100–200 range) and can be paired with a handful of selected frames instead of a full frame-dump. A complete narrated bundle runs about 3,500 tokens measured, carrying voice, pointer intent and a few frames for a fraction of the frame-dump cost.
The gap between a screenshot and a screenshot plus the reason it is wrong is exactly what narration closes. talkthrough-mcp, free and MIT-licensed, proves the idea works: narrated recordings turned into transcript segments, keyframes and OCR text, served to an agent over MCP, at no cost. What separates a paid bundle like Walkie's, $39 once, from a free proof of concept is which frames get selected and how cleanly the transcript and pointer data are packaged. Read what is inside a REVIEW.md bundle for the format itself, and the priced comparison of feedback tools for the rest of the field. That gap compounds across a working day: twenty visual reviews frame-dumped at this rate would burn through a meaningful share of a session's budget before any actual fixing starts.
What setup would you actually run?#
Match the format to the bug. A single obvious visual glitch: one cropped screenshot, free, done in seconds. A multi-step bug, or anything where the "why" matters: a narrated bundle, since transcript plus a few chosen frames beats a full frame-dump on cost and clarity. Reach for raw video only when a human, not the agent, needs to watch it.
In practice, that shakes out to a short decision tree:
- One clear visual glitch: a cropped screenshot with a one-line caption. Free, and it's enough.
- A bug with steps to reproduce, but nothing visual: written repro steps. No image needed at all.
- A multi-step or intermittent visual bug: a narrated bundle, so the agent gets sequence and intent, not just a still.
- Something a teammate needs to see, not the agent: raw video, sent outside the agent's context entirely, the same way you would use Loom or Jam — free, or $14 per creator a month billed yearly on its Team plan — for a bug ticket rather than a build review.
None of these tools is wrong for the job it was built for. Jam is built for browser telemetry and bug tickets, not for handing a coding agent a build review, and that is a fair thing to say about it rather than a knock. The honest answer to "what should I use" is closer to "what does this specific bug actually need" than it is to any single tool being the universal fix. Pick the cheapest format that carries the meaning the fix actually requires, and reserve the expensive ones for when the bug earns it. The number that matters at the end of the day isn't which tool wins in the abstract. It's how many tokens survive to describe the actual problem once the format's own overhead has been paid.
