Perplexity API Cost Attribution: Tracking Spend Per Tenant, Per Feature, and Per Request (2026)

Every other Perplexity problem worth writing about is a problem with a request. It failed, or it never got made, or it ran slowly, or it came back in a shape you could not trust, or the model underneath it was quietly replaced. This one is different: every request worked. The failure is that at the end of the month you have a single number from api.perplexity.ai and no defensible way to say which customer, which feature, or which code path produced it.

That is an allocation problem, not a pricing problem, and the distinction matters because the two have completely different fixes. Knowing the per-token rate tells you what a request costs. Knowing that eleven percent of your inference spend goes to free-tier accounts running one feature you shipped as an experiment tells you what to do on Monday. The second question is the one that changes decisions, and the provider cannot answer it for you at any price, because the dimension it needs — your tenant id — was never on the wire.

What the Invoice Structurally Cannot Know

It is worth being precise about the limits of the billing surface, because a lot of wasted effort goes into exporting it and pivoting it in a spreadsheet. Perplexity bills on input and output tokens plus a separate charge tied to the search and retrieval work behind a grounded answer, aggregated by key and by day. From the outside, that is everything observable. Four things it never sees:

Which tenant. Your production key serves all of them. The invoice sees one caller.
Which feature. Summarisation, search, the onboarding assistant and a nightly batch job all arrive as the same kind of request.
Which code path. A retry, a speculative pre-fetch and a user-initiated action are indistinguishable on the wire.
Whether the spend produced anything. A completion the user abandoned costs exactly what one they converted on costs.

None of those are gaps Perplexity could reasonably close. They are facts that exist only inside your process, at the moment the call is made, and if you do not write them down then they are gone. This is why attribution is a logging problem that happens to be about money, and why it is cheap to do at the call site and nearly impossible to reconstruct afterwards.

The Attribution Ladder

Most teams are on rung one and think the jump to rung five is a project. It is not; each rung is a small change that answers a strictly larger set of questions.

Rung	What you have	Question it answers
1	The invoice	Did spend go up?
2	A key per environment	Is staging burning production money?
3	A key or tag per major workload	Is the batch job or the product bigger?
4	A priced ledger row per request	Which tenant and which feature, on any day?
5	Ledger joined to product events	What does a completed job, or a paying account, cost?

Rung four is the one that pays for itself, and rung five is the one that changes pricing conversations. Note that rungs two and three are the only ones that use API keys as the mechanism, and they are deliberately coarse — keys are a bad allocation primitive because they get shared, rotated and reused, and when two workloads end up on one key your attribution degrades silently. Past that point, allocation belongs in data.

The Ledger Row

One row per attempt, written by the same wrapper that makes the call, priced at write time. The fields that carry the weight:

Field	Why it is not optional
tenant_id	The whole point. Never null — use an explicit “internal” or job id instead.
feature	A tenant total tells you who; only this tells you what to change.
model_id	The exact string you sent, not a friendly name. Rates are keyed on it.
input / output / cached tokens	Priced differently. Collapsing them into one number throws away the discount.
attempt	Retried attempts consumed input tokens. One row per logical call under-reports.
outcome	Errors and abandoned streams still cost money, and they are your cheapest saving.
rate_version	Pins the price used. Without it, last quarter restates itself when prices move.
cost	Computed once, stored as a fact. Not a view over today’s prices.

Two of those deserve emphasis because they are the ones teams skip. Pricing at write time makes historical cost immutable; a cost column derived by joining to a live price list means a rate change silently rewrites every report you have ever published, and nobody trusts a number that moves. Never writing a null tenantmatters because the null bucket grows: every background job, every migration, every admin tool lands there, and within a month the largest line in your cost report is called “unknown” and no one can decompose it. Make the wrapper require the field and force callers to name their job explicitly.

Enforce this with one construction point. If any service can build a raw client and call api.perplexity.ai directly, attribution is optional, and optional instrumentation is absent instrumentation within two quarters. Have exactly one module that creates the client and takes tenant and feature as required arguments, and make a direct import of the vendor SDK anywhere else a lint failure.

Reconciliation: The Test That Keeps It Honest

A ledger nobody checks drifts, and it drifts in the direction that makes you feel good: spend you failed to record simply does not appear. So run a scheduled job that sums the ledger over the provider’s billing period and compares it to the actual Perplexity invoice total, and alert when the gap exceeds a small percentage. A stable two percent gap is a known bias. A gap that grew from two percent to nine last week means a whole category of spend is missing, and the sooner you know that the smaller the archaeology.

The recurring causes, roughly in order of how often they turn up: streamed responses that returned no usage block and wrote zeros; retries counted once; a surface someone started calling that your cost function does not know how to price; a rate table that missed a price change; and requests that errored after the provider had already read the input. Each of those is a specific check you can add once you have seen it, which is why the reconciliation job is worth more than the accuracy it enforces — it is the thing that teaches you what your instrumentation is blind to.

Six Ways Attribution Breaks While Everything Returns 200

Symptom	HTTP	Real cause	Fix
Streaming requests look free	200	No usage block on a stream unless requested; writer recorded zero	Opt into usage on streams; treat a zero-token success as an error, not a row
Ledger runs 20% under invoice	200	Retries billed per attempt, logged per call	Write a row per attempt with an attempt number
“Unknown” is your biggest tenant	200	Background jobs and admin tools call with no tenant in scope	Require the field; give jobs an explicit job id as their tenant
Last quarter’s report changed	200	Cost is a view joined to current prices, and prices moved	Price at write time from a dated rate table; store cost as a fact
One feature’s cost halved overnight with no deploy	200	Cached input is billed at a lower rate and traffic patterns shifted	Break cached input into its own column so the change is visible, not spooky
A surface never appears in any report	200	It bills on a different unit than tokens, so the cost function returns zero	Carry a unit type per row and fail loudly on an unpriceable unit

The pattern across all six is that none of them raise. There is no exception to catch and no alert that fires on its own, because from the application’s point of view every one of these requests succeeded. The only detector is the reconciliation gap and a small set of assertions on the ledger itself: no successful row with zero tokens and zero cost, no row with a null tenant, no row with a model id absent from the rate table.

Budgets in the Request Path

Reconciliation is a rear-view mirror. If a single tenant can generate a month of normal spend in an afternoon — and with a scripted client against api.perplexity.ai, they can — you need a check that runs before the call, which means it has to be cheap enough to run on every call. A counter in a fast key-value store, keyed by tenant and period, incremented as each response is priced, read on the way in.

Give it two thresholds and make them behave differently. The soft threshold degrades: route to a smaller model, trim the context window, move the work from interactive to queued, drop optional enrichment passes. The hard threshold denies, and it should apply to trial and free-tier accounts rather than to paying ones, because a hard cut-off on a customer who is happily paying for what they are using is an outage you inflicted on yourself to save money you were making. Return a clear, machine-readable reason on denial and surface it in the product, or your support queue absorbs the cost you just avoided.

From Attribution to Unit Economics

Once the ledger carries tenant and feature, join it to the events you already emit and the interesting numbers fall out. Cost per completed job tells you whether a feature is viable. Cost per paying account, divided by that account’s revenue, is gross margin per customer and it is almost never evenly distributed — expect a small number of accounts to consume a wildly disproportionate share, and expect at least one of them to be on your cheapest plan.

The ratio to watch is spend on non-converting activity: free-tier accounts, abandoned sessions, retried failures, speculative work the user never saw. It is usually larger than anyone guesses, it is the least painful thing to cut, and it is invisible without exactly the two fields this whole exercise is about. That is the argument for doing this while the bill is small: the work is identical and the answers arrive before the decisions do.

The Perplexity Trap: A Token-Only Ledger Structurally Under-Counts a Search-Grounded Answer

Every other provider on this list charges you for a model reading your input and writing an output. Perplexity also goes and looks things up, and that retrieval work is not free and is not measured in your prompt tokens. A ledger that multiplies tokens by a token rate will therefore report a number that is consistently below the invoice, and the gap will be largest for exactly the requests you most want to attribute: the broad, open-ended questions that triggered the most search.

So the row schema needs a second cost component. Record the request's search or retrieval volume alongside the token counts -- the number of sources consulted or citations returned is the closest observable proxy available at the call site -- and compute cost as tokens times token rate plus retrieval units times retrieval rate. Even if your retrieval rate is an estimate calibrated against the invoice, having the component in the schema is what makes calibration possible at all. A schema with no field for it can never be reconciled, only apologised for.

This also changes which optimisation your data will recommend. On a token-only provider, the lever is shorter prompts. Here the expensive requests are the ones with the widest search, so the lever is scoping the question -- domain filters, recency windows, or routing the narrow lookups to a non-grounded model entirely. You cannot see that difference unless retrieval is its own column.

What to Log

Log the priced ledger row on every attempt, the reconciliation gap between ledger and invoice as a percentage on every billing period, and the counts of the three assertions above: zero-cost successes, null tenants, and unpriceable model identifiers. Those turn “the bill went up” into a named tenant, a named feature and a date. What none of them can tell you is whether api.perplexity.ai was degraded while your costs looked strange — a provider incident produces retries, timeouts and duplicated spend that read as a usage spike from inside your own data. That is the gap external monitoring closes.

Frequently Asked Questions

Why can I not just use the Perplexity dashboard to see what each customer costs?

Because the provider never learns what a customer is. The billing surface knows the things it can observe from the outside: which API key was used, which model was called, how many tokens moved, and on which day. It has no idea that key belongs to your production cluster serving four thousand tenants, that half the spend came from one background summarisation job, or that a particular account is on your free tier. The dashboard is therefore an excellent invoice and a useless allocation tool, and no amount of exporting it will change that -- the dimension you need was never sent. Attribution has to be recorded at the call site, in your own code, where the tenant id and the feature name are still in scope. Everything else is reconstruction from a shadow.

Should I create a separate Perplexity API key per customer?

Per environment yes, per major workload often, per customer almost never. Keys are a coarse instrument: they get rotated, leaked, reused, and shared between services, and the moment two workloads share one the attribution collapses silently rather than loudly. They also do not scale -- a thousand-tenant product does not want a thousand-secret rotation problem to answer a reporting question. Use a small number of keys to separate environments and anything you would want hard-isolated for a security reason, and do the fine-grained allocation with a ledger row that carries the tenant id as data. The one case where a per-customer key genuinely earns its keep is an enterprise account that brings its own key, because then the invoice is theirs and the attribution problem is somebody else’s.

What exactly should I record on every Perplexity call?

A request id, a timestamp, the tenant or account, the feature or code path, the exact model identifier, the token counts broken out into input and output with cached input separate if the surface reports it, the outcome, the attempt number, and the version of the rate table used to price the row. The last one matters more than it looks: a cost column computed by joining to today’s prices will rewrite history the next time prices change, and a quarter that silently restates itself destroys trust in the whole system. Price the row once, at write time, from a rate table with an effective date, and store the resulting number as a fact. Also record the attempt number rather than one row per logical call, because retried attempts consumed input tokens whether or not you kept their output.

How close should my ledger get to the actual Perplexity invoice?

Within a couple of percent, checked on a schedule rather than at the end of a quarter, and treated as a broken test when it drifts. Perfect agreement is not the goal and is not achievable -- rounding, mid-period rate changes and requests that failed between the provider counting them and your process recording them all contribute a little noise. What matters is that the gap is small and stable, because a stable gap is a known bias you can correct for while a moving gap means a whole category of spend is not in your ledger at all. When it moves, the usual culprits are a new surface someone started calling, streamed requests recording zero usage, retries counted once, and a rate table that missed a price change.

Can I stop a runaway tenant before the bill arrives?

Only if the check runs in the request path, which means the check has to be cheap. Reconciling against an invoice tells you what happened weeks ago; even an hourly aggregation job leaves an hour of unbounded spend. The workable version is a counter in a fast store, incremented as each response is priced, read before each request against a per-tenant budget with a soft and a hard threshold. Crossing the soft threshold should degrade rather than deny -- a smaller model, a shorter context, a queued rather than interactive job -- because a hard denial on a paying customer is an outage you caused. Reserve the hard stop for free-tier and trial accounts, which is where genuinely abusive volume actually shows up.

Is attribution worth the engineering time if our Perplexity bill is small?

It is worth it exactly when the bill is still small, because the work is the same size then and the decisions it enables are already in front of you. The questions that need the ledger are not accounting questions: what does serving this plan actually cost, which feature is worth its inference budget, can we afford this on the free tier, is the enterprise deal we are about to sign profitable at the usage they described. Teams that wait until the number is alarming end up trying to instrument a system under time pressure while also trying to reduce its cost, and they do both badly. A ledger costs one field on a log line and one join, and it is far harder to add once several services are already calling api.perplexity.ai without a tenant id in scope.

Related Guides

A Provider Incident Looks Exactly Like a Usage Spike

Retries, timeouts and duplicated spend all show up in your ledger as tenants suddenly costing more — and your own logs cannot tell you whether api.perplexity.ai was degraded at the time, because they only contain your traffic. API Status Check probes api.perplexity.ai and the rest of your stack independently and alerts on errors and latency, so you know whether to open the cost report or the incident channel.

Start Your Free Trial →