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. All four approaches eventually land in the same place, Claude Code's context window, and what actually arrives there differs enormously: from a transcript of your voice down to nothing but pixels the agent has to guess about. That gap is also the difference between a review your agent can act on today and one it simply can't open. This is part of the wider picture of the vibe coding workflow, 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 × 2,691, Claude 4.7+) | 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. It has no video decoder in the loop. Point it at an .mp4 and it either can't open the file or an integration silently drops it. Anthropic's vision support covers static images, not video streams, so a raw screen recording never reaches the model as video at all (Source: Anthropic, 2026).
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 "can't watch video" problem, but inherits the screenshot tax at scale: on Claude 4.7 and later, every frame costs roughly 2,691 tokens, so a 30-second review becomes about 80,730 tokens before your agent reads a word about what's actually wrong (calculated from Anthropic's formula).
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 ($9/month) is built around exactly this approach: it extracts frames, a transcript and click coordinates into an agent-readable file with its own MCP server. It solves the "video is unreadable" problem. It doesn't solve the "extracted frames are expensive" one, because every frame still pays the same per-image rate whether or not it shows anything useful.
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) exist entirely for this workflow: capture, crop, paste, done. There's no shame in that being the right answer. A screenshot loses timing and sequence, and it can't explain why something is wrong versus just showing that it is, but for one clear visual bug, a caption fills that gap cheaply enough that adding narration or a bundle format buys you very little. Vibe Annotations (free) covers a narrower version of this same job for localhost work in the 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 "here's a screenshot" and "here's a screenshot, and here's why it's wrong" is exactly what narration closes. talkthrough-mcp (free, open source) proves the idea works: narrated recordings turned into agent-readable data, no cost attached. What separates a bundle like Walkie's ($39, one-time) from a free proof of concept is which frames get selected and how cleanly the transcript and pointer data are packaged. Read more on what a REVIEW.md bundle actually contains if you want the format spelled out. 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'd use Loom or Jam.dev (free tier; $14/user/month for teams) for a bug ticket rather than a build review.
None of these tools are wrong for the job they're built for. Jam.dev is built for browser telemetry and bug tickets, not for handing a coding agent a build review, and that's 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.