Perplexity Moves Search to Photon and Launches a Fast Search API Mode

Perplexity has moved its search pipeline to Photon, its own engine for finding and ranking web pages, and used it to launch a fast Search API mode for AI agents. As Habr reported on October 18, 2026, the new mode reduces search latency and cost but falls behind standard search on relevance in some tests. It is designed for tasks where an agent needs to search repeatedly; standard mode may be a better fit for research that requires broad coverage of sources.

Why Perplexity Replaced Its Search Engine

Before Photon, the company used a modified open-source engine. As its index and traffic grew, that engine could no longer keep up, so Perplexity replaced it with an in-house system. According to the company, latency at the 99th percentile fell from about 800 ms to 65 ms. That figure measures the engine, not the time for a complete Search API call: the company reports separate numbers for fast mode.

The change matters for more than the speed of a single query. Photon now powers Perplexity’s search pipeline, and the fast API mode runs on the same foundation. So this news concerns two levels at once: how search is handled inside the system and a mode available for agent-based tasks. It is best not to collapse their latency figures into one neat but misleading number.

What Photon Does During a Search

Photon uses an inverted index that maps words to the documents in which they appear. To score the results, the engine keeps a separate, compact record for each document containing word frequencies, positions, and fields. It extracts only the data needed for a given query from that record instead of unpacking the whole thing. A WAND-like candidate selection algorithm lets it skip documents that cannot make it into the final results. Data is also read asynchronously, while index building is separated from query processing. According to the company’s description, this reduces delays caused by disk reads and index updates.

Saving time does not mean Photon is smaller than the previous system in every respect. It stores roughly 2.5 times more data per document, but needs about 20% fewer servers to handle queries. It is worth distinguishing between the amount of information stored and the resources needed to process searches: the company’s figures move in opposite directions.

Speed, Cost, and Quality

In fast Search API mode, median search-call latency is 160 ms, and 95% of calls complete within 230 ms. These are API figures, not the engine’s 65 ms at the 99th percentile mentioned above. The distinction matters when comparing ways to add search to an agent: what counts for that decision is the call the service makes, not just the speed of one component inside Perplexity.

The company tested both modes on 3,554 tasks across six agent benchmarks. Fast mode scored 64.3% at an estimated model-and-search cost of $59.73; standard mode scored 64.0% at a cost of $187.60 on the same set. The estimated savings were about 68%. Those numbers come from a specific comparison: applying that savings percentage to any product or set of queries without testing it yourself would be a stretch.

At the same time, internal tests of individual search results show a drop in quality. The DCG relevance score fell from 2.45 to 2.21, while the share of queries for which the retrieved pages contained an answer fell from 59.6% to 56.7%. Agent-task results are close, even though relevance scores for individual sets of results are lower in the tests. These evaluations measure different things; the report does not explain why they diverged.

For AI service developers, the practical question is which mode to use for a given task. If an agent makes many routine search calls, fast mode offers a way to reduce latency and estimated cost. If the task calls for broad coverage of sources, standard search may be preferable. There is no universal winner here: alongside speed, you have to assess whether the pages found answer the query well enough.

For product owners and marketers, these figures offer a starting point for a conversation with the team: response time alone is not enough to judge search results. The cited tests measured both agent-task performance and whether the retrieved pages contained an answer. Conflating those measures is rather like calling a website finished just because the design mockup opened quickly.

My Take: Fast Search Still Needs Testing

I like that the trade-off is visible in the numbers: you can compare not just milliseconds and cost, but the quality of the results too. The similar agent-task scores are encouraging, but I would not bury the drop in relevance in a footnote. A pixel seems trivial, too—right up until the mockup has already been sent off.

I would choose the mode to suit the task and look at what actually turned up in the retrieved pages. AI can suggest an option, but it cannot explain on our behalf why an audience should trust those particular results. As in design, the fundamentals help us do more than work faster: they help us notice when the result no longer solves the problem.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Perplexity представила Photon — поисковый движок для ИИ-агентов с задержкой от 160 мс habr.com

About the author

Lea Mayer

web design student

I’m studying in Germany and taking on my first small page design tasks. I’m still trying to figure out why one pixel shifts precisely after I’ve sent the mockup.

All posts by the author