Your search API isn't what's expensive. Your tokens are.
The Linkup Team
When teams evaluate retrieval APIs at scale, the first question is almost always price per call. It's the wrong question - and it leads to the wrong architecture. The finding, up front: the cost of web search in a production AI system isn't the API call. It's what the results do to your token bill downstream. A retrieval layer that looks cheap per call but forces extra fetches, re-searches, and bloated context is the expensive option. The right unit of comparison is cost per resolved query.
The naive comparison
Here's the worry, stated plainly. If you're running high query volumes, a system that returns 400-word content snippets per result looks significantly more expensive than a search tool that returns titles and URLs. More tokens in, more tokens billed, more rate-limit pressure.
That's true in isolation. But the comparison isn't native search vs. Linkup search. Nobody runs native search alone in a production pipeline - not if the output has to be trusted.
What a production pipeline actually requires
A title and a URL are not something a model can reason over. To produce an answer that's auditable - where a fact can be traced to a source sentence - the pipeline has to fetch the pages. Search, then fetch, then verify.
So the real comparison is native search plus manual fetches vs. Linkup search directly.
Run the arithmetic on the first option: an initial search, then 5 to 8 sequential fetch calls to retrieve and verify the sources. That's 7,000 to 12,000 tokens of fetched page content - full pages, navigation chrome and all - plus the latency of chained calls, plus the parsing overhead on every page.
Now the second option. Linkup's depth: standard runs around 3,000 to 8,000 tokens and returns extracted content inline - the relevant page text, already pulled, per result. depth: deep runs 15,000 to 50,000 tokens and does the full search-plus-fetch loop in a single call. For most queries, standard is enough, and the token cost is comparable to the search-and-verify pattern - without the sequential latency and without the parsing.
The cost objection only holds against a comparison no production team should be making: a verbose retrieval layer vs. an unauditable one. Compare like for like - auditable vs. auditable - and the gap disappears.
Where the real waste is: iterations
Token-per-call is the visible cost. The invisible one is iteration count.
When retrieval quality is poor, the agent doesn't fail cleanly - it tries again. Another search with a reworded query. Another round of fetches. A retry after a rate-limit error. Each loop multiplies the token cost of the query, and none of it shows up in a per-call price comparison.
This compounds in a second way: rate limits. Most teams hit their model provider's token-per-minute ceiling long before any search API quota. Every unnecessary fetch and every redundant iteration burns TPM budget that the rest of the system needs. At scale, verbose or low-quality retrieval doesn't just cost money - it caps your throughput.
The frugality equation is: fewer iterations means fewer tokens, means less rate-limit pressure. And iteration count is a function of result quality, not result size.
Right-sized context
The other lever is what each result contains. Full page dumps are the wrong default - most of a fetched page is navigation, boilerplate, and content irrelevant to the query. Dynamic snippets that return just the level of context needed to answer keep per-result cost bounded without losing the source text that makes verification possible.
Two controls matter here in practice:
- maxResults caps how many results come back per query - a direct budget lever per call.
- depth matches retrieval effort to query difficulty - standard for most queries, deep only when the answer is genuinely buried.
The honest boundary
Where does this argument not hold? If you're comparing Linkup deep against native search alone, on simple queries, for a use case where nobody will ever audit the output - native is cheaper. That's a real category: quick directional lookups, internal tools where approximate is fine.
But the moment a decision gets made on the output - a trade, a compliance check, a due diligence memo - the pipeline has to verify, and verification has a token cost wherever it happens. You either pay it in one call or in eight.
The test to apply
Don't benchmark retrieval APIs on price per call. Benchmark them on cost per resolved query: total tokens consumed. search, fetches, retries, re-searches - to get from question to verified answer. Run ten of your real queries through each candidate, count everything, divide.
If a retrieval layer looks cheap per call and expensive per resolved query, you've found where your AI infra budget is actually going.
