Every comparison of agent search APIs opens with a pricing table, and every one of those tables says the same thing: five to eight dollars per thousand queries, across the board. That number is not where your money goes. A single Firecrawl result can arrive as eight thousand tokens of page Markdown where a Brave result arrives as a two-hundred-token snippet — and because an agent re-sends its whole transcript on every subsequent step, you pay for that difference again at every turn. Pick on response shape, not on list price.
At a glance
Four products that all answer "search the web" and own four different layers of the stack underneath it.
| Product | What it owns | Default result shape | Rough list price |
|---|---|---|---|
| Brave Search | An independent crawl and index, advertised at 40B+ pages. | Title, URL, short snippet. | ~$5–9 / 1k queries |
| Exa | Its own crawl, indexed by meaning rather than by keyword. | Links; page text or highlights on request. | ~$7 / 1k requests |
| Tavily | A crawler plus aggregated third-party index data, re-ranked. | Condensed sources, optional synthesized answer. | ~$8 / 1k basic searches |
| Firecrawl | A renderer and cleaner; search is the entrance to it. | Full-page Markdown. | Credit-based; ~$83 / 100k credits |
Those prices are list prices at the time of writing and they move — free tiers in particular have been withdrawn on short notice in this market. Treat the column as "all four cost about the same" rather than as a leaderboard.
The question before the question
Before choosing between these, check whether you need any of them. Every frontier model vendor now ships a hosted web-search tool that runs inside the model call — you enable a flag, the model decides when to search, and results are grounded and cited without a line of retrieval code on your side. For a general-purpose assistant answering "what happened this week", that is almost always the right answer, and reaching for a third-party API instead buys you complexity you will maintain forever.
The case for a dedicated search API is narrower and worth stating precisely. You want one when you need to see and shape the results — filter by domain, control recency, cap how much text enters the context, cache aggressively, run the same query across providers, or search from somewhere the built-in tool does not reach. That is a retrieval-engineering problem, and it is the problem the rest of this post is about.
Brave Search — deep dive
What it owns
Brave runs its own crawler and its own index — advertised at over 40 billion pages — and does not resell another engine's results. In a market where several "independent" search APIs are aggregation layers over Bing or Google data, that is the structural fact worth paying for: your retrieval does not disappear when someone else's reseller agreement changes.
What you get back
Web results in the classic shape: title, URL, a snippet of a few dozen words, plus metadata. It is keyword-and-ranking search, tuned for recency and against SEO spam, and it consistently benchmarks at the fast end of the field — sub-second where some competitors take many seconds.
What it makes hard
Everything downstream. If your agent needs the content of a page, you fetch it, render it if it is JavaScript-heavy, strip the navigation, and handle the sites that block you. That is a real engineering surface, and it is exactly the surface Firecrawl exists to sell you.
Exa — deep dive
What it owns
Its own crawl, indexed on meaning rather than on keyword match. The practical consequence is a query mode nothing else here offers: hand Exa a URL and ask for pages like it. For "find me twelve more companies doing what this company does", that is not a better version of keyword search — it is a different operation, and the alternative is a person with forty browser tabs.
What you get back
Links by default; page text or model-extracted highlights on request. Highlights are the interesting middle setting: the relevant passages without the whole document, which is the shape an agent context actually wants.
What it makes hard
Coverage of the ordinary web. Exa's crawl skews to information-dense content — papers, blogs, news, code repositories — which is why it is excellent for research and unreliable for "the opening hours of a specific shop". Asking it a long-tail factual question is asking a specialist index to be a general one.
Tavily — deep dive
What it owns
The layer after retrieval. Tavily runs a crawler but also aggregates third-party index data, then puts a model stage on top that re-ranks, condenses and optionally answers. It is billed in credits — one for a basic search, two for an advanced one — which prices that extra processing honestly rather than hiding it.
What you get back
Content already shaped for an LLM: cleaned, trimmed, citation-friendly, with a synthesized answer available if you want it. This is the fastest of the four to get working, and for a straightforward research agent it removes a week of retrieval plumbing.
What it makes hard
Knowing what you lost. A condensing step is a model deciding what mattered, before your model sees it — so a fact that was on the page can be missing from the result with no signal that it was dropped. When your agent gets an answer wrong, you now have two retrieval stages to debug and you can only instrument one of them.
Firecrawl — deep dive
What it owns
Getting a page into clean Markdown — rendering JavaScript, stripping navigation and cookie banners, handling the awkward sites. Search is a route into that pipeline rather than the point of it, and the pricing reflects the emphasis: a flat credit per page, which at high volume undercuts the per-query APIs substantially.
What you get back
The whole page. That is the feature and it is also the problem: eight thousand tokens of Markdown is wonderful when you need the document and ruinous when you needed one sentence from it.
What it makes hard
Restraint. With Brave you must build extraction; with Firecrawl you must build truncation, and truncation is the easier thing to skip. A search returning five full pages puts tens of thousands of tokens into a transcript that will be re-sent on every subsequent step — see agent cost control for why that compounds rather than adds.
Cross-cutting comparison
Context cost is the axis that actually separates them
Run the arithmetic for a ten-step agent that searches three times. With Brave snippets, retrieval contributes a few thousand tokens to the transcript. With Firecrawl full pages, the same three searches contribute over a hundred thousand — carried forward through every remaining step, at input prices, on top of a search bill that differed by less than a factor of two. The API you chose for being cheap can be the most expensive line in your model bill, and the search invoice will never show it.
The corollary is that these products are complements more often than substitutes. Search wide and cheap, then extract deeply on the two or three results that survived a relevance check. That is the same wide-then-narrow discipline as reranking, applied one layer earlier.
Who actually owns an index
Three of the four have their own crawl; Tavily and Firecrawl both lean on aggregated data for the search step. This matters less for quality than for continuity — an aggregator's coverage and pricing are downstream of contracts you cannot see. If your product's core loop depends on web search, having at least one independent index in the mix is cheap insurance, and Brave and Exa are the two that qualify.
Latency, and the thing benchmarks do not measure
Published comparisons put a 20× spread across this category, from a few hundred milliseconds to well over ten seconds. The fast end is dominated by snippet-returning index APIs and the slow end by anything that renders pages or runs a model over the results — which is not a defect, it is the work you asked for. The number to plan against is not the search API's median but your agent's step latency including it, because a five-second search inside a fifteen-step loop is over a minute of wall clock the user is watching.
When to pick which
| Use case | Pick | Why | Watch out for |
|---|---|---|---|
| General assistant, "what happened this week" | The model's built-in search tool | Grounded and cited with no retrieval code. | You cannot shape or cap the results. |
| High-volume agent loop, tight context budget | Brave | Independent index, snippet-sized results, fast. | You own fetching and extraction. |
| Research agent, find-similar, discovery | Exa | Semantic retrieval and a real find-similar mode. | Thin on the long tail of the ordinary web. |
| Ship a research feature this week | Tavily | Pre-condensed, citation-shaped, least plumbing. | An opaque stage between the page and you. |
| You need the document, not the snippet | Firecrawl | Best-in-class extraction; flat per-page pricing. | Truncation is now mandatory, not optional. |
| Core product loop, cannot lose search | Two of them | One independent index plus one extraction layer. | Two failure modes and two bills to watch. |
FAQ
Do I need a search API at all if my model already has a web search tool?
Usually not. Reach for one when you need to control the results — domain filters, recency windows, a hard cap on tokens returned, caching, or running the same query across providers. If you cannot name which of those you need, use the built-in tool.
Which of these four is fastest?
Snippet-returning index APIs like Brave sit at the fast end, generally under a second, while anything that renders pages or runs a model over the results is slower by design. Compare them on your own queries: latency in this category varies more with query type than with vendor marketing.
Is the $5–8 per thousand queries figure the whole cost?
No, and that is the argument of this post. The larger cost is the tokens each result adds to your model context, which in an agent loop is re-sent on every subsequent step. Measure cost per completed task, not cost per query.
Can I use more than one?
Yes, and for anything load-bearing you probably should. The common pattern is a cheap index API for breadth and a full-page extractor for the handful of results that survive a relevance check — they are complements, not competitors.
What about Perplexity, You.com, SerpAPI or Google's own API?
They fill the same four roles. Perplexity and You.com sit where Tavily does, as answer-and-citation layers; SerpAPI and the various SERP scrapers sit where Brave does but resell another engine's index rather than owning one. Place any new entrant by asking which layer it owns.
Do these work over MCP?
All four ship MCP servers, so wiring one into an MCP-capable agent is configuration rather than code. That makes swapping them cheap enough that you should benchmark on your own queries instead of trusting anyone's leaderboard — including this one.
Further reading
On this wiki:
- What is RAG — the retrieval pattern these APIs plug into.
- Agentic retrieval — letting the agent decide what to search for, and when to stop.
- Hybrid search and reranking — the wide-then-narrow discipline, one layer down.
- Agent cost control — why a fat tool result is charged again on every later step.
- Research agents — the playbook this choice sits inside.