Fastest search APIs: what the latency numbers actually measure

Exa was quickest in our three developer-source tests. That does not make it the fastest search API for every application. We tested particular configurations in August, and several providers now have modes we did not run.

If you need a low-latency shortlist, start with the exact mode, the statistic being reported and whether the result was usable. A 200 ms response that forces three more searches can lose to a slower call that returns the evidence the agent needs.

This page compares the available evidence without pretending it came from one experiment. The search API directory covers the broader vendor set; the benchmark register preserves the source and limitations of external results.

The speed we measured ourselves

On August 23, we sent Exa, Perplexity Search and Parallel Search the same three developer-source tasks, three times each. All 27 attempts passed. The expected primary source ranked first every time.

These ranges contain three case medians, not a pooled p50 and not a confidence interval. The full reports retain the request parameters, individual attempts and outputs: Exa, Perplexity and Parallel.

The sample is small, from one environment, with easy-to-recognize technical sources. It does not establish a production SLA, a global speed ranking or today's performance of modes released later. In particular, it is not a comparison of Parallel Turbo with Exa Instant or Perplexity Fast.

External benchmarks identify other low-latency candidates

NEEDLE publishes rolling successful-call percentiles. In the seven-day view we reviewed on October 27, selected entries were:

Keenable also operates the benchmark and competes in this market. That does not invalidate its measurements, but it is relevant context. Inspect its methodology, error column and current window before choosing from the table.

Do not place these p50 values directly beside our case medians and sort them into one leaderboard. The query mix, modes, location, time window and treatment of failures differ. They suggest configurations worth trying, not a universal order.

Endpoint time and agent time are different

An API call ends when the response arrives. An agent task ends when the application has a supported answer or a completed action.

The second includes model reasoning, additional searches, page fetches, retries and decisions about whether the sources are sufficient. Artificial Analysis distinguishes tool latency from model-inclusive task time. A seconds-per-task column is not a hidden claim that one HTTP request took that long.

For a coding agent, measure these separately:

• Time to the first usable source.
• Search calls and page fetches per completed task.
• Total task time, including retries and model work.
• Source accuracy and completion rate under the same deadline.

Payload size is part of this trade-off. A large excerpt may remove a fetch or merely make the model read more irrelevant text. There is no safe shortcut from response size to usefulness.

Tail latency matters more when the agent loops

A low median can hide occasional very slow requests. If the agent searches several times, one slow call can dominate the experience. But do not claim to estimate a stable p99 from nine attempts; our run is nowhere near large enough for that.

Use the distribution from enough repeated requests on your own workload. Include timeouts in the reliability denominator instead of dropping them and celebrating the remaining fast responses. Record warm versus cold behavior and cache settings when the provider exposes them.

Do not silently treat a timeout as an empty successful search. The agent should know whether no sources were found or retrieval failed.

How to choose a fast search API

Start with a small set of queries whose expected primary sources you recognize. Include one exact lookup, one ambiguous question and one freshness-sensitive task. Hold result counts and content budgets steady where the APIs allow it.

Then compare modes before providers. Test the fast configuration you would actually deploy, not an expensive research mode selected by someone else's default. Keep a task-quality threshold so speed does not become a reward for returning too little evidence.

Our Exa vs Parallel, Exa vs Perplexity and Parallel vs Perplexity pages connect the historical run to current integration choices. For a new agent integration, use the best search APIs workflow guide.

The shortest defensible conclusion remains narrow: Exa had the lowest case medians in our August run. Current low-latency modes from other vendors deserve their own matched test.