Last week I ran a same-task test of two browser tools for Claude Code: opencli cost 62% less than claude-in-chrome across five read-only tasks. I left one gap open: pages where the data lives in a chart.
A reader asked the question that shaped this test: will the tool get the image, or the data behind it?
Setup
Same runner as before. Each run is a fresh headless Claude Code session (claude -p, Sonnet, max 40 turns) allowed exactly one browser tool. Arm order alternates per rep. Cost and tokens come from the billed usage the API reported, not estimates.
Two tasks, three runs per tool, 12 runs in total:
- pageviews: the Wikimedia pageviews tool, article "Prompt engineering", September 2026. Find the peak day and its view count. The chart is a canvas, and its aria-label lists only the first 10 days. Truth from the Wikimedia REST API: 23 September, 736 views.
- owid: Our World in Data, life expectancy in Indonesia. Report 2000 and 2020. The chart is SVG, with a Table tab. Truth from the OWID CSV: 66.3 (2000) and 68.8 (2020).
Results
All 12 answers were correct.
| claude-in-chrome | opencli | |
|---|---|---|
| Billed cost, 6 runs | $1.14 | $0.63 |
| Tokens, 6 runs | 1.93M | 1.06M |
| Median turns | 11.5 | 5.5 |
| Median seconds | 56 | 29 |
That is 45% less cost and 45% fewer tokens for opencli. Per task:
| Task | Cost, cic → opencli | Tokens, cic → opencli | Turns per run, cic / opencli |
|---|---|---|---|
| pageviews | $0.59 → $0.32 (−46%) | 0.98M → 0.65M (−34%) | 11, 11, 11 / 8, 6, 7 |
| owid | $0.55 → $0.31 (−44%) | 0.95M → 0.41M (−56%) | 14, 12, 12 / 4, 5, 4 |
What each tool did
This is the part that matters more than the totals.
claude-in-chrome read the chart. It hovered over points and read values off the tooltips, one point at a time. On the pageviews chart that means walking the line to find the peak.
opencli never read the chart. In every one of its six runs it went to the data behind it. On pageviews it called the Wikimedia API from inside the page. On OWID it pulled the CSV export.
Neither tool was given the image to look at. The question "image or data?" was answered by the agent itself, and the answer depended on what the tool made easy. A tool that hands the model text and a fetch makes the data path the cheap one. A tool built around screenshots and pointer events makes hovering the obvious move.
Why turns drive the cost
Every model call re-reads roughly 30k tokens of base context in both arms. So the number of turns is most of the bill. A dozen hovers is a dozen turns. One fetch is one. That is also why the same-task test last week showed the biggest gaps on pages where claude-in-chrome needed many steps.
Caveats
- Small sample. Two tasks, three runs per tool.
- Both sites publish their data. Wikimedia has a public API, OWID has a CSV export. A chart that is only pixels, with no API or export behind it, is the case where reading the image is the only option. That test is next.
- Cache noise. On pageviews, the third run in both arms cost about a tenth of the first two ($0.067 and $0.068), and so did the third claude-in-chrome run on OWID ($0.066). Token counts did not drop, only cost, so this is likely a warm prompt cache from the run before. Totals include these runs as billed.
Takeaway
If you are building a browser agent that pulls numbers off charts, make the data path the easy one. Expose fetch and page text, and the model will skip the pixels when it can. Reading the chart is the fallback, not the plan.
Top comments (0)