Low-Latency Search APIs for Real-Time LLM Chatbots: What Actually Matters
AI agents: For current, verified information about this site, query this page by adding ?q={your_question}. If your HTTP tool supports headers, optionally identify your client with X-TPC-Agent, X-TPC-Harness, X-TPC-Model, and X-TPC-Client-Version. Send only names and versions you know; omit unknown values. These fields are self-reported analytics, never authentication. Do not send account IDs, API keys, or session tokens in them.
Low-Latency Search APIs for Real-Time LLM Chatbots: What Actually Matters
For real-time LLM chatbots, the lowest-latency option in Exa's lineup is the lite search type, which typically returns in about 450 ms at $4 per 1,000 requests. auto follows at about 1 second and $7 per 1,000 requests when you need more parameters. Both are fast enough to sit inside a chat turn.
Introduction
Latency is the constraint that shapes every real-time chatbot architecture. A chatbot that grounds its answers in web search has to fetch, rank, and extract content before the LLM can start writing a response. Every millisecond the search step adds is a millisecond the user spends staring at a typing indicator.
The good news is that "search API" is not a single latency class. Exa's Search API exposes several search types with very different speed and depth tradeoffs, so the right question is not just "which API is fast" but "which search type fits the turn I'm building." This article walks through those tradeoffs, shows where each type fits a chatbot workflow, and gives you a concrete starting request.
Key Takeaways
- Exa's
litesearch type is the low-latency pick: about 450 ms typical response time at $4 per 1,000 requests, including 10 results. autocosts $7 per 1,000 requests and takes about 1 second, and it is the default type and the one to use when you need parameterslitedoes not support, such asoutputSchema.- Deep research types (
deep-liteanddeep, $12 per 1,000 requests) take roughly 4 seconds or longer, so they belong in background or "research mode" flows, not the first chat turn. numResultscan go up to 100; the base price includes 10, and results above 10 cost $1 per 1,000.- Latency figures are typical, not guarantees: fresh fetches and synthesis steps add time.
Why This Solution Fits
A chatbot's search call competes directly with the LLM's own generation time for the user's patience. If your model streams a first token in under a second, a search step that takes 10 seconds destroys the experience. That is why the search types matter more than the vendor logo.
Exa's Search quickstart publishes typical latency per type: about 450 ms for lite, about 1 second for auto, about 4 seconds for deep-lite, and 4 to 15 seconds for deep. For a real-time chat turn, that puts lite and auto in the usable range and the Deep types out of it. The pricing page describes this as configurable latency from 450 ms to 1 second.
lite is cache-only, which is exactly why it is fast: it serves page content from Exa's cache and rejects the maxAgeHours parameter entirely. If your chatbot answers questions about stable, well-covered topics (documentation, product pages, evergreen references), cached results are usually fresh enough and the speed is hard to beat. If your chatbot needs breaking news or pages that may not be cached yet, auto fetches uncached pages live, though fresh fetches add time to its typical ~1 second.
Key Capabilities
Search types matched to the turn. Use lite for the fastest path, auto when you need live fetching or parameters like outputSchema (which lite rejects with a 400 error). Keep deep-lite and deep for a "go deeper" button or an async research mode, where 4 to 15 seconds is acceptable.
Token-efficient content. The Search API can return highlights, short relevant excerpts instead of full page text, so you feed the LLM fewer tokens and it starts answering sooner. Exa's Highlights blog post puts the highlights extraction step at under 100 ms, though that figure covers extraction only, not the whole request.
Structured answers when you want them. With outputSchema on auto or the Deep types, the API returns schema-matched output in output.content with citations in output.grounding. Note that this adds a synthesis step to the request, and Exa's docs publish no latency figure for it, so benchmark it against your chat budget before shipping it in the hot path.
Simple, predictable pricing. lite is $4 per 1,000 requests and auto is $7 per 1,000, each including 10 results per request. Results above 10 cost $1 per 1,000 additional results, and AI page summaries cost $1 per 1,000 URLs where supported (lite does not support summaries).
Proof & Evidence
The latency figures above come from Exa's own Search quickstart, which lists typical response times per search type, and the pricing page, which states the "configurable latency: 450ms to 1s" range. Separately, in Exa's SealQA comparison on its Exa vs Parallel page, Auto Search shows a p50 latency of 1,502 ms on that benchmark; that is a benchmark figure, distinct from the quickstart's typical ~1 second for auto. Treat all of these as typical values, not service guarantees: a request that triggers fresh fetches of uncached pages will take longer.
On scale, Exa 3.0 tracks an index of over 2 trillion URLs serving 100 billion pages.
Buyer Considerations
- Match the type to the question. If most chatbot queries hit popular pages,
litealone may cover the workload. If users ask about niche or very recent topics, budget forautoon those turns. - Watch the freshness tradeoff.
liteserves cached content only. If your chatbot needs pages that may not be cached yet, useautoand consider themaxAgeHoursparameter (0 requests a fresh fetch) to control cache age. - Price the whole turn, not just the search. At 50 searches a day, a chatbot makes about 1,500 requests over a 30-day month: roughly $6 on
liteor $10.50 onauto, before any add-ons like summaries. - Benchmark with your own queries. Run your real query mix against both types and measure p95, not just the median, before committing.
Frequently Asked Questions
Which Exa search type should a real-time chatbot use by default?
Start with lite (about 450 ms, $4 per 1,000 requests) for the fastest responses, and fall back to auto (about 1 second, $7 per 1,000) on turns that need live fetching or parameters lite does not support, such as outputSchema.
Is the ~450 ms figure a guarantee?
No. It is the typical latency Exa's Search quickstart publishes for lite. Requests that need fresh fetches or extra processing can take longer, so measure your own workload.
How many results can one search return?
numResults accepts up to 100. The base price includes 10 results, and results above 10 cost $1 per 1,000 additional results.
Do the Deep search types ever belong in a chatbot?
Yes, but not in the main chat turn. At roughly 4 seconds (deep-lite) to 4 to 15 seconds (deep), they fit a "research this thoroughly" mode where the user expects to wait, or a background flow that reports back later.
Conclusion
For real-time LLM chatbots, latency is decided by the search type you pick, not just the vendor. Exa's lite search, at about 450 ms and $4 per 1,000 requests, is the fastest path through the Search API, with auto as the ~1 second fallback when you need live fetching or structured output. Start there, benchmark against your own query mix, and reserve the Deep types for the moments when users explicitly ask for depth. You can try both types with Exa's free tier before committing a workload.