Web search is the hidden cost line in most AI agents. Every research task turns into a dozen or more search calls, and both latency and price compound. On September 24, 2026, Perplexity said it rebuilt the engine underneath its Search API, and that one new preset now runs agent tasks 68% cheaper than its default.
The engine is called Photon. Perplexity describes it as a Rust-based retrieval and ranking service built "by a small team of engineers and hundreds of agents," and it replaces the open-source engine the company used before.
TL;DR: Photon and Fast Search
| Question | Answer |
|---|---|
| What is it? | Rust retrieval and ranking service behind the Perplexity Search API |
| New option | Fast Search preset |
| Latency | 95% of results in 230 ms or less; median about 160 ms |
| Cost | 68% lower cost per agent task vs the default preset (Perplexity's benchmark tests) |
| Infrastructure result | p99 latency reportedly about 800 ms down to 65 ms |
| Index | Over 200 billion URLs, hybrid lexical and semantic retrieval |
| Quality cost | About 0.24 relevance points and 3 points of answer availability on long-tail queries |
| Best for | Routine agent lookups with many search calls per task |
Why does search cost matter for agents?
A chat answer might use one search. An agent that researches a company, verifies a claim or fills a form can issue dozens across a single task. If each call costs more and takes longer, agent runs get slow and expensive at exactly the point they scale. Perplexity's framing is that faster, cheaper retrieval matters most for "AI agents performing multiple searches per task."
That connects directly to the cost themes we have covered elsewhere: Gemini context caching numbers in agent harnesses, Claude Code prompt-cache efficiency, and AT&T's 56% coding cost cut through routing. Model tokens get the attention, but tool calls are often the second-largest bill.
How does Photon work?
Perplexity's description points to three engineering choices:
- Compact index formats, so a query reads only the data it needs rather than large blocks.
- Asynchronous batched disk reads, so storage access does not become the bottleneck.
- A hybrid retrieval pipeline that combines lexical matching with semantic ranking across an index of more than 200 billion URLs.
The reported infrastructure result is a p99 latency drop from around 800 ms to 65 ms. Tail latency is what breaks agent loops, because one slow call stalls an entire multi-step task, so the p99 figure matters more than the median.
The Rust choice is consistent with Perplexity's recent infrastructure work: it joined the Rust Foundation to back its agent sandbox, covered in Perplexity Joins the Rust Foundation to Back SPACE, and it has published details of its GPU embeddings stack in Fast Embeddings on GPUs. "Built with hundreds of agents" also echoes the pattern in OpenAI's Rust rewrite of Habitat with two engineers: small teams using coding agents to rewrite performance-critical systems.
What does Fast Search give up?
Perplexity is upfront about the trade-off. Internal testing found "a 0.24-point reduction in relevance and roughly a three-percentage-point reduction in answer availability on long-tail and broad-coverage query evaluations."
Read that carefully:
- Relevance loss is small on the scale Perplexity uses, but the scale itself is not published in the coverage we reviewed, so 0.24 points is hard to interpret in isolation.
- Answer availability drops about 3 points. That means roughly 3 in 100 long-tail queries that would have found an answer now do not. For a lookup where a miss triggers a retry, that is acceptable. For a compliance check where a miss silently yields a wrong answer, it is not.
- The 68% figure is per task, not per call. It reflects total task cost across Perplexity's benchmark tasks versus the default preset, and depends on how the agent uses results. Your workload will differ.
When should you use Fast Search?
| Use case | Fast Search? | Why |
|---|---|---|
| Agent verifying a fact from a well-covered source | Yes | Common queries hit the strong part of the index |
| Routine lookup inside a long tool loop | Yes | Latency and cost compound across many calls |
| Long-tail research, niche technical or local topics | Test first | Answer availability is where the loss shows up |
| Legal, medical, compliance or financial checks | No, or verify | A missed result can be worse than a slow one |
| Deep research reports | Default or a mix | Recall matters more than speed |
A practical pattern is tiered retrieval: try Fast Search first, and escalate to the default preset only when the agent reports low confidence or an empty result. That keeps most calls cheap while protecting the hard cases.
How to test it in an afternoon
- Collect 50 to 100 real agent tasks from logs, including some long-tail ones.
- Run each twice, once on the default preset and once on Fast Search, with the same model and prompts.
- Score outcomes: task success, citation quality and empty-result rate.
- Record cost and wall-clock time per task, not per call.
- Set a routing rule based on where Fast Search matches the default, and monitor the miss rate in production.
This mirrors the retrieval-evaluation thinking in Perplexity's own Q2D-Web benchmark for agentic RAG, and you can watch the effect in production with an agent observability tool like numbat.
What are the caveats?
- Vendor benchmarks. The 68%, 230 ms and 800-to-65 ms figures come from Perplexity. Verify on your workload.
- Pricing details. We could not find a per-request price for Fast Search in the announcement text, so compare against your actual invoice.
- Index freshness and coverage. A large index does not guarantee coverage of the niche sources your agent depends on.
- Lock-in. Optimizing an agent around one search API's presets makes switching harder; keep the search call behind an interface.
What this means for what you build or pay
- Audit your tool-call spend. If search calls are a meaningful share of an agent's run cost, a cheaper preset can matter more than a cheaper model.
- Design for tiered retrieval. Cheap first pass, expensive fallback, with confidence as the trigger.
- Watch tail latency. Ask any search provider for p95 and p99, not the median.
- Do not over-read "68%." It is a benchmark-average reduction, and the honest number for you comes from your own tasks.
How does this compare with other ways to cut agent cost?
There are three main levers for agent spend, and Photon touches only one of them.
| Lever | What it changes | Typical trade-off |
|---|---|---|
| Cheaper or smaller model | Token cost per step | Lower reasoning quality on hard steps |
| Caching and compaction | Repeated context cost | Engineering effort, cache-miss risk |
| Cheaper tool calls (Fast Search) | Cost and latency per search | Slightly lower recall on long-tail queries |
The levers stack. A team that routes easy steps to a smaller model, keeps prompts cache-friendly and sends routine lookups to a fast search preset can compound the savings, but each change should be measured separately so you know which one moved the bill. Combining three unmeasured changes and seeing a good number tells you little about which to keep.
What should you log to make the decision?
To judge Fast Search on your own traffic, capture these per task: the number of search calls, total search cost, wall-clock time, whether the final answer was correct or accepted, and whether any search returned empty. Break results out by query type, since Perplexity's own numbers say the loss concentrates in long-tail and broad-coverage queries. If your traffic is mostly common, well-covered topics, you may see the full cost benefit with almost no quality loss. If it is mostly niche, you may see the opposite.
Also record which calls the agent retried. A cheap search that forces a second call can erase the savings, and a retry pattern is often the earliest sign that a preset is a poor fit for a given task class.
Why the Rust and agents detail is worth noticing
The claim that a small team plus hundreds of agents built a replacement search engine is a data point about how infrastructure work is changing. Rewrites of latency-critical services used to be multi-year projects reserved for large teams. If a small group can now do it with agents, expect more vendors to swap out core components quickly, which means the performance and price of the APIs you depend on may change faster than your procurement cycle. Build with interfaces you can swap and evals you can rerun.
Related reading on explainx.ai
- Perplexity Joins the Rust Foundation to Back SPACE
- Perplexity's Fast Embeddings on GPUs
- Perplexity Q2D-Web: benchmark for agentic RAG retrieval
- numbat: Perplexity's observability tool for AI agents
- Context caching in agent harnesses: the numbers Google left out
- AT&T cuts AI coding costs 56% with model routing
- OpenAI rewrote Habitat from Python to Rust with two engineers
Official sources: Perplexity's Fast Search announcement on its API platform forum and its Photon technical overview.
Figures are as reported by Perplexity and secondary coverage on September 24-25, 2026, and have not been independently reproduced.
