Perplexity has introduced Fast Search, a lower-cost API option that retrieves ranked web results in 230 milliseconds at the 95th percentile, powered by a new retrieval engine called Photon built in Rust. The speed improvement addresses a critical bottleneck for AI agents that perform dozens of searches in sequence, where even modest delays accumulate into noticeable slowdowns.

Why Speed Matters for AI Agents Doing Research

When an AI assistant performs a single search, the delay is barely noticeable. But when an agent needs to compare products, verify claims, gather sources, and write a report, it may search dozens of times. Each search call takes time, and each call costs money. For developers building research agents, those small pauses add up quickly.

Imagine a company asking an AI agent to identify potential suppliers in three countries. One search finds names. Later searches check each supplier's products, locations, and recent announcements. A final pass looks for evidence that the details are still current. If the agent performs 30 searches one after another, even a modest delay on each call accumulates significantly. Faster retrieval gives the agent more time to reason over results, or simply gives its user an answer sooner.

Perplexity positions Fast Search for frequent calls inside agent workflows and other applications that prioritize response time. The company's developer guidance points builders toward standard search for difficult or ambiguous questions, suggesting that developers should choose between speed and a more thorough search path.

How Photon Rebuilds Search Infrastructure from the Ground Up

Fast Search is the feature developers can choose. Photon is the machinery making it possible. Perplexity previously adapted an open-source search engine for its retrieval and ranking work, but as its index and workloads grew, the company ran into limits involving cost, slow responses at the high end of the latency range, and the time needed to recover or expand serving nodes. The company built Photon to gain more control over those parts of the system.

Retrieval and ranking have different jobs. Retrieval finds pages that might help answer a question. Ranking sorts the candidates so the most useful ones rise toward the top. An AI model can then use those pages to support its response. Photon now powers both of these functions in Perplexity's search pipeline.

The engineering improvements behind Photon address unglamorous but critical problems. To rank search results, the system may need information about many documents stored in different places. Perplexity's previous approach could leave a processing thread waiting when required data was not already in memory. Repeat that across enough records, and the waits start to stack up.

Photon checks a batch of needed records against its cache, uses the records it already has, and sends missing reads to disk together. Those reads can happen while other reads are still pending, rather than forming a slow queue. Perplexity uses Linux's io_uring mechanism to manage that work. Think of ordering food for a group: you would not wait for one person's meal to arrive before placing the next person's order. You would send the orders together and collect them as they become ready.

What the Performance Numbers Actually Show

In Perplexity's measurements, a Fast Search call took 160 milliseconds at the median and 230 milliseconds at the 95th percentile. In plain English, 95% of the measured calls finished within 230 milliseconds. This engineering change is most relevant to the slower requests that users notice. After the migration to Photon, Perplexity's 99th-percentile retrieval-and-ranking latency fell from roughly 800 milliseconds to 65 milliseconds. That measures an internal stage, not the entire end-to-end API call.

The full wait for a complete research report also includes network travel, any page fetching, model processing, and application code. A 230-millisecond search figure does not promise a complete research report in 230 milliseconds. However, for developers building agents that make repeated searches, the cumulative time savings are substantial.

How Photon Handles Index Updates Without Slowing Live Searches

Search infrastructure has another moving part: the index keeps changing. Pages appear, disappear, and get updated. A search service has to prepare fresh index data while continuing to answer requests. Perplexity's old setup coupled some index-building work to the machines serving live searches. Recovering a failed node or adding another copy of the data could require reindexing in place, a process the company says sometimes took days. That also put maintenance work in competition with user queries.

Photon separates those jobs. Indexers prepare new, versioned structures on different machines. Serving nodes can attach a ready version when it is time to use it. Before Perplexity sends live traffic to an updated serving group, the system replays real queries to warm the caches. This separation means maintenance no longer competes with user-facing performance.

Steps for Developers to Use Fast Search in Their Applications

• Enable Fast Search: Developers select Fast Search by setting search_type to "fast" in a Search API request. If they leave that setting out, the request uses standard web search.
• Compare Results Across Both Options: Both Fast Search and standard search return results in the same response format, making comparison straightforward. Developers can run a representative set of searches through each option, then check the answers their application ultimately produces.
• Choose Based on Your Use Case: Use Fast Search for frequent calls inside agent workflows and applications that care about response time. Use standard search for difficult or ambiguous questions that require more thorough retrieval.

What This Means for the Broader AI Search Landscape

Perplexity's infrastructure improvements reflect a broader shift in how AI companies are optimizing for real-world use cases. As AI agents become more capable at multi-step reasoning and research tasks, the speed of individual search calls becomes a bottleneck worth engineering around. The move to a custom-built search engine in Rust signals that Perplexity sees search performance as a core competitive advantage.

The distinction between Fast Search and standard search also matters for how developers think about AI-powered applications. Rather than treating search as a monolithic operation, developers can now optimize for their specific needs. An agent doing rapid fact-checking might use Fast Search for speed. An agent answering a complex question might use standard search for depth. This flexibility reflects the maturation of AI agent development as a discipline.

None of this will appear as a shiny new button in a consumer chat window. That is part of the point. Good infrastructure tends to disappear into the experience when it works. But for developers building the next generation of AI agents, the ability to perform dozens of searches without noticeable delay could be the difference between a sluggish assistant and one that feels responsive and capable.