Give an agent a web search tool and it will use it. Often. A research agent that runs eight searches per task looks cheap in a demo and expensive at 100,000 tasks a day. Before that bill arrives, you have to decide how the agent gets web data at all: a search API, a crawl-and-extract service, or infrastructure you run yourself.

These aren’t three versions of the same thing. They answer different questions, and most production systems end up using more than one. This post lays out what each category does, what it costs you, and a simple way to route between them.

Three tools, three different jobs

A July 2026 roundup from Mastra sorts agent web-data platforms into groups that are worth keeping straight.

Search APIs find things. Exa uses semantic, embedding-based search. Tavily returns structured results aimed at retrieval-augmented generation. Linkup returns answers with citations, and Brave runs its own independent index. Mastra notes that these tools generally don’t crawl entire websites.

Crawl and extraction services, with Firecrawl as the example, search, crawl and convert pages into Markdown or structured data in one API. Mastra presents them as the best fit when an agent needs clean page content.

Large-scale scraping infrastructure, such as Bright Data, brings proxy networks, browser automation and datasets. Mastra describes it as aimed at organizations where data acquisition is core to the product, and heavier than a lightweight research assistant needs.

ScrapingBee’s comparison of search APIs adds a fourth label you’ll see in the wild: SERP APIs (Serper.dev, SerpApi, DataForSEO and others) that return structured search-engine results, and scraping APIs that fetch and render full pages and hand you the raw content. Note that ScrapingBee sells a scraping API, so read its framing with that in mind.

The useful takeaway from both: discovery, content and scale are separate problems. Mastra says outright that the approaches are complementary, and that many production systems combine search for discovery, crawling for structured content and scraping infrastructure for scale.

What each option costs you

Pricing models differ more than the headline numbers suggest. ScrapingBee’s list (as published, so check current rates) shows the spread:

Provider Pricing model
Serper.dev $1 per 1,000 searches
Tavily Free up to 1,000 searches/month; paid from $27/month
Brave Search API Free tier; paid from about $5/month
SerpApi From $50/month
ScrapingBee From $19/month for 75k credits
Exa Usage-based, $10 starter credit

Those are entry prices, not what you’ll pay at volume. The number that matters is cost per completed agent task. A quick illustration, using Serper’s listed rate and made-up workload numbers:

searches_per_task = 8 # hypothetical agent behaviour tasks_per_day = 100_000 # hypothetical volume price_per_search = 1 / 1000 # Serper.dev, $1 per 1,000 searches daily_cost = searches_per_task * tasks_per_day * price_per_search print(daily_cost) # 800.0 dollars/day, before you fetch a single page

That’s search alone. Reading the results costs extra, and ScrapingBee’s own advice is that an agent running many searches per task can erode margins quickly. Cap searches per task early, and log how many each task actually uses.

Where the search layer can shift under you

If your agent depends on SERP data, you’re depending on a source that can change without notice. In September 2025, Google stopped honoring the &num=100 parameter, which had returned up to 100 results in one request. AdPushup dates the rollout to September 12 to 14, 2025. Google called the parameter "not an officially supported feature."

The effect on collection was direct. Per Zeo, tools now need up to 10 requests for what one used to return, and tracking beyond the first few pages gets harder. Neither source gives dollar figures, so I won’t either. But the lesson carries over to agents: if an agent’s quality depends on seeing results 11 through 100, a vendor-side change can quietly reshape your cost and your coverage. Write down how deep your agents actually need to look, and test whether they’d do as well at the top 10 or 20.

Choosing: a practical routing rule

Start from what the agent is trying to do, not from the vendor list.

In code, the router is boring, and that’s the point:

def route(task): if task.needs_discovery: return "search_api" # find candidate URLs if task.url_count < 1_000 and not task.needs_custom_logic: return "crawl_api" # clean Markdown or JSON per page return "own_fleet" # volume or control justifies running it

The thresholds above are placeholders. Set yours by measuring cost per correct page on your own targets, not by trusting a vendor’s benchmark. ScrapingBee itself says its benchmark claims aren’t detailed.

What to decide before you commit

Four questions settle most of it:

  1. How fresh does the data need to be? Real-time access matters most for news-driven agents, ScrapingBee notes. A weekly-refreshed knowledge base has a very different budget.
  2. How many searches and fetches will one task trigger? Multiply it out as in the example above.
  3. How much control do you need over sources and ranking? Summarizing APIs are faster to start with. Scraping APIs give you the raw content for your own indexing.
  4. What happens when the upstream changes? Keep the search layer behind an interface you can swap, as the num=100 episode suggests.

The short version

Don’t pick one tool for the whole agent. Use a search API to find pages, a crawl API to read them, and your own infrastructure only where volume or control pays for the operational work. Then measure cost per completed task, because per-request prices will mislead you.

A caveat on the evidence: most of what I found is vendor writing, and the pricing is self-reported and will have moved. Mastra gives no pricing or latency comparison at all. Treat the table as a starting point and run your own test on a few hundred real tasks.

Sources