Search nomadLab

Best AI Search APIs for Agents 2026: Tavily vs Exa vs Serper

Four different products wear the same label. Which one you need depends on whether you want URLs, passages, or clean text, and the bill is decided by how many pages you fetch, not how many searches you run.

Updated

The first time you wire an agent to the open web you meet the boring truth: the model is the easy part. Finding clean, recent, citation-ready text about whatever the user just asked is where projects stall. Scraping Google yourself is fragile and against the terms. A vector store full of last quarter’s PDFs is no help when someone asks about a feature that shipped this morning. And once the agent starts looping, you are paying a frontier model to read a page of SEO sludge on every turn.

That gap is why this category exists, and why it split into four quite different products that share one label.

Prices below came off the vendor pricing pages on 21 August 2026.

Four products, one label

Four kinds of AI search API: SERP wrappers return links and snippets, LLM-native search returns passages with citations, crawl and extract turns one URL into clean text, and independent indexes return a different set of results entirely SERP WRAPPER Serper, SerpAPI gives you titles, snippets, links LLM-NATIVE SEARCH Tavily, Exa, Linkup gives you passages with citations CRAWL + EXTRACT Firecrawl, Jina gives you one URL as clean markdown OWN INDEX Brave, Kagi gives you different results, cleaner licensing Almost every production stack runs two of these: something to find the URLs, and something else to read them. No single tool is good at both jobs.
Knowing which column you are shopping in saves more money than picking the cheapest vendor inside a column.

Tavily: the default

The closest thing to a default in agent search, and not because of magic. The API does what an agent loop needs and not much else. One query, five to ten passages back with URLs, scores, and optionally the full page content, in a single round trip. A depth parameter trades latency for recall, and there is a deeper research mode that does its own query expansion.

What is good: the response is genuinely LLM-shaped. No SERP parsing, no nav text, no cookie banner in the content blob. Citations come back as structured fields you can hand to a frontend without regex.

What to watch: the pricing is credit-based at $0.008 a credit on pay-as-you-go, with 1,000 credits free to start, and different request types burn different numbers of credits. The pricing page does not spell out the per-operation cost, so read the docs before you model your bill, because a chatty research agent making five calls per user message is where this stops being a rounding error.

If I could only call one search API on a new project, I would start here and optimize down later.

Exa: when the question is fuzzy

Reach for this when keyword search is the wrong frame. It is embedding-based retrieval over its own crawled index, so it is good at “essays that argue X” and “papers that benchmark Y,” the questions where similarity beats token matching. It will also take a URL and find you conceptually adjacent pages, which is a genuinely different primitive from a keyword search.

The catch is the mirror of the strength. A neural index is not trying to be the freshest. Ask what happened at yesterday’s keynote and you can get a thoughtful essay about the company’s strategy rather than yesterday’s coverage. There are keyword fallbacks and date filters now, and it still shines on the conceptual end.

Pricing is refreshingly legible: $7 per 1,000 searches, $1 per 1,000 pages of content retrieval, $20 of credits to start, no subscription.

The pattern that works is Exa as the second search inside a research agent: a fresh pass with something recency-oriented, then Exa to go sideways from the best result into deeper context.

Serper: the boring answer that keeps being right

A thin, fast Google SERP wrapper. No reranking, no extraction, an order of magnitude cheaper per query than anything LLM-native. Cheap enough that you stop thinking about it.

It still wins because Google remains very good at “what is the official documentation page for this product,” and an agent that needs a known canonical URL does not need a neural index to find it. Use it when you are navigating to a known site, when you already have a strong reranker downstream, or when the budget is hobby-shaped.

It is the wrong answer for deep research or anything freshness-sensitive, and it is the wrong answer whenever you actually want a passage in the response, because you will do a second fetch on every result and add the latency and cost back.

SerpAPI lives in the same lane with far more engines behind it, including Amazon and eBay, which matters if you are building a comparison agent.

Firecrawl: the line item nobody budgets

Here is the unglamorous shape of an agent loop: most calls are not searches, they are fetches. The model picks three URLs and now something has to actually read them, through cookie banners and JavaScript rendering and PDFs.

Firecrawl is the cleanest answer I know for that. A scrape endpoint returns clean markdown, a search endpoint stitches discovery and extraction into one call, and a structured extract mode takes a schema and gives back JSON.

The credit model is where the surprise lives, and it is worth reading twice. A scrape is one credit per page. A search is two credits per ten results. Extraction is one credit per page. So search-then-read on five results is the search credits plus five more, and an agent that re-reads the same URL three times in a session because nothing is cached pays three times. A missing cache in front of the fetch layer is the single most common way this bill triples.

Plans run from a free 1,000 credits a month, through Hobby at $16 for 5,000, to Standard at $83 for 100,000, which works out around eighty cents per thousand pages. Growth and Scale go to 500,000 and a million.

Jina: parts, not a product

Jina ships three useful things and does not always sell them as one: Reader turns any URL into clean markdown and has a free endpoint you can hit with no auth at all, plus their own search and a reranker API that is useful as a standalone layer.

The do-it-yourself appeal is real. Reader plus a cheap model for query rewriting plus their reranker gets your cost per query well down. The trade is glue code. Tavily hands you a finished result; Jina hands you parts. One engineer and no time points at Tavily. Tens of millions of queries a month points the other way.

The free Reader endpoint is a gift for prototypes.

Brave and the independent-index case

Brave runs its own index rather than rewrapping someone else’s, with news, web and image endpoints and generous free tiers.

Two reasons to care. The licensing, first: if you are going to display search results inside a product, the rights situation around Google SERP wrappers gets uncomfortable, and Brave is upfront that you can use the data. And the index is genuinely different, which shows on queries Google has buried under content farms.

It has more gaps than Google on long-tail technical content, so treat it as a complementary source rather than a replacement.

The cost math that actually bites

The number that matters is not cost per search. It is cost per user session, and the fetch layer usually dominates it.

Take an agent where an average session triggers five searches and ten page reads. At Exa’s rates the searches are about three and a half cents. At Firecrawl’s Standard tier the reads are about a cent. Swap to an advanced search mode with extraction on every call and the same session can cost several times that, and at ten thousand sessions a day the gap between the careful path and the careless one is a five-figure annual line item.

Three things fix it, none of them exotic. Cache on the URL with a TTL tuned to how stale you can stand. Route navigation queries to the cheap path and save the expensive one for real research turns. And put a reranker in front of the model instead of shoving ten mediocre results into context.

Stacks that survive contact with users

Search then extract: an LLM-native search for discovery, Firecrawl for reading, a cache keyed on the URL in between. Clean separation, easy to swap either half.

Single vendor: one API, one bill, one place to debug. Right while prototyping, or when ops cost matters more than per-query cost.

Neural first: Exa for discovery, Jina Reader for the fetch, your own reranker on top. Right for concept-heavy retrieval rather than fact lookup.

Cheap and cheerful: a SERP wrapper plus an extractor plus a small rerank step. The most setup work and the lowest per-query bill.

The one to avoid is a bare SERP wrapper as your entire search layer. A two-hundred-character snippet is almost never enough for a model to reason on, and you will spend more time chasing hallucinated citations than you would have spent on a real search API.

What to do with your own numbers

Instrument the search calls with timing and a content-length log, then read fifty responses by hand. Not the queries, the responses.

You will find that some fraction returned something the model could use and the rest were paywalls, empty extractions, and SEO sludge. That ratio is the only signal that matters, and no vendor benchmark page will tell you what it is for your traffic. Once you have seen it, the choice between these mostly makes itself.

Keep reading