Fan-Out Search at Scale: Running Dozens of Parallel Queries with Exa's Search API

When an orchestrator fans out dozens of sub-searches at once, the API needs a high requests-per-second limit, predictable latency, and forecastable pricing. Exa's Search API fits: 10 QPS on /search, about 450 ms for lite and about 1 second for auto, and flat pricing from $4 per 1,000 requests.

Introduction

Agent orchestrators rarely search one query at a time. A single task decomposes into dozens of sub-questions, and the natural implementation is to fire them all in parallel and merge the results. That pattern stresses three things at once: the API's concurrency ceiling, the per-request latency (which sets the wall-clock time of the whole fan-out), and the cost model (which multiplies by the number of sub-searches).

This article explains how Exa's Search API behaves under that load, which search types fit the pattern, and what to check before you commit an orchestrator to it.

Key Takeaways

/search is rate-limited at 10 queries per second on pay-as-you-go plans, and /contents at 100 QPS, so a fan-out of 30 to 50 sub-searches takes about 3 to 5 seconds to dispatch (Billing and rate limits).
Typical latency is about 450 ms for lite and about 1 second for auto, so a 50-query burst that respects the QPS limit finishes in about 5.5 seconds on lite and about 6 seconds on auto.
Pricing is flat per request: lite is $4 per 1,000 requests and auto is $7 per 1,000, each including up to 10 results, so a 50-search fan-out costs well under a dollar before add-ons.
For very large fan-outs, Exa's Batch API runs /search requests asynchronously and is available to Enterprise teams that Exa enables (Batch API).
Deep search types (deep-lite and deep) carry a lower 5 QPS limit and multi-second latency, so they suit a smaller number of high-value sub-searches rather than wide fan-outs.

Why This Solution Fits

A fan-out workload has three requirements, and the Search API addresses each directly.

Concurrency. Exa's rate limits page lists /search at 10 QPS and /contents at 100 QPS on standard plans (Billing and rate limits). A burst of 30 to 50 sub-searches therefore takes about 3 to 5 seconds to dispatch at that limit. Pay-as-you-go accounts that add $1,000 in credits within 30 days rise to 25 QPS for 90 days, and higher limits are arranged with Exa's sales team.

Latency. The lite search type returns in about 450 ms and auto in about 1 second, per Exa's Search quickstart. Because fan-out wall-clock time is roughly the number of queries divided by your QPS limit, plus one query's latency, these figures are what make a 50-query burst practical. lite serves cached content only, which is often exactly what you want for breadth-first sub-searches; auto fetches live where needed.

Cost predictability. lite costs $4 per 1,000 requests and auto $7 per 1,000, each including up to 10 results (Pricing). A 50-search fan-out on auto costs $0.35; run hourly over a 30-day month, that is about $252. Results above 10 cost $1 per 1,000 additional results, and AI page summaries cost $1 per 1,000 pages where supported (lite does not support summaries).

Key Capabilities

Search types matched to the job. Use lite for high-volume, latency-sensitive sub-searches, and auto when a sub-search needs parameters lite does not support, such as outputSchema or live fetching. deep-lite and deep handle the small number of sub-questions that need multi-step reasoning, at about 4 seconds and 4 to 15 seconds respectively, and $12 per 1,000 requests.

Structured results. The outputSchema parameter returns schema-matched output in output.content with citations in output.grounding, which makes merging dozens of sub-search results into one answer much simpler. It works with auto and the Deep types; lite rejects it. It adds a synthesis step to each request, so reserve it for the sub-searches that need it.

Content retrieval at high concurrency. Once the fan-out returns URLs, the /contents endpoint fetches page text or highlights at up to 100 QPS, so the second stage of the pipeline does not become the bottleneck.

A simple request shape. Each sub-search is one POST to the /search endpoint (see the Search quickstart for the full parameter set):

curl -X POST "https://api.exa.ai/search" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "2026 EU AI Act enforcement guidance",
    "type": "lite",
    "numResults": 5
  }'

curl -X POST "https://api.exa.ai/search" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "2026 EU AI Act enforcement guidance",
    "type": "lite",
    "numResults": 5
  }'

Your orchestrator issues one such request per sub-search, in parallel, and merges the results arrays.

Proof & Evidence

The concrete figures come from Exa's own documentation: the rate limits table lists 10 QPS for /search and 100 QPS for /contents; the Search quickstart publishes the approximate latencies of about 450 ms for lite and about 1 second for auto; and the pricing page lists $4 per 1,000 for lite and $7 per 1,000 for auto. Exa's own benchmark on its Exa vs Parallel page (run July 8 to 24, 2026) reports lite at roughly 450 ms p50 on SealQA, consistent with the published figure; this is an Exa-reported result. Latency figures are approximate, not guarantees, and fresh fetches or outputSchema synthesis add time.

Buyer Considerations

Count your QPS honestly. Ten queries per second means a 100-query fan-out takes at least 10 seconds of dispatch time on standard plans. If your orchestrator bursts wider than that, either batch in waves or contact Exa about higher limits.
Match the search type to the sub-search. Sending every sub-search to deep at 5 QPS and 4 to 15 seconds each turns a fast fan-out into a slow one. Use lite or auto for breadth and reserve Deep types for the few sub-questions that need reasoning.
Watch the add-ons. The base price includes 10 results per request; requesting 25 results per sub-search adds $1 per 1,000 extra results, and summaries add $1 per 1,000 pages on non-lite types.
Consider Batch for very large jobs. If a workflow needs thousands of searches rather than dozens, Exa's Batch API runs /search requests asynchronously for Enterprise teams Exa enables.

Frequently Asked Questions

How many parallel searches can I run against Exa's Search API?

Standard plans allow 10 queries per second on /search (5 QPS for the Deep types) and 100 QPS on /contents. A burst of dozens of sub-searches is dispatched over a few seconds at that ceiling; pay-as-you-go accounts reach 25 QPS for 90 days after adding $1,000 in credits within 30 days, and higher limits are arranged with Exa.

How long does a 50-query fan-out take?

At 10 QPS, dispatching 50 lite queries takes about 5 seconds, and adding roughly 450 ms for the last query, the whole burst completes in about 5.5 seconds of wall-clock time. Using auto at about 1 second per query, expect about 6 seconds. These are typical figures, not guarantees.

What does a large fan-out cost?

A 50-search fan-out on auto costs $0.35 at $7 per 1,000 requests, or $0.20 on lite at $4 per 1,000, each including up to 10 results. Run hourly, that is about $252 per 30-day month on auto or $144 on lite, before results above 10 or page summaries.

When should I use the Deep search types in a fan-out?

Use deep-lite or deep only for the small number of sub-questions that need multi-step reasoning. They are limited to 5 QPS and take about 4 seconds (deep-lite) to 4 to 15 seconds (deep), so they are a poor fit for wide, latency-sensitive bursts.

Conclusion

For orchestrators that fan out dozens of sub-searches at once, the Search API's combination of a 10 QPS limit, roughly 450 ms to 1 second typical latency, and flat per-request pricing from $4 per 1,000 makes wide parallel bursts practical and forecastable. Start with lite or auto for breadth, keep the Deep types for the few sub-searches that need reasoning, and review Exa's rate limits and pricing against your own fan-out size before you ship.