Sonar Reasoning Pro: Search Plus Reasoning, Mid-Migration

Most model guides are about what a model can do. This one is mostly about what it is turning into. Sonar Reasoning Pro is Perplexity's search-grounded reasoning model, and in 2026 Perplexity moved the whole Sonar line onto a different API. If you have the model id hard-coded somewhere, the thing answering your requests may not be the thing you originally tested.

That is not a reason to avoid it. It is a reason to understand what you are buying, how it is billed, and how to tell whether behaviour has shifted under you.

What the model is for

Sonar Reasoning Pro answers questions by searching the web, reading what it finds, reasoning over the results and returning an answer with citations. The search is part of the model call, not a tool you wire up yourself. You send a question; it decides what to look up.

Perplexity positions it for multi-hop work: questions where the first search does not contain the answer, only the clue to the next search. Its own migration documentation describes the job as multi-hop browsing and wide aggregation across many sources. That is the distinction from plain Sonar and Sonar Pro, which are better suited to single lookups and quick summaries. See the Sonar Pro guide for the cheaper non-reasoning tier, and the Sonar Deep Research guide for the exhaustive, slower end of the line.

OpenRouter's listing describes it as powered by DeepSeek R1 with chain-of-thought, and gives a 128K context window with text and image input. Treat the underlying-model claim as historical: the migration described below changes what serves the requests anyway.

The bill has two parts

Search-grounded models are priced differently from ordinary chat models, and this catches people out in budgeting. Perplexity's pricing page lists Sonar Reasoning Pro at $2 per million input tokens and $8 per million output tokens, plus a request fee per thousand calls that depends on the search context size you choose:

• Low search context: $6 per 1,000 requests
• Medium: $10 per 1,000 requests
• High: $14 per 1,000 requests

Those were the published rates at the time of writing, and OpenRouter lists the same token prices. The request fee is the part that matters for short questions. A query with a few hundred tokens of input and a modest answer can cost more in request fee than in tokens, so per-token comparisons against ordinary models are misleading. Work out cost per answered question instead.

Reasoning tokens count as output. A reasoning model that thinks at length before answering will spend more of the $8 rate than its visible answer suggests, so measure total output on real queries rather than estimating from answer length.

What changed on 27 September 2026

Perplexity's migration guide states that Sonar Chat Completions support ended on 27 September 2026. The Sonar models have been folded into its Agent API, which uses named presets rather than model ids. The guide maps Sonar Reasoning Pro to the low preset.

Three details from that guide are worth knowing:

• Synchronous and streaming requests still work. They are reformulated as Agent API requests, rolled out gradually by model. Your old call keeps returning answers, but what produces them is the preset.
• Asynchronous Sonar requests are no longer supported. They are not reformulated; they need moving to the Agent API's background mode.
• The preset is a different configuration. According to Perplexity's preset documentation, low runs a different underlying model with minimal reasoning effort, up to five steps, and web search plus single-URL fetch as tools.

Perplexity also removed the older sonar-reasoning model in December 2025 and pointed users at Sonar Reasoning Pro, so this is not the first consolidation in the line. The pattern is the one described in model deprecation and migration: a stable name, a moving implementation.

Migrating to the native API

If you call Perplexity directly, the native shape is worth adopting rather than relying on reformulation. The guide's mapping is mechanical:

endpoint:    /v1/agent  (responses.create instead of chat.completions.create)
messages  -> input
model     -> preset: "low"
max_tokens -> max_output_tokens
search_domain_filter, search_recency_filter -> web_search tool filters
search_context_size -> explicit max_tokens / max_tokens_per_page budgets

Two behavioural changes matter for parsers. Inline [n] citation markers stay in the answer text, but the sources come back as a separate output item of type search_results. In streams, reasoning and tool calls arrive as their own events rather than as inline text, so any code that stripped a thinking block out of the answer string needs rewriting.

The named search-context sizes have no direct equivalent. You set token budgets on the search tool instead, which is more precise but means your old low, medium and high cost tiers no longer map one-to-one.

How to tell whether it still suits you

Because the implementation may have changed after you integrated it, re-run whatever acceptance tests you had. If you never had any, build a small set now:

1. Collect twenty real questions your users asked, including several that needed two or three hops to answer.
2. For each, record the answer, every cited URL and whether each citation actually supports the sentence it is attached to.
3. Run the same set through the old model id and through the low preset directly, and compare citation accuracy, latency and total cost per answer.
4. Repeat monthly. A preset can be retuned without its name changing.

Citation accuracy is the metric to watch. A search model that cites a page which does not say what the answer claims is worse than one that cites nothing, because it borrows credibility it has not earned. LLM-powered search covers why retrieval quality, not model cleverness, usually decides this.

The practical takeaway

Use Sonar Reasoning Pro, or its preset successor, when the question needs live information and more than one search to answer. Do not use it for questions a model can answer from training data; you pay the request fee for nothing. If you depend on it in production, move to the native Agent API on your own schedule rather than leaving the reformulation to decide for you, and record which preset and date your evaluation covered, as you would when pinning a model version anywhere else.