The easiest way to give an agent the web is curl. It works, and it is a terrible idea. A single Wikipedia article comes back as navigation menus, inline scripts, tracking pixels and markup, with the few paragraphs you wanted buried somewhere in the middle. The agent reads every byte of it, and every byte sits in the context window for the rest of the session.
The industry noticed Link to heading
Dozens of tools now sit between agents and the web. Search APIs, extraction services, fetch endpoints and the built-in tools in the big agent harnesses all promise clean content at a lower token cost.
How they get there differs. Some strip a page down to markdown. Others hand the page to a small model and return an answer. Quality, latency and cost vary a lot between them, and published benchmarks mostly rank them on how good the extraction is.
I wanted to know something narrower: how many tokens does each one cost the agent that has to read the result?
What I measured Link to heading
I loaded the same 12 popular web pages with three methods: Claude’s built-in web tool, Tavily Extract and TinyFish Fetch. Tokens for Claude are what the model actually ingested. For the other two I estimated them from the returned text. Each page was timed once.
| Method | Avg tokens per page | Avg latency |
|---|---|---|
| Claude web tool | ~634 | ~15.1 s |
| TinyFish Fetch | ~13.9k | ~3.6 s |
| Tavily Extract | ~48.4k | ~0.7 s |
Claude came in around 22x leaner than TinyFish and 76x leaner than Tavily. The long pages drive most of that gap. A big Wikipedia article cost Tavily over 130k tokens and Claude under 1.5k.
Why the gap is so big, and why the latency is not a fair fight Link to heading
The extractors return the page, cleaned up. Claude’s tool lets a small model read the page and hands back an answer. Far less comes back because the question only needs a little.
That also explains the time. Claude’s 15 seconds includes the agent turn, the fetch, the summarising and the answer. Tavily’s 0.7 seconds is a page fetch and nothing more, and the agent still has to read 48k tokens afterwards. So treat latency as time to usable content, not a pure speed test.
It is also a small test. One run per page, a fixed reference price, and tiny pages tell a different story. On a bare page like example.com the extractors are just as lean, sometimes leaner.
Give it a question, not just a page Link to heading
The best way to use any of these tools is in two steps. Hand it a URI, or a search, and ask a specific question about what it finds. The extraction happens inside the tool and only the answer lands in your agent’s context.
That two-step pattern is where the lean numbers come from. Claude was asked a question. The extractors were only given a URL. Some extractors can narrow their output with a query too, and that is worth trying, but it is not what I measured.
Where this leaves you Link to heading
Connecting agents to the web is vital, and doing it fast, cheaply and reliably is still changing month to month. The right choice depends on the job. An extractor wins when latency matters most, or when you need the full page text. When tokens are the constraint, ask a question instead.
For developers building their own agent factories, Claude’s web tool is currently the most token efficient option I have tested, and at scale that adds up.
The market is also splitting fast. These players are no longer all selling the same thing, and some are pivoting hard. That is a story for the next article.