Latency is the metric everyone asks about and almost nobody measures correctly, so let me set expectations up front: I am not going to quote millisecond numbers in this post. Latency depends on your region, your payload, the provider’s day, and a dozen things I cannot know about your setup. What I can give you is the structure, because the structural differences between search APIs are stable even when the milliseconds are not, and structure is what you should route on.
Why the tiers have different speed profiles
Search APIs do different amounts of work per query, and the work is visible in the product design.
A SERP-style API like Serper is fundamentally a lookup against an index someone else already built. The heavy lifting (crawling, ranking) happened before your query arrived. Structurally, this is the fastest shape a search API can have, and it is part of why the SERP tier is also the cheap tier at $1.20 per thousand queries routed.
An independent-index provider like Brave does the same shape of work against its own index. Neural providers like Exa and Perplexity add inference: the query gets embedded and matched by meaning, which is more compute per request than a keyword lookup, structurally.
Then there is the biggest factor people forget: payload size. Content-included search (Exa, and Firecrawl Search at $2.40 per thousand routed) can return the actual page text with results. That is more bytes to assemble and transfer than ten links with snippets, and it will never be as fast as a bare SERP response. But this is exactly where naive latency comparisons mislead, because that slower call may replace a search plus several scrape calls. The end-to-end task can finish sooner on the “slower” API. Measure the workflow, not the request.
p50 flatters you, p95 is your actual experience
The median request does not describe an agent’s life, because agents make many calls per session, and the session is only as fast as its slowest dependencies.
The math is worth internalizing. If a session fires 20 search calls, the chance that at least one of them lands beyond the provider’s p95 is 1 minus 0.95 to the 20th power, which is about 64%. At 50 calls it is over 92%. Tail latency is not an edge case for agents; it is a near-certainty per session, experienced by every user. Two providers with identical medians and different tails are not interchangeable, and the one with the fatter tail will feel slower in production despite the identical p50 on the marketing page.
This is also why timeouts and failover are latency tools, not just reliability tools. A request that would have taken forever, cut off and retried against a different provider, often completes faster than waiting out the slow one. Our router enforces a per-request wall-clock budget on the whole failover chain (20 seconds for search) precisely so the worst case is bounded: an agent gets an answer or a clean failure inside a known envelope, never an unbounded hang. Bounding the tail is frequently worth more than shaving the median.
When fastest-first routing is right
The router can sort providers cheapest-first, quality-first, or fastest-first, and fastest-first is the mode I recommend least often but most emphatically when it fits.
It fits when a human is waiting on the loop. Voice agents are the extreme case: dead air is product failure, and paying the neural-tier premium for a search that arrives too late to use is the worst of both worlds. Interactive copilots are close behind. In these settings, a fast good-enough result beats a slow excellent one, and I would rather take Serper’s answer now than something marginally better later.
It does not fit for batch and background work. A research agent filling a report overnight should sort by quality (Exa scores 90 in our catalog for a reason) and let latency float. Spending speed-tier tradeoffs on a pipeline nobody is watching is optimizing a number no one experiences. And as I argued in the semantic vs keyword piece, query type should drive tiering first; latency policy comes after.
The pleasant surprise is that the tiers mostly cooperate: the cheap SERP tier is also the structurally fast tier, so cheapest-first and fastest-first often pick the same provider for navigational traffic. The policies diverge on the hard queries, which is where you actually have a decision to make. Either way it is a saved routing preference, not an architecture change.
Measure it yourself, from where you run
Whatever numbers you find published, including any impressions you infer from my writing, your agents will experience something different, because they run from your infrastructure against your query mix. Wrap your search calls with timing, log per provider, and compute your own p50 and p95 after a week of real traffic. Every response from our router includes the full routing.attempted chain, so you can attribute slow requests to the provider that actually served them rather than blaming the tier. A day of your own percentiles outranks anyone’s benchmark page, mine included.
Prices, quality scores, and payload capabilities for all six search providers we route are side by side on the search API comparison page.