Sonar Pro Search: Multi-Step Search Priced per Call

A single web search answers most questions. The ones it does not answer are the expensive ones: a question whose answer depends on a fact you only learn from the first result, or one where the top pages disagree and somebody has to go and check. A one-pass search model handles those badly, and it does not tell you it handled them badly.

Sonar Pro Search is Perplexity's answer to that class of question. OpenRouter listed it on 30 October 2025 and its listing describes it as exclusive to the OpenRouter API and as Perplexity's most advanced agentic search system, designed for deeper reasoning and analysis. This guide covers what you are paying for and how to find out whether your questions need it.

What it is, relative to Sonar Pro

Underneath, this is Sonar Pro running in Pro Search mode. Perplexity made Pro Search generally available for Sonar Pro on its own API in November 2025; on OpenRouter, the mode is packaged as a separate model id, perplexity/sonar-pro-search, so you choose it by name rather than by a request parameter.

The difference is the search loop. Plain Sonar Pro retrieves once and answers. Pro Search is agentic: it can search, read, decide what is missing and search again before answering. That is the whole value, and also the whole cost.

The listing details at the time of writing: text and image input, a 200,000-token context, an 8,000-token maximum output, reasoning that cannot be switched off, and support for structured outputs.

The per-call fee is the number to watch

OpenRouter lists Sonar Pro Search at $3 per million input tokens and $15 per million output, the same token rates as Sonar Pro. The difference is the search charge: $0.018 per request, against $0.005 for Sonar Pro on the same listing. That is $18 per thousand calls before a single token is counted.

Because reasoning is mandatory, each answer also carries reasoning tokens, which are typically billed as output. An illustrative thousand-call run, assuming 3,000 input and 600 output tokens per call including reasoning, comes to about $9 of input, $9 of output and $18 of search fees. On those assumptions the search fee is half the bill, and the total is roughly one and a half times what the same traffic costs on Sonar Pro.

Those per-call figures are assumptions, not measurements. Read the usage block on real responses, because a multi-step search can pull in far more context than a one-pass one. Agent cost control patterns applies here: it is an agent, and it should be budgeted like one.

Structured outputs are the quiet differentiator

On OpenRouter, Sonar Pro Search accepts structured_outputs; the plain Sonar and Sonar Pro listings do not. If you are feeding search results into a pipeline rather than a chat window, that matters more than the extra search depth.

A research step that returns a JSON object, with a claim, a confidence field and the source URLs that support it, can be validated, stored and diffed. A paragraph of prose cannot, at least not reliably. Define the schema first, and make the source list a required field so an answer without evidence fails validation instead of slipping through. Best model for structured output covers the schema design side.

When multi-step search pays

Multi-step search earns its fee on a recognisable set of questions:

• Multi-hop: "Which company acquired the startup that built X, and what did it pay?" needs the first answer to form the second query.
• Conflicting sources: prices, specifications and dates that differ between pages and need a tie-breaker.
• Thin first pages: niche topics where the top results are aggregators that do not contain the fact.

It does not pay on single-fact lookups, definitions or anything already in the first result. There, it charges more and adds latency, since each extra search step is wall-clock time. For a user waiting on an answer, that latency is part of the cost too.

If you need a long, sourced report rather than a precise answer, the 8,000-token output cap is the limit you will hit, and Sonar Deep Research is built for that job instead.

Routing rather than defaulting

The economical pattern is not to choose Pro Search for everything. Send questions to Sonar or Sonar Pro first, and escalate to Pro Search when the first answer is weak: no supporting citation, a low self-reported confidence in your schema, or a question type you have learned fails on one pass. Model routing and fallbacks covers escalation rules.

One forward-looking caution. Perplexity says its Sonar Chat Completions support ended on 27 September 2026, with requests moving onto its Agent API, where multi-step search is offered as presets. Its docs do not say how that affects OpenRouter's Pro Search id. Keep a fixed set of test questions and rerun them periodically so a behaviour change shows up in your numbers before it shows up in complaints.

A test that answers the question

1. Run 50 real questions through Sonar Pro and keep the ones it gets wrong or cannot source.
2. Rerun only those through Sonar Pro Search.
3. Count how many it fixes, and divide the extra cost by that number.

That figure, extra cost per rescued answer, is the one to put in front of whoever approves the budget.