One of these APIs will sell you a thousand searches for a dollar and another will charge sixteen, and both prices are honest — they are selling different amounts of work. The unit a search API prices in tells you exactly where along the retrieval pipeline it stops reading, and every stage it leaves undone your agent pays for anyway, in fetch failures, latency and tokens. Price the turn, not the call, and the cheapest API on the rate card turns out to be the most expensive one you can pick.
At a glance
Four APIs that agent builders actually reach for, with the list prices published as of August 2026. Read the third column first — it is the one that decides your bill.
| API | Base list price | What one unit includes | Where it stops |
|---|---|---|---|
| Brave Search API | $5 per 1,000 calls, flat across web-search endpoints | Ranked results from Brave's own index; the separate LLM Context endpoint returns extracted "smart chunks" at the same list price | Snippets — or full extraction, if you call the other endpoint |
| Exa | $7 per 1,000 searches (≤10 results) | Neural and keyword retrieval with page contents for the first ten results bundled in since the March 2026 pricing change; $1 per 1,000 for each result past the tenth | Extracted text, in the base call |
| Tavily | Credits — $0.008 each pay-as-you-go, $0.005 in volume | A basic search costs 1 credit and returns snippets; an advanced search costs 2 and fetches the pages to extract clean text |
Wherever you set search_depth |
| Parallel | $0.001 per basic request for ten results, plus $0.001 per additional result and excerpt | Results with excerpts; the separate Task API runs a whole research job from $300 per 1,000 runs | Excerpts — the research loop is a different product |
Two more numbers frame the field. An independent August 2026 benchmark of eight agentic search APIs put Brave narrowly at the top on answer quality, with Exa, Firecrawl and Parallel's Pro tier close enough that the gaps could be noise, and Brave about a point clear of Tavily. The same benchmark measured a 20× spread in latency, from roughly 670 ms at the fast end to 13.6 seconds at the slow one. Hold that second number; it does more damage than the first one does good.
Four price units, four different products
A price unit is a design document. It tells you what the vendor thinks it is selling, and by omission, what it expects you to build.
Brave: a flat call, and a second endpoint that changes the whole calculation
Brave prices like a search engine because it is one — its own crawl and index, a flat $5 per thousand calls, no per-result arithmetic. That flatness is worth more than it looks: it is the only one of the four where you can predict next month's bill from this month's request count without a spreadsheet. The February 2026 removal of the free tier, replaced by $5 in monthly credits, annoyed a lot of hobby projects and changed nothing structural.
The interesting part is the LLM Context endpoint, which runs the query, opens the top-ranked pages, and returns cleaned chunks — text, JSON-LD structured data, code blocks, forum threads, video captions — at the same $5 per thousand. Two products, one price, on opposite sides of the line that matters. Most write-ups treat Brave as the cheap snippets option; that is only true of the endpoint people happen to have wired up first.
Exa: contents are the product, and the base call already includes them
Exa prices per search and folds the page contents for the first ten results into the $7. Before March 2026 contents billed separately, and the change is more than a discount — it moved Exa's default from "a search API you then read from" to "a retrieval API that hands you text". Past ten results you pay $1 per thousand for each extra, so cost tracks how wide you cast rather than how many queries you issue, which is the right shape for an agent that would rather run one broad search than five narrow ones.
Above that sit Deep Search at $12 and deep-reasoning search at $15 per thousand, an Answer endpoint at $5, and Monitors at $15 for standing queries. The tiering is honest about what it costs to do more reading, and it is also the reason a naive cost model built on "the search endpoint is $7" underestimates a system that quietly calls Answer in a loop.
Tavily: credits, because the unit of work genuinely varies
Tavily is the one that prices the depth switch explicitly. A basic search is 1 credit; an advanced search is 2, and the second credit buys the fetch-and-extract pass — the API opens the pages and returns clean text instead of snippets. At $0.008 per credit pay-as-you-go that is $8 and $16 per thousand respectively, falling toward $0.005 on volume plans, with a free tier of 1,000 credits a month and paid plans starting at $30 for 4,000.
The credit model is honest and it is also the least predictable of the four, because a single Research call can consume anywhere from 4 to 250 credits depending on how far it goes. That is fine when a human triggers it. It is a different proposition inside an autonomous loop, where the thing deciding how deep to go is the same thing spending the money — the general form of that hazard is in cost attribution and budgets.
Parallel: per result and excerpt, with the research loop sold separately
Parallel's search pricing is a formula rather than a number: $0.001 for a basic request returning ten results, plus $0.001 for each additional result and excerpt, with an advanced mode starting at $0.005. On the smallest configuration that is $1 per thousand requests, the cheapest headline in this comparison by a factor of five.
The formula is the tell. Parallel is charging for how much text it hands you, which means it has thought about the thing this whole post is about — and it has also unbundled the expensive half into the Task API, where a deep-research run starts at $300 per thousand and climbs to $2,400 for the heaviest tier. Those two products sit on either side of the same line, priced 300× apart, which is a fairly precise statement about how much of the work was in the search call.
Price the turn, not the call
Here is the arithmetic that reorders the field. Take one ordinary research turn: the agent issues three searches and ends up reading twelve pages. Assume a raw page runs about 4,000 tokens once the HTML is stripped, an extracted chunk about 1,000, and an input price of $3 per million tokens.
Links-only search costs about 1.5 cents in API charges for those three calls — and then the agent fetches twelve pages itself and puts roughly 48,000 tokens through the model, which is 14.4 cents. The API is 9% of the turn. Every endpoint that hands back extracted text instead lands the turn between 5 and 8.5 cents, because 12,000 tokens of chunks cost 3.6 cents and no amount of API pricing difference catches up with a 10× swing in what you feed the model.
Sort by rate card and you get Parallel, Brave, Exa, Tavily. Sort by cost of a completed turn and you get Brave's LLM Context endpoint, Exa, Parallel, Tavily — with Brave's links-only endpoint dead last at nearly three times the cheapest. The vendor at the top of the second list is also the vendor at the bottom, at the same list price, one endpoint apart. Whatever else you take from this comparison, take that: the endpoint choice matters more than the vendor choice, and it is the one people make by accident.
Three things the chart deliberately leaves out, all of which push the same direction:
- Fetch failures. When your agent does the fetching, some fraction of pages return a bot wall, a paywall, a cookie interstitial or a JavaScript shell. Those cost a request, a timeout's worth of latency, and often a retry, and they produce nothing. A vendor doing the fetching absorbs that failure rate into its price.
- The second pass. Raw page text usually cannot go straight into the answer; agents summarise or re-rank it, which is another model call on the expensive side of the token split.
- Context displacement. Forty-eight thousand tokens of page text is not just a charge, it is occupancy — it crowds the instructions and prior steps that the agent still needs, and long contexts degrade attention well before they hit the advertised limit. That is the argument in effective versus advertised context, and it makes the token column a quality cost as well as a money one.
What you buy back when you let the API read
If the analysis stopped there it would be an advert for extraction endpoints. It should not, because handing the reading to the vendor hands over something else with it.
Chunk selection is a relevance judgement you can no longer see
When an API returns "the relevant parts of the page", something decided what was relevant. You cannot inspect that decision, cannot A/B it against an alternative, and cannot tell the difference between a page that did not contain the answer and a page whose extractor dropped the table the answer was in. Your agent's most common failure — confidently answering from partial evidence — now has a cause that lives on someone else's infrastructure. If you are running a serious evaluation of your retrieval quality, and evaluating RAG argues you should, you are now evaluating a component you cannot change.
It changes under you without a deploy
An extractor is a model or a heuristic, and vendors improve both continuously. That is a silent input change to your system: same code, same prompt, different text arriving, different answers going out. Nothing in your CI catches it, because your CI runs your code. This is exactly the drift problem in third-party tool drift, and search APIs are its purest instance — the interface is stable while the content behind it moves.
Index coverage is not interchangeable, and "no results" is ambiguous
Brave answers from its own crawl; Exa runs a neural index alongside keyword matching; the others blend sources. A neural index returning nothing means "nothing was semantically close", which is a different claim from a keyword index's "no document contained these terms", and an agent that treats either as ground truth about the world will confidently tell a user something does not exist. Whatever you pick, the loop should be able to reformulate and retry against a different modality before it concludes anything — see agentic retrieval.
Latency compounds, and it compounds in the loop
A 20× spread between the fastest and slowest API sounds like a preference until you put it inside a loop. Three sequential searches at 670 ms is two seconds the user barely registers. Three at 13.6 seconds is forty seconds of an agent appearing to have hung, and if the loop then re-queries after reading, it is a minute and a half. Search latency is not one number in your trace; it is one number multiplied by however many times the agent decided to look again — which is the whole point of measuring agent latency on the trajectory rather than the call.
When to pick which
| If your agent… | Pick | Because |
|---|---|---|
| Answers a user in real time, one or two lookups per turn | Brave, LLM Context endpoint | Fastest measured, flat pricing, and extraction included at the same rate as snippets |
| Runs broad research turns, many results per query | Exa | Contents bundled for the first ten and $1 per thousand after, so casting wide is the cheap direction |
| Needs domain filtering and a depth switch you control per call | Tavily | The search_depth parameter is the price lever, and it is yours to set per query |
| Wants excerpt-level control and a separate deep-research job | Parallel | Pay per result and excerpt for the fast path; hand genuinely long jobs to the Task API and price them as jobs |
| Is still deciding | Two of them, behind one interface | The switching cost is a day and the failure modes are per-target; nothing else will tell you which index covers your domain |
The durable principle: a search API's price is a boundary marker, not a cost. It tells you which stages of retrieval the vendor performs, and your bill is the vendor's price plus the price of everything past that marker — which is denominated in tokens, latency and failed fetches rather than dollars per thousand. Before you compare rate cards, instrument one real turn end to end and write down where the tokens actually went. Most teams discover the search line is under a tenth of the number they were optimising.
FAQ
Is the cheapest search API always the wrong choice?
No — it is the wrong choice when your agent then has to fetch and read the pages itself, which is the common case. If you already run a crawler and an extraction pipeline you trust, buying links only is exactly right, and the flat-rate options become the sensible pick. The mistake is comparing rate cards without checking which side of the fetch-and-extract boundary you are standing on.
Should I use the vendor's answer or deep-research endpoint instead of my own loop?
For a one-shot question with no follow-up, often yes; it is cheaper than building the loop and the vendor has tuned it. For anything where the agent needs to decide what to look for next based on what it just read, no — you are paying for a research loop you then have to interleave with your own reasoning, and the two loops do not compose. Note the pricing tells you this too: Parallel's Task API is roughly 300× its search call, which is a statement about how much of the work was never in the search.
How do I evaluate these against each other honestly?
Not on a public benchmark — on your queries. Take fifty real questions from your traffic, run each API, and score the agent's final answer rather than the search results, because result quality is only interesting through the thing that consumes it. Then compare total cost and p90 latency per completed turn. That is a day of work and it is the only comparison that transfers.
Does a search API protect me from prompt injection in the pages it returns?
No, and extraction can make it worse by stripping the visual cues a human would have noticed. Text that arrives from a search API is untrusted content that your agent is about to read as if it were instructions — the defences are the ones in prompt injection and ambient authority, and none of them are things a vendor sells you.
What about running search through MCP instead of the HTTP API?
Most of these ship an MCP server, and it changes the integration surface, not the economics — the same call is made, at the same price, with the same amount of text landing in your context. The one thing worth checking is whether the MCP wrapper's default parameters match the ones you would have chosen, because a default of ten full-content results is a token decision made for you.
Further reading
On this wiki:
- Agentic retrieval — the loop that decides what to search for next.
- Evaluating RAG — scoring a retrieval layer, including one you do not own.
- Effective vs advertised context — why the token column is a quality cost.
- Cost attribution & budgets — tagging spend when the agent decides how much to spend.
- Third-party tool drift — what happens when the extractor improves.