Notes ·
What it costs to give an agent web access
The expensive part of giving an agent web access is not the search. It is fetching and reading every page the search returned, when the agent only needed the titles.
Most agent queries are answered by a title and a snippet. “Who is the CEO of X”, “when did Y ship”, “is Z still maintained” — the answer is in the result list, and fetching six full pages to find it is work nobody asked for and everybody pays for.
Four rungs, not two
Search APIs usually give you one dial with two positions: cheap or thorough. That is one position too few at the bottom.
Narrowest. Take the quickest route to an answer and stop. Reach for it when a question is cheap to answer and you are running a lot of them — a retry loop, a disambiguation step, anything where a user is waiting on a first token.
Full breadth, no escalation. Search everything, but do not let a blocked or degraded page be re-fetched through a real browser. Breadth costs almost nothing in wall clock. Driving a browser costs seconds, and this rung buys that time back.
Full breadth with escalation. The default. A page that comes back blocked may be re-asked properly rather than written off.
Read the pages. Everything above, plus every result fetched, stripped to its readable part, and its passages ranked against the question. This is the rung that returns the page rather than the headline, and it is roughly an order of magnitude more in both latency and cost.
The mistake worth avoiding
Reaching for the deepest rung by default, because it sounds the most thorough.
It is more thorough, and for most questions it is more thorough about things nobody asked. You pay for the fetch, you pay for the extraction, and then you pay again when your model reads six full pages instead of six snippets.
Start at the middle. Escalate when the snippet genuinely does not answer the question, which is less often than it feels.
Where the cost actually lands
Three places, in rough order of size:
- Your model reading the result. The largest line by a distance. A raw page is mostly navigation, cookie banners and inline CSS; extracted, it is about a twenty-fourth the size. Whatever you pay per token, you pay it on everything you pass along.
- Fetching the pages. Bandwidth, time, and the tail risk that one page takes eight seconds to say nothing.
- The search itself. Almost always the smallest number on the invoice, which is why optimising it first is a common and expensive mistake.
A useful rule
Price the call before you make it. If a search API cannot tell you what an operation costs before you run it, you cannot reason about the bill until it arrives.
Ours is one credit for a search that returns snippets, two for one that reads the pages, and one per five URLs extracted directly. That is publishable arithmetic: multiply by your monthly volume and you have the number before you write any code. The full price list is on one page, and the depth parameter is one field in the request.
The design goal is not to be the cheapest search on the list. It is that the cheap rung is genuinely useful, so you are not paying for depth you were never going to read.