Research-backed calculator guide
Perplexity API Cost by Product: Search Requests, Agent Tools and Orchestrator Tokens
Compare Perplexity Search API, Agent API, and Orchestrator API billing units with a worked cost ledger for requests, tools, sessions, and tokens.
Quick answer
Perplexity API Search vs Agent pricing is not one rate-card question. The Search API charges per successful search request: the official pricing page lists $5 per 1,000 standard requests and $1 per 1,000 Fast Search requests. The response is ranked web data rather than a generated answer, and a single successful request can contain an array of up to five queries. [1] [4]
The Agent API adds a model-token meter to tool meters. Its standard web_search tool is listed at $0.0025 per invocation, Fast Search inside the tool is $0.001, and fetch_url is $0.0005 per invocation. A sandbox session is $0.03 per session, with SDK search queries made inside that session billed separately. Those tool charges sit on top of the selected model's input, cached-input, and output-token rates. [1]
The Orchestrator API is different again: it is token-priced at the requested model's rates and has no per-request fee. Therefore, choose Search when your application will rank or synthesize raw retrieval itself, Agent when you want Perplexity to manage a tool-using loop, and Orchestrator when you need model choice without a Search API request or Agent tool layer. The answer is a classification rule, not a promise that one product will always be cheaper.
Prices and product behavior in this guide are checked against the cited pages on November 2, 2026. Verify the live rate card before committing budget because provider pricing, models, tool menus, and access requirements can change.
What the three products actually meter
Search API: one successful request is the main unit
The Search API is raw retrieval. Its quickstart describes ranked results with titles, URLs, and extracted page text, with no generated answer. That makes it a good fit when your own application will deduplicate results, apply a domain policy, pass selected passages to a model, or store search evidence for later review. [4]
For standard Search API traffic, the pricing page gives a simple formula:
successful requests / 1,000 × $5.00
At that rate, 1,000 successful requests cost $5 and 10,000 cost $50. The billing unit is the successful POST /search request, not each query string inside it. If one request contains five queries and succeeds, it is still one Search API billing unit. A successful response that returns no results is still billed; invalid, rate-limited, and upstream-failed requests are not billed according to the same page. [1]
Fast Search changes the rate, not the accounting concept. The Fast Search documentation lists $1 per 1,000 requests and says it uses the same response format as standard Search API. It also warns that Fast Search is a Search API search_type, not the Agent API's fast effort level. [3] Treat those as separate fields in your usage export.
Agent API: model tokens plus the tools the loop uses
The Agent API is a managed runtime rather than just a search endpoint. Its documentation describes a unified interface for models, reasoning, web search, tool configuration, and token budgets. Web search is opt-in: a request with only a model and input does not automatically imply a web-search tool charge. [2]
An Agent request can therefore have several independent rows in your ledger:
- Input tokens, including prompt and conversation content, priced at the selected model's input rate.
- Cached input tokens, if the model has a cache-read rate.
- Output tokens, including reasoning tokens where the model's usage reporting bills them at the output rate.
- Tool invocations, such as
web_search,fetch_url, image search, people search, or finance search. - Sandbox sessions, when code execution is enabled.
- Search queries issued by an SDK from inside a sandbox session.
The official rate card lists standard web_search at $0.0025 per invocation, Fast Search at $0.001, and fetch_url at $0.0005. The sandbox rate is $0.03 per session, not $0.03 per line of code or per minute of wall-clock runtime. The page describes a session as a 20-minute active-use billing window and separately bills SDK search queries made within it. [1]
This is why “cost per Agent API call” is an incomplete metric. Two calls with the same prompt can have different totals if one makes two searches and fetches a page while the other uses no tools. The response usage object can report calculated cost when present, but your own ledger should still retain the model, tool, session, and request identifiers so finance can reconcile a total to an invoice.
Orchestrator API: token accounting without a request fee
The Orchestrator API is intended for model choice and routing across supported models. The official pricing page says it bills per token at each model's published rates and has no per-request fees. Input, cached input, output, and reasoning-token treatment therefore depend on the selected model's rate card. [1]
Do not copy a Search API request price into an Orchestrator forecast. Conversely, do not call a Search API request “free of token cost” and then forget that your downstream model, if you add one, has its own token bill. Product-level selection should follow the actual workflow boundary:
- Raw retrieval only: count successful Search or Fast Search requests.
- Retrieval plus managed research: count Agent tokens and every tool or session meter.
- Model routing or model completion without the Search API: count Orchestrator tokens at the requested model's rates.
- A mixed pipeline: keep each product's rows separate, then add them only at the workflow or customer level.
Worked cost example: Search and Agent cost ledger
The following table is a deliberately inspectable visual. It uses vendor-published request and tool prices where available. It does not invent a model rate: token costs are left as a variable because the selected Agent or Orchestrator model determines them.
| Step | Assumption or input | Billing formula | Output for the example | Meter to store |
|---|---|---|---|---|
| 1. Standard Search API | 2,000 successful requests | 2,000 / 1,000 × $5.00 | $10.00 | search_successful_requests |
| 2. Fast Search API | 2,000 successful Fast Search requests | 2,000 / 1,000 × $1.00 | $2.00 | fast_search_successful_requests |
| 3. Agent web search | 1,000 Agent requests, one standard web_search each | 1,000 × $0.0025 | $2.50 | agent_web_search_invocations |
| 4. Agent URL fetch | 1,000 Agent requests, one fetch_url each | 1,000 × $0.0005 | $0.50 | agent_fetch_url_invocations |
| 5. Agent sandbox | 1 sandbox session per Agent request | 1,000 × $0.03 | $30.00 | sandbox_sessions |
| 6. Sandbox SDK searches | 3 SDK search queries per session | 3,000 × $0.0025 | $7.50 | sandbox_sdk_searches |
| 7. Agent model tokens | 1,000 requests; I input and O output tokens per request | (1,000I × input_rate + 1,000O × output_rate) / 1,000,000 | Variable; add to $40.50 | input, cache-read, output, reasoning tokens |
The fixed Agent tool subtotal in this scenario is $40.50 before model tokens: $2.50 + $0.50 + $30.00 + $7.50. If the workflow does not use a sandbox, remove both the session line and the SDK-search line. If it uses Fast Search as the Agent web_search mode, replace $2.50 with $1.00 for 1,000 tool invocations. Do not add a Search API request line unless the application separately calls POST /search; an Agent tool call is not automatically the same billing event as a standalone Search API request.
A simple monthly extension is just multiplication by the number of identical batches. For example, ten batches of 2,000 standard Search API requests total 20,000 successful requests and $100 at the published $5-per-1,000 rate. This is a vendor-rate calculation, not a traffic forecast. It assumes every counted request succeeds and that the rate remains unchanged for the period.
For token rows, use the model's live published input, cache-read, and output prices. If a request has 1,200 input tokens and 800 output tokens, the token component is:
(1,200 × input_rate + 800 × output_rate) / 1,000,000
If a portion of the 1,200 input tokens is cache-read, split it into ordinary input and cached input before applying rates. If the provider reports reasoning tokens and the selected model bills them at output rates, include them in the output-side usage rather than treating the visible answer as the entire bill. The arithmetic is general; the rate values must come from the model selected at the time of the request.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
How to choose Search versus Agent in practice
Start with the output contract rather than the product name. If your application needs a list of URLs, snippets, dates, or extracted content and your own model will decide what to say, Search API is the cleanest boundary. Its response format and request meter make a retrieval budget easy to isolate. Fast Search is a lower-cost option when lower latency and routine retrieval matter, but it is still a search request meter, not a free add-on. [3] [4]
Choose Agent when the value is in the loop. An Agent can decide whether to search, fetch a URL, call a custom function, or execute code. The Agent API announcement describes this as retrieval, tool execution, reasoning, and model orchestration in one managed runtime. [2] That convenience can reduce the amount of orchestration code your team owns, but it also makes cost depend on what the loop actually does. Budget from observed distributions such as searches per request, fetched pages per request, and sandbox sessions per successful task. A single average is often not enough; keep at least median and high-percentile tool counts for guardrails.
Use Orchestrator where the primary decision is which model should answer or route the workload. Its pricing is token-based, so estimate prompt size, cached reuse, output length, and reasoning behavior rather than counting web requests. If the surrounding workflow later adds Search or Agent, append those as separate product lines. The API Platform page also presents Agent, Search, and Orchestrator as composable primitives, so a mixed architecture is possible; composability is not a reason to collapse meters into one “API call” field. [1]
For a broader token worksheet, see the AI token cost calculator. For multi-provider comparisons, use the Model pricing comparison calculator. When actual provider usage arrives, reconcile estimates against invoice rows with the AI API invoice reconciliation calculator. These links are useful because the Perplexity question has two dimensions: product meter selection and token-rate arithmetic.
Common budgeting errors
The first error is comparing $5 per 1,000 Search API requests with an Agent request total that excludes tokens. Those are not equivalent units. Normalize to a completed workflow, such as one research task, and include the number of search, fetch, sandbox, and token events needed to complete it.
The second error is counting queries instead of successful requests. A Search API request can contain multiple queries, while failures and rate-limited requests have different billing treatment. Store request status and query-array length so a finance reviewer can see why query volume and billed request volume differ. [1]
The third error is treating Fast Search as a model effort setting. The official documentation explicitly separates Search API search_type: "fast" from Agent effort levels. Keep search_type, effort, and service_tier as different fields in your event schema. [3]
The fourth error is assuming the Agent loop will make a fixed number of calls. Tool use is conditional. Instrument each invocation, session, and SDK search, then use your own measured counts for forecasts. A tool price is a vendor quote; an estimate of monthly tool volume is your assumption.
The fifth error is mixing consumer subscriptions with API spend. A chat subscription, if applicable to your organization, is not a substitute for a product-level API ledger. This guide covers API usage only. Subscription fees, taxes, credits, payment processing, and any contract-specific enterprise terms are excluded unless they appear in a separate approved budget line.
FAQ
Is Perplexity Search API cheaper than Agent API?
Not as a universal rule. Search API has a clear per-successful-request price, while Agent combines model tokens with tool and possibly sandbox charges. A Search API request can be cheaper for raw retrieval, but a fair comparison must include the model and application work needed after retrieval. An Agent can be operationally simpler while costing more or less depending on model choice and tool behavior.
What is the Perplexity Search API cost per request?
The published standard rate is $5 per 1,000 successful requests, or $0.005 per successful request. Fast Search is listed at $1 per 1,000, or $0.001 per successful request. The rate is per successful POST /search request, not per individual query string in a multi-query request. [1] [3]
Does Agent API web search include token pricing?
No. Agent web-search tool fees are separate from model token costs. The rate card lists standard web_search at $0.0025 per invocation and Fast Search at $0.001 per invocation. Add input, cached-input, output, and applicable reasoning-token costs for the selected model. [1]
Does an Agent sandbox cost per search?
The sandbox has a session meter. The official pricing page lists $0.03 per session and separately lists SDK search queries made from inside that session at the applicable search-tool rate. Therefore, do not replace one session plus three SDK searches with four sandbox charges. Record those as different rows. [1]
What does Orchestrator API pricing mean for a budget?
Orchestrator usage is token-priced at the requested model's rates and has no per-request fee according to the official pricing documentation. Forecast input, cache-read, output, and reasoning-token behavior for each model. If your workflow adds Search or Agent later, add those products' request or tool rows separately rather than applying Orchestrator's token-only rule to the whole workflow. [1]
Can one workflow use Search, Agent, and Orchestrator together?
Yes, the platform describes these as composable API primitives, subject to access requirements. The cost implication is that each API boundary keeps its own meters. A retrieval call, a managed Agent request, and a model-routing request should each carry a product label and usage event so your estimate can be reconciled later. [1]
Are the figures in this guide a guaranteed monthly bill?
No. The fixed rates cited here are vendor-published observations checked on November 2, 2026. The worked example is an illustration based on stated volumes. Your bill can vary with model selection, cached-input eligibility, output and reasoning tokens, successful-versus-failed request status, actual tool use, credits, taxes, contracts, and future rate-card changes.
Limitations and update notes
This guide intentionally does not estimate search volume, keyword difficulty, CPC, rankings, traffic, impressions, revenue, or AdSense outcomes. It also does not treat third-party pricing pages or community anecdotes as authoritative rate quotes. The benchmark behind this article observed a mixed SERP: official documentation and product pages appeared alongside third-party explainers, a comparison page, a wiki, and a community discussion. The practical gap is a reconciliation method, not a claim that other pages are absent or that this page will rank.
Before approving a forecast, capture the exact model ID, search_type, effort or service tier, request status, tool name, session ID, token usage, and response-reported cost where available. Re-run the arithmetic after any pricing-page change. A small event ledger is more reliable than multiplying a vague “API calls per month” estimate by one rate.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.