All Perplexity (Sonar) models available through the API

Use the current Sonar catalog with its announced migration timeline, and distinguish it from Perplexity’s newer product catalogs. Select a model or preset by the evidence and output your application needs.

Model families at Perplexity

The Sonar catalog distinguishes sonar, sonar-pro, sonar-reasoning-pro and sonar-deep-research. Their official references describe search, more extensive research and reasoning-oriented use cases. Use the live metadata and rates below for numeric comparisons. Official Perplexity documentation.

The official Sonar documentation states that Sonar support continues until September 27, 2026 and directs developers to the Agent API migration guide. Official Perplexity documentation.

The broader Perplexity platform now documents Router, Agent, Search and Embeddings separately. A Sonar model name, an Agent preset and a Router model identifier are different configuration choices. Begin with the product that returns the artifact your application needs, then inspect its available models or presets rather than assembling a universal selector from unrelated names. Official Perplexity documentation.

For a cited-answer application, define what counts as acceptable evidence. A concise explanation with a relevant primary source can be better than a longer answer with weak support. For a research report, require coverage of the actual question and make uncertainty visible. Include a fixture where sources disagree so the application demonstrates how it presents that conflict.

All models

The live table tracks the supported Sonar catalog. It is not a complete list of models available through every Perplexity product. Follow the relevant official Router or Agent catalog when selecting those interfaces, and keep the selected endpoint next to the identifier in configuration.

Use exact identifiers rather than turning display names into request values. If the application presents a human-readable label, store the accepted API value separately. When a saved selection becomes unavailable, show a clear migration state instead of silently substituting a different model whose evidence or billing behavior may differ.

For existing Sonar integrations, save the accepted response shape, citation mapping and search controls before making changes. Keep safe examples of both successful and incomplete tasks. Those fixtures become the basis for migration testing, and they help explain whether a new result differs because of the product, the prompt or the selected configuration.

Cheapest / strongest / longest-context

A rate ranking can compare the tracked models under stated conditions; it does not establish research quality or latency. Use the AI API cost calculator for supported token assumptions and retain request-related charges separately. A unit-price comparison is meaningful only if the route and charge categories match.

For a cheapest candidate, measure the complete accepted answer. Include correction turns and any additional calls the application needs to verify or repair output. A lower initial rate can still produce a more expensive accepted task when the first response does not meet the requirement. Keep the acceptance criterion fixed across the comparison.

For a strongest research candidate, assess whether the returned evidence supports the key claims, whether the question is actually answered and how missing information is handled. Preserve the output and safe source list for review. Do not rank strength solely by a family suffix or the amount of text generated.

For longest-context work, test the actual supplied material and how the application combines it with retrieved evidence. A larger window is a capacity property, not a guarantee that every relevant passage will be used correctly. Define the expected factual relationships and check the resulting answer against them.

If evaluating Agent presets during migration, use the official mapping as a starting point and then run the same fixtures. The mapping identifies an intended replacement path; your evaluation establishes whether that path preserves the behavior your users need. Official Perplexity documentation.

Keep evidence review consistent across candidates. Choose the same safe questions, define which primary sources would establish the answer and record missing or contradictory information. If a configuration returns more sources, inspect whether those sources contribute relevant support rather than rewarding the count alone. Preserve the final answer and the source mapping so a reviewer can follow the same reasoning about acceptance. When the web changes between runs, record that limitation and avoid attributing every difference to the model. Repeat only the affected comparison when new evidence or a configuration change makes the original result insufficient.

For a documentation assistant, include a version-specific fixture and an example that asks about a feature no longer supported. Those cases reveal whether the application identifies the relevant version and handles an obsolete premise. A generic question about the same technology can pass while leaving those practical failure modes undiscovered.

Deprecations and replacements

The Sonar support notice makes replacement planning an immediate part of model selection. Follow the official Agent migration reference for the request and response changes. Do not assume that a model identifier can be changed while leaving every parser, filter and background-job handler untouched. Official Perplexity documentation.

Create a migration checklist around observable behavior: request construction, answer extraction, citation display, completion state, safe error handling and usage accounting. Run it against the existing Sonar fixture and the proposed Agent configuration. Preserve both outputs so a reviewer can assess the practical differences rather than only seeing that each route returned HTTP success.

Plan rollback according to actual service availability. After a product is retired, a configuration flag pointing at the old endpoint may no longer be a useful recovery route. Keep the previous fixture for comparison, but maintain a current supported alternative and a clear application failure state. Read Perplexity errors and product admission rules as part of that plan.

Naming and versions

Treat the product name as part of the request identity. Sonar Chat Completions and Agent responses have different output contracts, while Router uses its own model catalog. Save the exact configuration with completed task records so later reviews can establish which route was requested.

Pin the model or preset that your evaluation actually covered and review official change notices before switching. Do not make a public strongest-model claim from a provider’s naming convention alone. Explain the measured acceptance criteria and preserve the limitations of the comparison, especially when search sources can change between runs.

Follow Perplexity project key setup and the current Python tutorial after selection. Review Perplexity billing by product before expanding the workload. Return to the Perplexity API hub for current source links and service context, keeping model choice connected to a reproducible application task.

Frequently asked questions

Sources

• Sonar catalog and notice ↗
• Current platform products ↗
• Migration mapping ↗
• Sonar features ↗
• Product pricing ↗

Last verified 12 Sep 2026 · Source ↗