ContentsStart0%
Exa announced Exa 3.0 on October 19, 2026, combining a retrieval-model upgrade, Dynamic Highlights and broader data coverage with a new Lite search type priced at US$4 per 1,000 requests. The original October 22 article examined the announcement as infrastructure for AI agents, rather than as another consumer chatbot launch.
This adaptation retains the release-era prices and comparisons. Unless an item is explicitly described as rechecked, it is a dated product description, not a quotation for a new deployment. No paid API request was made for this article.
What does Exa provide to an AI application?
Exa offers search and content-retrieval services that developers can call through an API. An application sends a query, receives candidate pages and extracts, then passes them to a language model to construct an answer. Exa competes at the retrieval layer even when another company owns the interface the user sees.
Consider a daily industry-news agent. A language model alone does not guarantee access to today’s announcements. A search service supplies outside material; the application still needs to verify dates and distinguish a press release from independent reporting. This is one possible use of retrieval-augmented generation, not a claim that RAG requires Exa.
The company’s FAQ describes an independent index and crawler. The original October coverage recorded Exa’s claim of tracking more than two trillion URLs with approximately 100 billion searchable pages. These are vendor scale claims; they do not measure whether a source will be returned for a particular question.
| Stage | Responsibility |
|---|---|
| User request | Define the question and any freshness or source requirements. |
| AI application | Decide whether to retrieve outside information and form a query. |
| Exa Search API | Return candidate URLs and available content or highlights. |
| Answer generation | Use the evidence, report uncertainty and provide appropriate citations. |
What changed in Exa 3.0?
Exa attributed the release’s retrieval improvement to a larger embedding model trained with more compute and data. Embeddings compare meaning rather than depend entirely on identical keywords. A query about reducing inference cost may need material on quantization or inference chips without repeating the exact phrase.
A larger retrieval model does not guarantee every source improves. Applications still need to test the topics, languages and source types relevant to their work.
Dynamic Highlights and the 95% token claim
Highlights select passages instead of returning full pages. Dynamic Highlights allocates the text budget across the result set: more space can go to a useful source while repeated material is reduced elsewhere. Exa reported an average reduction of about 95% in tokens compared with full-page content in its own evaluation, alongside improvements in some downstream answers.
The baseline matters. A 95% reduction from full text is not a guaranteed 95% reduction in an application’s total bill, which may include model reasoning, other tools and repeated searches. It does not mean every query retains all necessary evidence.
A documentation inconsistency remained visible in the source check. The launch post said Dynamic Highlights was generally available at no additional charge, while the technical page rechecked on October 26 still described a research preview and showed the header Exa-Beta: dynamic-highlights-2026-08-28. Developers should resolve the behavior against the relevant SDK and documentation rather than assume the announcement removed that requirement.
Products, places and time-sensitive information
The release described more than 1.27 billion product records and over 211 million local businesses, plus news, weather, sports, markets, flights, events, traffic and podcast information. Some capabilities predated October 19: Exa Places was announced on October 5.
These categories fit tasks beyond reading articles. Finding a café open now requires hours and location; comparing products requires prices and stock. A field being present in an index does not prove it is complete or current, so operational decisions still need a freshness check.
Lite versus Auto: the release-era cost comparison
The original article recorded these vendor prices and typical latency figures during the release period. They are a dated comparison, not end-to-end guarantees or a present-day contract.
| Search type | Base price | Vendor’s typical latency |
|---|---|---|
| Lite | US$4 | About 450 ms |
| Auto | US$7 | About 1 second |
| Deep-lite | US$12 | About 4 seconds |
| Deep | US$12 | About 4–15 seconds |
The original check included up to 10 results per basic request, with US$1 per additional 1,000 results beyond that allowance; further processing could add charges. Its free-tier record was US$10 in monthly credits plus a US$10 onboarding bonus without an initial payment method. Recheck the live price and actual account allowance before estimating expenditure.
At those basic rates, 10,000 requests cost US$40 on Lite and US$70 on Auto, before extras. The relevant comparison is the total cost of completing the same task. A cheaper search that forces repeated queries can erase the saving.
Lite and Auto share an index. Exa said Auto spends more compute across retrieval, highlights and ranking. The original technical check recorded two important Lite limits: cached content only, with no live fetch at request time, and rejection of unsupported parameters such as outputSchema, systemPrompt and maxAgeHours with HTTP 400. When requested content is unavailable in cache, a result may be omitted from content-bearing output.
Those limits matter for breaking news, changing policies and prices. Auto may support the needed controls, but choosing Auto alone does not prove every returned page was freshly retrieved.
How much do the benchmark claims establish?
The launch said Exa led every benchmark it tested. The original coverage retained these examples from Exa’s published comparison:
| Benchmark | Exa 3.0 | Next listed provider | Gap |
|---|---|---|---|
| BrowseComp | 91.8% | Perplexity, 91.5% | 0.3 percentage points |
| DSQA | 88.2% | Perplexity, 87.6% | 0.6 percentage points |
| WideSearch | 56.1% | Parallel, 55.4% | 0.7 percentage points |
These small margins describe those tests, not a universal provider ranking. The launch also links an external search index; neither that link nor the vendor table is an independent reproduction performed for this article. The evaluations have not been rerun.
For an application, evaluate relevant-source coverage, freshness, latency and answer quality together. Two providers with similar headline scores can retrieve different sources, and a downstream model can still misuse a good source.
What would a small API integration look like?
The release-era example used the official Python SDK. It requires an API key outside the source code, such as in EXA_API_KEY. This illustrative integration is preserved from the original article and was not executed in this adaptation.
Connecting a search API does not establish whether an agent will find and select it. The TSO guide to tool selection separates integration, candidate exposure, selection and successful invocation.
pip install exa-py
from exa_py import Exa
exa = Exa()
result = exa.search(
"latest AI search API developments",
type="lite",
num_results=5,
contents={"highlights": True},
)
for item in result.results:
print(item.title, item.url)
The request asks for at most five results with available highlights. Changing the type to auto gives a starting point for comparison, while keeping the task and output requirements fixed. Direct HTTP integration uses the search endpoint with the authentication specified in current documentation.
Exa also documents a hosted MCP endpoint, https://mcp.exa.ai/mcp, and integrations in its MCP guide. The original check recorded limited access without an API key, subject to rate, capability and client requirements. A documented integration does not prove every user or task works without authentication.
What website owners should know about ExaSearchBot
Exa’s crawler policy distinguishes ExaSearchBot, which discovers and indexes public pages, from ExaUser, which fetches pages following a user request. It explains how crawler-specific rules, relevant search-engine rules and the generic group are used to decide access.
User-agent: ExaSearchBot
Disallow: /
This declines crawling. It does not itself request removal of an indexed page. Exa describes noindex in a meta element or X-Robots-Tag for that purpose; the crawler needs access to discover it. Blocking the fetch can prevent it from seeing a newly added noindex instruction.
The policy also documents Web Bot Auth signatures. Use the documented verification rather than trusting an arbitrary User-Agent. The AI crawler policy guide and analysis of agent restrictions separate discovery preferences from permission to operate a service.
Does this create a new “Exa SEO” requirement?
It creates a research question, not evidence for a guaranteed optimization recipe. Google inclusion does not prove Exa inclusion. Exa inclusion does not prove an application will retrieve the page, and retrieval does not prove the final answer will cite it.
Exa Places lists business fields such as name, category, location, phone, hours, website and ratings. Their overlap with LocalBusiness structured data and business listings does not establish that a schema property improves Exa ranking. Consistent public facts remain useful without inventing that causal claim.
The original referenced a Taipei restaurant observation made with Perplexity, where third-party information could supply facts about businesses without official sites. That was a different service and sample; it cannot establish Exa’s mechanism. It illustrates why a brand’s information footprint may extend beyond its own domain.
Two controlled studies would be more informative than a ranking promise: compare source overlap for identical questions across providers, then hold the model and prompts fixed while changing only the retrieval service. Measure citation differences, accuracy, failures and total task cost. These are proposed studies, not completed results.
For developers, Lite reduces the announced basic request price. The best choice depends on how much relevant and sufficiently fresh evidence the application gets per completed task.



