The Cost of Browser Agents Reading Screens: The Token Bill for opencli vs claude-in-chrome

An Overlooked Cost: How Expensive Is It to Let AI "See" Web Pages?

When we ask Claude Code to do clickops for us — reading dashboards, checking settings, pulling a number from a web app — we typically choose between two paths: claude-in-chrome drives Chrome and returns screenshots, or opencli drives the same logged-in Chrome but returns plain text.

The question is: how big is the Token consumption gap between these two approaches? A developer on Dev.to shared a set of measurements based on real API counts, covering over 7,500 browser tool calls, and the conclusions are quite clear-cut.

Screenshot Calls Account for Nearly Half the Tokens

The measurement method involved iterating through real Claude Code session logs and taking the API-reported token count difference before and after each call. This is not a character-count-based estimate — it's real API counts.

The results:

claude-in-chrome call type	Share of calls	Median Tokens per call
Returns screenshot	23%	1,855
Returns text only	77%	373

A screenshot call consumes roughly 5 times the Tokens of a text call. More critically, screenshot calls — which account for only 23% of calls — contribute 49% of claude-in-chrome's total Token consumption.

opencli's median Tokens per call is 397, essentially on par with claude-in-chrome's text calls. The gap between the two tools comes entirely from screenshots, not from text extraction itself.

The tiered pricing of Tokens and multimodal input

Understanding this data requires understanding how large models process images. When Claude receives a screenshot, the image is not fed directly into the model as pixels; it is first divided by a vision encoder into patches, each converted into a set of visual Tokens, which are then concatenated with text Tokens into the same context window. A 1920×1080 web page screenshot typically produces 1,000 to 1,600 visual Tokens, depending on the model's resolution-splitting strategy. This is the fundamental reason why the median for screenshot calls (1,855 Tokens) is far higher than for pure text calls (373 Tokens) — web text after HTML→Markdown extraction is often just a few hundred words, while the same page's visual information balloons several times over. Additionally, most APIs bill image input at Token-equivalent rates; visual Tokens and text Tokens draw from the same budget, so screenshots not only eat into context length but directly drive up per-call costs.

The Real Gap Between the Two Tools on the Same Set of Websites

On 9 websites with at least 10 calls each, the developer compared the median Tokens per call for the two tools:

Website	claude-in-chrome	opencli	Change
telegram.org	1,879	275	−85%
github.com	580	336	−42%
cloudflare.com	578	378	−35%
google.com	605	437	−28%
linkedin.com	736	594	−19%
youtube.com	542	470	−13%
lokerdollar.com	432	386	−11%
nvidia.com	363	384	+6%
bing.com	270	353	+31%

opencli wins on 7 of the 9 websites, and weighted by call volume, reduces Token consumption by about 27% per call on average. The scenarios with the biggest advantage are logged-in web apps like Telegram Web, GitHub, and Cloudflare dashboards — these pages are complex, screenshots have low information density, and the value of text extraction becomes clear.

But not all scenarios favor opencli. On simple public pages, the two tools perform similarly or even identically; on Bing, opencli actually used 31% more Tokens. Both the nvidia.com and bing.com rows have sample sizes under 30 calls, so those conclusions are for reference only.

Practical Rules: Text First, Screenshots Later

Based on this data, the developer established three rules for their team's clickops:

1. When an API or curl is available, prefer the API
2. Use opencli to read pages as text
3. Only take screenshots when visual elements need to be inspected

The logic behind this prioritization is clear: API calls have the highest Token efficiency, text extraction comes next, and screenshots are the most expensive fallback. Limiting screenshots to scenarios that genuinely require visual judgment — such as checking layout misalignment, confirming chart rendering, or verifying UI state — can significantly reduce the Token overhead of everyday browser automation.

A general principle beyond clickops

This "API → text → screenshot" priority isn't limited to clickops scenarios; it's a general trade-off in Agent tool design as a whole. The observation result returned by any tool call permanently resides in the conversation context as Tokens and is re-read and billed in every subsequent round. So the more verbose a tool's output, the higher its marginal cost — not just that this one call is expensive, but that every subsequent round of reasoning pays for it. This is exactly the problem with screenshots: a single screenshot may be repeatedly "viewed" by the model across multiple rounds, whereas text-extracted content is short and can be compressed by subsequent summaries. Common engineering countermeasures include: having the browser tool perform a summary before returning, or returning only the fragments relevant to the current task; replacing actual screenshots with visual descriptions when screenshots are truly needed; and periodically cleaning up or collapsing historical observations in multi-round tasks to avoid unbounded context growth.

What Are the Limitations of This Measurement

The developer proactively disclosed the boundaries of the method, and these limitations are worth noting:

Tasks are not perfectly equivalent. The website comparison matches calls by the same website, not running the same task through both tools, so this is field measurement rather than a laboratory A/B test.

Screenshot results linger in context. After a screenshot is returned, it stays in the context and is re-read in subsequent rounds. Since the two tools have different session lengths, this portion of the cost is excluded, meaning the actual cost of screenshots may be even higher than the data shows.

Sample bias. Some websites have low call volumes, with individual rows under 30 calls, so statistical significance is limited.

Despite these limitations, the core conclusion — "the Token cost of screenshots is far higher than that of text" — still holds under a large sample of 7,500+ real calls. For anyone heavily using browser automation in Agent workflows, this data provides a clear optimization direction: read text when you can, and avoid screenshots.

Background Notes

Why web text extraction can be so lean

Tools like opencli can push a single call under 400 Tokens mainly because they heavily prune the DOM. Raw HTML pages often contain hundreds of thousands of characters of tags, inline styles, scripts, and comments; feeding them directly to the model is both expensive and prone to interfering with reasoning. The mainstream approach is to first convert the page into an accessibility tree or semantic Markdown, discard styles and decorative nodes, and retain only semantically meaningful elements such as headings, body text, links, and form controls. Take a GitHub repository page as an example: the full HTML may exceed 200KB, but the extracted structured text is usually only 2 to 5KB, equivalent to a few hundred Tokens. This compression ratio is the core advantage of the text path, and it's why it can still keep overhead low on heavily frontend-driven apps like Telegram Web and Cloudflare dashboards. But pruning has a cost: once a page relies on Canvas rendering, dynamic charts, or purely visual states (such as a disabled, grayed-out button), text extraction loses information, and only then is falling back to screenshots necessary.

One-line Summary

7,500+ real calls show screenshot calls cost about 5x the Tokens of text; prioritizing text can save roughly 27% overhead.

Paragraph Summary

Based on real API counts from over 7,500 browser tool calls, the article compares the Token consumption of claude-in-chrome (returns screenshots) and opencli (returns text). Results show screenshot calls have a median consumption of 1,855 Tokens, about 5x that of text calls (373 Tokens); screenshot calls account for only 23% of calls yet contribute 49% of total Token consumption. opencli's median per call is 397 Tokens, on par with the text path, with the gap between the two coming entirely from screenshots. Across 9 website comparisons, opencli wins on 7, saving about 27% on average weighted by call volume, and up to 85% on logged-in apps like Telegram Web. The author therefore proposes an "API → text → screenshot" priority and proactively discloses limitations such as the lack of strict A/B testing, lingering screenshot context, and sample bias.