Perplexity API Best Practices 2026
The Perplexity Sonar API is a search engine with a language model attached, and that changes how you run it in production. Billing has a per-request search component on top of tokens, freshness beats prompt engineering, and citations are the output your users actually trust.
Quick Reference
- →Status page:
status.perplexity.com - →Billing has two components — tokens plus a per-request search charge. Token-only cost models will understate your bill
- →Always render citations. They are the product differentiator and dropping them removes the reason to use Sonar over a plain LLM
- →Use search filters (recency, domain) instead of prompt instructions — filters are enforced, prompts are suggestions
- →429 = rate limit; limits are tighter than pure-LLM APIs because every request does retrieval work
- →Sonar is not a drop-in replacement for a chat model — it will search even when the answer needs no search
Perplexity Model Selection Guide
Model choice is the largest single lever on both cost and latency. Start at the bottom of this table and move up only when an eval on your own data shows the smaller option failing.
sonarBest for
Straightforward grounded Q&A where one retrieval pass is enough
Avoid when
Multi-hop research questions needing several search rounds
sonar-proBest for
Research-grade answers with deeper retrieval and more citations
Avoid when
High-volume paths — the per-request search component multiplies
sonar-reasoningBest for
Questions needing analysis across retrieved sources, not just extraction
Avoid when
Latency-sensitive UI — reasoning plus retrieval stacks two slow phases
Offline chat model (any provider)Best for
Anything that does not need current information — route it away from Sonar
Avoid when
Questions about recent events, prices, or availability
Your cost model needs a search term in it
Perplexity bills input tokens, output tokens, and a per-request search charge. Teams that forecast cost from token counts alone consistently underestimate, and the error grows with sonar-pro, which performs more retrievals per request. At high request volume the search component can exceed the token component entirely.
The direct consequence is that request count, not token count, is the metric to control. Caching identical or near-identical queries pays back faster here than on a pure-LLM API, because a cache hit avoids both the tokens and the search charge.
Route away from Sonar when the question is not a search question
Sonar retrieves on essentially every request. For a question the model could answer from parametric knowledge — formatting, rewriting, summarizing text you already supplied — that retrieval is pure cost and pure latency with no quality benefit.
The pattern that works is a cheap classifier in front: a small model decides whether the query needs current information, and only those requests go to Sonar. Everything else goes to a standard chat model. On mixed workloads this typically removes a large fraction of Sonar calls without any user-visible change.
Alert Pro
14-day free trialStop checking — get alerted instantly
Next time Perplexity goes down, you'll know in under 60 seconds — not when your users start complaining.
- Email alerts for Perplexity + 9 more APIs
- $0 due today for trial
- Cancel anytime — $9/mo after trial
Use filters, and always render citations
Sonar exposes structured search controls — recency windows and domain filters among them. Use them. An instruction in the prompt saying "only use sources from the last month" is a suggestion the retrieval layer may not honour; a recency filter is enforced. The same applies to restricting to a trusted domain set for regulated or high-stakes answers.
On the output side, render the citations. They are the reason to pay for Sonar rather than a cheaper chat model, they are what lets a user verify a claim, and stripping them for a cleaner UI converts a defensible grounded answer into an unattributable one. If your interface has no room for a source list, that is a signal Sonar is the wrong service for that surface.
Latency, errors, and monitoring
Sonar is slower than a pure LLM call because retrieval happens before generation, and sonar-reasoning stacks a second slow phase on top. Budget for it in UI design: stream the response, and show a retrieval state rather than a spinner, or the wait reads as a hang.
For errors, 429s arrive sooner than on pure-LLM APIs because each request does real retrieval work — back off with jitter and shape traffic client-side. Beyond availability, monitor citation count per response. A sudden drop to zero citations while requests still return HTTP 200 means retrieval is degraded, and that is invisible to a standard uptime check.
Production Checklist
Model cost as tokens plus search requests
The per-request search charge is a separate line. Token-only forecasts understate the bill, badly on sonar-pro.
Put a router in front of Sonar
A cheap classifier sends only current-information questions to Sonar. Everything else goes to a plain chat model.
Cache aggressively on query text
A cache hit avoids both tokens and the search charge, so caching pays back faster here than on pure-LLM APIs.
Use recency and domain filters, not prompts
Structured filters are enforced by the retrieval layer. Prompt instructions are suggestions.
Always render citations
They are the reason to pay for Sonar. Stripping them turns a grounded answer into an unattributable one.
Design the UI for retrieval latency
Stream output and show a retrieval state. A plain spinner on a two-phase request reads as a hang.
Alert on citation count, not just HTTP 200
Degraded retrieval returns successful responses with no sources. Uptime checks miss it entirely.
Pick sonar over sonar-pro by default
Sonar-pro performs more retrievals per request. Upgrade only where answer depth is measurably insufficient.
📡 Monitor your APIs — know when they go down before your users do
Better Stack checks uptime every 30 seconds with instant Slack, email & SMS alerts. Free tier available.
Affiliate link — we may earn a commission at no extra cost to you
FAQ
How is Perplexity Sonar API pricing different from other LLM APIs?
Sonar bills a per-request search charge on top of input and output tokens, because every request performs real retrieval before generation. Cost forecasts built from token counts alone consistently understate the bill, and the gap widens on sonar-pro, which performs more retrievals per request. At high volume the search component can exceed the token component, which makes request count — not token count — the primary metric to control.
When should I use Sonar instead of a regular chat model?
Only when the answer depends on current information. Sonar retrieves on essentially every request, so for formatting, rewriting, or summarizing text you already supplied, that retrieval adds cost and latency with no quality benefit. The production pattern is a cheap classifier in front: it decides whether a query needs current information, routes those to Sonar, and sends everything else to a standard chat model. On mixed workloads this removes a large fraction of Sonar calls.
Do I have to display Perplexity citations?
You should, for both product and trust reasons. Citations are the differentiator that justifies paying for Sonar over a cheaper chat model, and they are what lets a user verify a claim rather than take it on faith. Stripping them for a cleaner interface converts a defensible grounded answer into an unattributable one. If a surface genuinely has no room for a source list, that is a strong signal Sonar is the wrong service for it.
How do I restrict Perplexity to recent or trusted sources?
Use the structured search controls — recency windows and domain filters — rather than prompt instructions. A prompt saying "only use sources from the last month" is a suggestion the retrieval layer may not honour, while a recency filter is enforced before generation happens. For regulated or high-stakes answers, combine a recency window with a domain allowlist so the model can only ground its answer in sources you have vetted.
Why is my Perplexity API response slow?
Sonar runs retrieval before generation, so it is structurally slower than a pure LLM call, and sonar-reasoning stacks a reasoning phase on top of that. This is expected behaviour rather than a fault. Design for it: stream the response and show an explicit retrieval state instead of a generic spinner, since a two-phase request behind a plain loading indicator reads to users as a hang. If latency is unacceptable for a given surface, route that surface to a non-search model.