Kingy AI
Work with Kingy
AI News

Perplexity Gives Developers a Faster Way to Search the Web

September 25, 2026 AI News
Perplexity Fast Search

The small pause that grows into a long wait

Ask an AI assistant one question and it may search the web once. Ask it to compare products, check claims, gather sources and write a report, and it may search dozens of times. Each call takes time. Each call costs money. Those little pauses can become the longest part of the job.

Perplexity wants to shrink them. The company has introduced Fast Search, a lower-cost option for developers using its Search API. It runs on Photon, a new retrieval and ranking engine that Perplexity built in Rust. In the company’s measurements, a Fast Search call took 160 milliseconds at the median and 230 milliseconds at the 95th percentile. In plain English, Perplexity says 95% of the measured calls finished within 230 milliseconds.

That sounds like a blink. For an AI agent making repeated searches, it could feel more like removing a string of red lights from a trip across town.

A date correction: I placed this story in the previous roundup’s 24-hour window. Perplexity dates both its Photon research post and its Fast Search announcement 24 September 2026, so that placement was incorrect.

First, what is actually new?

Perplexity did not just launch its Search API. It introduced that API in September 2025, giving developers a way to request ranked web results for their own applications. Fast Search is a new option within that existing product.

That distinction matters. Imagine a developer building an assistant that tracks a fast-moving industry. The assistant can ask the Search API for relevant pages, then pass the results to an AI model that reads and reasons over them. The API supplies the search results; the developer’s application decides what to do next. The original Search API announcement described results such as titles, links, snippets and dates, without generating a finished AI answer itself.

Fast Search changes the search leg of that journey. Developers select it by setting search_type to "fast" in a Search API request. If they leave that setting out, the request uses standard web search. Perplexity says both options return results in the same response format. That should make comparison straightforward: run a representative set of searches through each option, then check the answers an application ultimately produces.

Why AI agents care about milliseconds

A person can skim a page and decide what to read next. An AI research agent may turn that process into a loop: search, inspect results, refine the query, search again, compare sources, then pursue a lead it found halfway through.

Here is a hypothetical example. A company asks an 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. The work grows quickly.

If an agent performs 30 searches one after another, even a modest delay on each call accumulates. Faster retrieval can give the agent more time to reason, or simply give its user an answer sooner. In practice, the full wait 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.

Perplexity positions Fast Search for frequent calls inside agent workflows and other applications that care about response time. Its developer guidance points developers toward standard search for difficult or ambiguous questions. That is a useful clue: the company expects builders to choose between speed and a more thorough search path.

Meet Photon, the engine beneath the switch

Fast Search is the feature developers can choose. Photon is the machinery making it possible.

In its technical account, Perplexity says it previously adapted an open-source search engine for its retrieval and ranking work. 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. It 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.

Picture a librarian handling a request about a little-known topic. Finding every potentially relevant book is the first challenge. Putting the best ones on the desk first is the second. Photon works on those behind-the-scenes steps; it is not itself the assistant writing the final answer.

Perplexity says Photon now powers retrieval and ranking in its search pipeline, with Fast Search built on top. The news, then, reaches beyond a single API setting: the company has replaced a core piece of its search infrastructure.

A search request takes a short tour

Perplexity’s description of Photon gives developers a look at where the time goes. A search request reaches a broker, which sends work to a group of shards. Each shard handles part of the index, retrieves candidates and ranks them. The broker combines the candidates, obtains details for selected pages and sends the results onward.

The word “shard” sounds dramatic. Here, it simply means a portion of a much larger collection. Splitting an index lets multiple machines tackle a search at once instead of asking one machine to rummage through everything.

Photon also avoids reading more document data than a query needs. Perplexity says its compact formats let the engine pull relevant pieces efficiently while storing about 2.5 times as much data per document as the earlier system. That extra room can give ranking access to richer information, according to the company. It does not mean the public API suddenly returns 2.5 times as much text. (perplexity.ai)

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.

The trick with waiting for a disk

Perplexity Fast Search

One of Photon’s more interesting changes tackles an unglamorous problem: waiting for data.

To rank search results, the system may need information about many documents stored in different places. Perplexity says its 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. It 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 tidy but slow queue. Perplexity says it 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. The comparison is imperfect, but it captures why overlapping waits can help.

This engineering change is most relevant to the slower requests that users notice. Perplexity reports that, after the migration to Photon, its 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.

Updating an index without getting in the way

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 says its 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, it says the system replays real queries to warm the caches.

The kitchen analogy practically writes itself: prepare the ingredients away from the service counter, then bring out a ready tray. Customers do not need to watch someone chop vegetables while their order sits there.

Perplexity reports using about 20% fewer equivalent serving machines than the old system’s content nodes. That is a comparison of a particular part of its infrastructure. It is not a claim that the company’s total computing use, electricity bill or environmental footprint fell by 20%.

The price drop developers can calculate

Here is the easiest number to carry away from the launch: Perplexity lists Fast Search at $1 per 1,000 successful Search API requests, compared with $5 per 1,000 for standard web search. At those listed rates, 100,000 successful requests would cost $100 with Fast Search or $500 with the standard option.

That calculation covers the Search API requests. It does not include the price of any separate AI model a developer uses to read results and produce an answer.

Perplexity’s pricing documentation says a successful request counts as one billing unit even when it contains an array of up to five queries. It also says there are no additional token charges for the Search API itself. Invalid requests, requests rejected by rate limits and upstream failures are not billed; a successful request still counts if it returns no results.

There is a separate way to use Fast Search inside Perplexity’s Agent API. Its listed search-tool charge is $0.001 per Fast Search invocation, and model tokens are billed separately. Developers should check which product their application actually calls before multiplying a price by expected traffic. A cheap search call can still be part of a more expensive AI task.

The 68% figure needs its own label

Perplexity also reports a 68% reduction in estimated model-plus-search cost across a set of agent benchmarks. That figure sounds similar to the API price cut, but it measures something different.

The company compared its default and fast search options across 3,554 selected tasks drawn from six benchmarks. It reports an aggregate task score of 64.3% for Fast Search at an estimated total cost of $59.73, versus 64.0% for its default option at $187.60. Those dollar amounts refer to the selected benchmark tasks, including estimated model and search costs. They are not subscription prices or a promise that every customer’s bill will fall by 68%.

Perplexity names the six evaluations as WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 and SEAL-Hard. Its result suggests Fast Search can preserve overall task performance while spending less in the workflows it tested.

It remains a company-run comparison. Perplexity also warns that latency numbers reported by different search providers do not all use the same measurement setups or even the same high-end percentiles. A developer deciding where to route production traffic should test real queries, at real volumes, against the results their users need.

Faster can mean leaving something behind

Perplexity’s own results show why the standard option still exists. In internal tests covering difficult searches, broad coverage and result diversity, Fast Search scored lower than its default setting. Reported relevance fell from 2.45 to 2.21 on the company’s measure. Answer availability fell from 0.596 to 0.567, a difference of 2.9 percentage points.

Those are narrower retrieval-quality measures, not the same thing as the aggregate agent scores from the six-benchmark comparison. Both can be true: an agent may finish a tested task at about the same rate, while the fast search path sometimes surfaces a less helpful set of results.

Suppose an assistant needs the current opening hours of a popular museum. A quick search may be plenty. Now suppose it must determine whether a little-known research claim has been independently reproduced. The cost of missing an obscure source rises. Spending more time on retrieval starts to look sensible.

That is why the Fast Search documentation recommends the standard setting for rare, difficult or ambiguous questions. A practical application could start with fast search and use standard search when the first results leave uncertainty. That would be a developer’s design choice, not an automatic behavior Perplexity has promised for every application.

One setting, with a few developer wrinkles

Developers can request Fast Search by sending search_type: "fast" to POST /search. Perplexity says the response keeps the standard search format, so a team does not need a different result parser solely for this setting. Fast Search accepts between one and 20 results per request.

There is a small catch for teams using Perplexity’s software libraries. At the time of the published guidance, the company says Python library versions 0.43.4 and 0.43.5 reject "fast" when developers pass it directly as the search_type argument. The documented workaround puts it in extra_body. Its TypeScript example uses a type cast because that SDK’s types do not yet include the new value. A direct API request can specify the setting in its request body.

It is the sort of detail that can turn a five-minute trial into a puzzling afternoon if nobody mentions it. It also shows why launch documentation matters as much as a benchmark chart.

For teams considering a switch, the test is concrete: compare search-call times, examine the returned sources, check the agent’s final answers and calculate the full cost per completed task. The fastest individual call wins little if the agent has to run three extra searches to repair a weak result.

What this launch is really testing

Perplexity Fast Search

Fast Search gives developers a more explicit choice. They can pay less for a quicker search path when their application makes frequent calls, and retain the standard path when a question demands broader or more careful retrieval. Photon gives Perplexity more control over the infrastructure supporting both.

The reported gains are striking, particularly the median and 95th-percentile API timings and the lower estimated cost in Perplexity’s benchmark tasks. The reported losses in narrower retrieval-quality tests deserve just as much attention. Together, they describe a product with a purpose, not a magic setting that improves every search.

The next meaningful evidence will come from applications using it: whether research agents finish sooner, whether their source lists hold up, and whether the total bill falls once model use and repeat searches are included. Until then, the strongest verified description is straightforward. Perplexity has launched a faster, cheaper Search API option, documented how to use it, and published company-run measurements showing both its advantages and its trade-offs.

Sources