Perplexity has introduced Photon, a Rust-based search engine that finds and ranks web pages before a language model assembles an answer based on them, and has released a Fast Search mode in its Search API based on this engine. The fast mode costs five times less than standard web search and responds with nearly the same quality: on agent benchmarks, the difference from the standard mode is measured in fractions of a percent, although internal relevance metrics have dropped slightly. It is enabled by a single API parameter, so the search step in your own agent can be made cheaper right now.

image
image

What happened

Perplexity announced the creation of Photon, a new Rust-based search engine that selects and ranks web pages at the stage preceding answer generation by a language model. Based on it, a Fast Search mode has been opened in the Search API: it is enabled by the value search_type: "fast" and costs $1.00 per 1,000 requests, compared to $5.00 for standard web search. According to the company, 95% of results are returned in 230 ms or faster, with a median of 160 ms. On six agent benchmarks—WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, and SEAL-Hard—the fast mode scored 64.3% compared to 64.0% for the standard mode, with an estimated cost of $59.73 versus $187.60. Simultaneously, Perplexity published internal relevance tests where metrics declined: DCG dropped from 2.45 to 2.21, and the share of queries for which an answer was found among the selected pages fell from 59.6% to 56.7%.

Context

Photon is notable not for scientific novelty but for its engineering assembly: Perplexity has packaged the classic arsenal of information retrieval—an inverted index with Elias-Fano compression, two-stage ranking, WAND traversal, asynchronous reading, CLOCK cache, and MapReduce index building—into a cheap and fast mode of a public API. The engine's index stores approximately 2.5 times more data per document but requires approximately 20% fewer servers, and the 99th percentile latency within Photon, according to published figures, decreased from approximately 800 to 65 ms. For understanding the event, it is important that all these mechanisms are standard tools of classic IR, which now work again as the base layer of LLM systems. The background also includes a rare practice of transparency for product releases: along with the benchmarks, the company published internal relevance metrics showing a decline.

Why this matters for the industry

For the industry, the main effect concerns the economics of the retrieval layer. The announced pricing moves web retrieval from one of the main cost items in the agent pipeline to cheap infrastructure and significantly lowers the barrier to entry for startups with search agents. The announced latencies allow running more search steps in interactive agent cycles without losing responsiveness. The announcement also sets a competitive benchmark: if the figures are confirmed in real pipelines, other search APIs will have to respond with price and latency, and the division into "fast and cheap" and "maximum quality" modes may become a standard industry interface. A likely working pattern is two-level retrieval, where fast serves the hot path and fan-out, while standard web search remains for deep research scenarios, with a classifier selecting the mode based on query complexity. Within a two-year horizon, the retrieval layer is moving toward commoditization: competition shifts to index freshness, data coverage, and ranking quality for specific agent scenarios, while value moves up to domain ranking, agent memory, orchestration, and the product layer.

Why this matters for users

For those building agents on the Perplexity Search API, the fast mode is already available: it is enough to pass the parameter search_type: "fast"; in Python SDK versions 0.43.4 and 0.43.5, it is set via extra_body, and max_results accepts values from 1 to 20. The agent's hot path can be switched to fast today to reduce search call costs, leaving standard web search for complex questions where maximum relevance of results is important. A reasonable first step is to run both modes in a shadow test or A/B experiment on your own traffic: compare relevance on a sample of real queries and measure actual savings, rather than relying only on the figures from the announcement.

What is currently unknown / limitations

The difference of 64.3% versus 64.0% on six benchmarks is small and may fall within the bounds that ordinary measurement noise can produce. The published materials do not include the number of runs, confidence intervals, or a breakdown of results for each of the six agent benchmarks, so it is unknown exactly where the fast mode wins and where it loses. All key figures are provided by the vendor itself: there is no independent reproduction yet, and the disclosure of internal metrics with a decline, while a good signal of transparency in itself, does not replace it. It is also undisclosed on which types of queries and domains the drop in DCG and query coverage by answer is most pronounced.

Sources

Author

Look at AI, editorial team