Do you still need a search API when the model has web search? Two 2026 evals, read carefully

Vals AI's Web Search Index, last updated 15 July 2026, compares the native web search built into frontier models against independent web-search tools on legal-research and finance-analysis tasks. It covers eight models. The top score on the board is 48.5%, from Claude Fable 5.

That number is the reason this post exists. Until this year the build-versus-buy question for search had no third-party evidence attached to it, because published evals scored the bundle: a model plus whatever retrieval it happened to use, reported as one accuracy figure. You could not tell whether a wrong answer came from bad retrieval or bad reasoning over good retrieval, which is exactly the thing you need to know before you decide whether to pay a second vendor. Vals separates the search layer from the model. That makes the comparison legible for the first time.

serp.fast runs no benchmarks of its own. Every number below is someone else's, and named.

What the index measures, and what it does not

The Web Search Index scores search on two professional task families, legal research and finance analysis, where the correct answer usually sits in a specific document rather than in a summary of the topic. Those are recall-hard tasks. They reward a retrieval layer that can reach a filing, a docket, or a footnote, and they punish one that returns a competent overview of the general subject.

That framing is useful for anyone building research, diligence, or compliance features, and it is a poor proxy for a shopping agent or a support bot. It also says nothing about throughput, price, or how a provider behaves when a query returns nothing. Treat it as evidence about one dimension, not a ranking of vendors.

The headline that should slow you down

The top score is under 50%. On the tasks Vals measures, more than half of attempts fail, whichever side of the native-versus-independent line the configuration sits on.

A comparison table invites you to pick the winner. The more defensible reading of a sub-50% board is that neither native model search nor an independent API is a finished product for hard retrieval, so your architecture should assume a meaningful failure rate rather than try to design it away. That means citations a human can check, a visible "not found" path instead of a confident guess, and a second retrieval channel for the queries the first one whiffs. Our build-versus-buy guide for web data argues that from general principles. This is the first dated third-party number that supports it.

The variable that decides agent loops

Accuracy is the number that gets published. Latency is the number that decides whether an agent loop is usable, and it almost never appears in the same table.

AIMultiple ran a comparison of eight search APIs in May 2026, covering Brave, Tavily, Exa, Firecrawl, SerpAPI, Perplexity and two Parallel tiers, and reported roughly a twentyfold spread between the fastest and slowest responses: under a second at one end, low double-digit seconds at the other. Those are reported figures from a periodically re-run comparison, so check the live table before you quote them, and note that the ranking on their agent-oriented score put Brave at the top rather than any of the AI-native entrants.

Take the shape rather than the digits. A single query at 13 seconds is an acceptable page load. An agent that fans out to twenty queries per task, serially in places, turns the same provider into a two-minute wait and a user who leaves. This is where a per-query API and native model search stop being interchangeable in a way accuracy alone never shows: you can put a timeout, a cap, and a fallback on a provider you call directly. Inside a bundled tool call you mostly cannot.

Vendor claims carry information, if you label the source

Two vendor announcements are worth reading precisely because they are marketing.

Brave's AI Grounding post, published August 2025 and updated that September, states an index of over 30 billion webpages and over 1.5 billion monthly queries, prices the AI Grounding plan at $4 per thousand web searches plus $5 per million tokens, and claims an F1 of 94.1% on SimpleQA for its research configuration. Linkup announced a $10M seed led by Gradient on 3 March 2026 alongside Linkup /fast, which it markets as the most accurate sub-second web search API, and a company post claims a 92% F-score on Verified SimpleQA. All of those are vendor-published and unaudited.

Whether 94.1% or 92% is real matters less than the distance between numbers in the nineties on SimpleQA-family tests and 48.5% on Vals's legal and finance tasks. SimpleQA asks short factual questions with a single verifiable answer; Vals asks for a specific filing or footnote. Roughly the same retrieval capability produces a 45-point swing depending on which test a vendor picks, and vendors pick the one that flatters them. Read the task family first and the score second, and treat any figure a vendor selected for its own launch post as a claim about what it optimizes for rather than a measurement you can rely on.

Where native search genuinely wins

Four cases where the model's built-in search is the right answer and a second contract is overhead:

• Search is incidental to the task. One grounding call per conversation, not one per reasoning step. The integration cost of a separate provider is not repaid.
• You are already committed to one model provider and have no near-term plan to switch. The coupling you are adding is coupling you have already accepted.
• You do not re-rank, cache, or store results. If the model consumes its own retrieval and you never touch the intermediate output, the format instability that makes bundled search awkward downstream never bites.
• Volume is low enough that per-query cost is noise against your token bill. Below a few thousand queries a month this is usually true.

Where an independent API wins

• Freshness or source coverage you have to be able to state. If a customer asks which sources a feature reads, "whatever the model's search returned" is not an answer. Valyu covers arXiv, PubMed and SEC filings alongside the web; Linkup licenses publisher content rather than crawling it; Brave Search API runs its own index. Each of those is a claim you can put in a contract.
• Filtering as a first-class parameter. Domain allowlists, date ranges, and result-count control are API arguments with Exa, Tavily and Parallel AI. With bundled search they are prompt instructions the model may or may not follow, which is a different reliability class.
• Cost control at fan-out. An agent that issues twenty to fifty queries per task needs a unit price you can multiply, a hard cap, and a per-tenant meter. Bundled search costs you tokens on a schedule the provider controls.
• Jurisdictional or licensing constraints. Regulated buyers increasingly ask where retrieved content came from and under what licence. Provenance is a property of the retrieval vendor, not of the model wrapped around it.

The side-by-side of the AI search APIs covers the feature differences between the independent options; Exa versus Tavily is the closest of those calls for most RAG workloads.

Read benchmarks against your own task shape

The most common misuse of a search eval is reading a read-only retrieval score as a general capability estimate. ClawBench is the cleanest illustration of why that fails. It runs 153 everyday tasks across 144 live production sites in 15 categories, including purchases, appointments, job applications and long forms, behind an interception layer that stops real side effects. Its leaderboard, last updated 10 July 2026, has Claude Sonnet 4.6 on top at 33.3%.

ClawBench's own methodology tells you to read it beside WebVoyager and Online-Mind2Web, because navigation ability and transactional ability separate. A system that retrieves well can still fail at the point where it has to change state on someone else's site. If your product's hard part is finding the right document, the Vals index is the relevant board. If the hard part is completing something, it is not, and our survey of AI web agent benchmarks maps which suite covers which shape.

A procedure instead of a verdict

The answer depends on your task shape, your query volume, and whether you have to be able to name your sources to a customer. What generalizes is the order you test in.

Start with native search, because it is free to try and settles the question for the cases in the first list above. Instrument it before you judge it: log every query, every source returned, and the latency of the whole call, for a week of real traffic. Then replay the same query set against two independent providers, scoring on your tasks rather than on legal research or SimpleQA. Two, not one and not five, because a single alternative gives you no sense of variance and five is a procurement project. If you cannot tell the three apart on your own scoring, native search wins on integration cost and you are done.

If you do switch, keep the second provider warm. Put both behind one retrieval interface so the swap is a config change, and keep enough traffic on the runner-up to know it still works. The guide to independent indexes is the shortlist to draw those two from.

What this means if you build on web data

• A sub-50% top score is a design input, not a disqualification. Build the failure path first: checkable citations, an explicit not-found state, and a second channel for the queries that miss.
• Benchmark the search layer separately from the model. The split Vals AI's Web Search Index uses is the pattern to copy internally. A bundled accuracy number cannot tell you whether to buy retrieval.
• Latency belongs in the comparison table. A twentyfold spread across providers, as AIMultiple reported in May 2026, decides more agent products than a few points of accuracy do.
• Vendor benchmark choice is positioning. Nineties-range SimpleQA scores and a 48.5% ceiling on professional research tasks are both real. Which one predicts your product depends entirely on which resembles your task.