Guides / track llm cost by api key
How to track LLM cost by API key
Tracking LLM cost by API key means issuing a separate provider key per tenant or environment and reading spend per key. It needs no code change, which is why most teams start there. Culpa, a local-first LLM cost, margin, and forecast ledger, prices and attributes each call individually, so attribution survives a key that serves many customers.
Why this happens
Key-level attribution is the only kind you get for free, and that's both its appeal and its trap. Issue a key per environment and you can separate staging from production without touching a line of code. Issue one per customer and you appear to have per-customer economics. The trap is that the number a key reports is always true and stops being useful the moment the key stops mapping one-to-one onto the thing you actually want to measure. One key serving forty customers reports one total, and no analysis recovers the split afterwards, because the information was never captured. The second problem is operational: keys get reused in a hurry during an incident, and the attribution damage is silent and permanent. Keys are a good coarse boundary. They're a poor unit of economics.
What this usually looks like
- One key serves every customer and the per-customer question has no answer.
- A key got shared during an incident and last month's split is now fiction.
- You can separate staging from production and not one feature from another.
- Adding a customer means provisioning a key, so nobody does it consistently.
- Your provider console shows spend per key and your finance question is per account.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Treating a key as a customer. | It's a customer until the day it isn't, and the day it isn't leaves no trace in the data. | Attribute per call with a customer identifier, and let keys stay an operational boundary. |
| Assuming key totals can be split later. | A key total is a sum. The information needed to divide it was never recorded. | Record the attribution at capture time, when the context still exists. |
| Provisioning keys per customer at scale. | Key sprawl becomes a rotation and revocation problem long before it becomes good reporting. | Keep keys few and coarse, and carry the fine-grained identity in the call record. |
| Reading a key spike as a customer spike. | It might be a retry storm, a prompt change, or a price rise, and the key can't tell you which. | Break the spike down by model, version and outcome before naming a cause. |
Run this check tonight
- Count your provider keys, then count the things you want cost broken down by.
- If those two numbers differ, name what you lose in the gap.
- Ask who can issue a key, and whether an incident last quarter created one.
- Pick your largest key and try to name which customer drove its last increase.
What one shared key hides
A modelled tenant on one shared key spending $890.00 a month, priced on gpt-5.4 at real rates of $2.50 and $15.00 per million from the price book, effective 2026-07-02. Three customers sit behind that key. The key reports one number and it's correct. Customer volumes are modelled.
The key total is accurate and answers nothing. Customer A costs more than seven times customer C, and if they pay the same subscription then one is subsidising the other. A key can never surface that, because the split was never recorded anywhere.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $890.00 | modelled monthly spend on one shared key, hiding a 7x spread between the customers behind it | calculated | Sum of three modelled customers priced on gpt-5.4 at real rates of $2.50 and $15.00 per million from the price book effective 2026-07-02: $480.00 + $345.00 + $65.00. Customer token volumes are modelled. The point of the figure is that the total is correct and the three components are unavailable from it. |
What a generic answer can’t know
Provider consoles are built around keys because a key is the only identity a provider has for you. That makes key reporting the ceiling of what any external dashboard can offer, no matter how good it looks. Culpa attaches attribution to the call rather than to the credential, so one key can serve every customer and the split still exists. Each call is priced from a versioned price book in exact decimal and tagged with the customer, the feature and the run that caused it, which is what turns a correct total into an answerable question. Set those per-customer costs against the revenue each customer pays you and the output is margin rather than spend.
Questions founders ask next
Is tracking cost by API key good enough?
It's good enough while each key maps one-to-one onto the thing you want to measure. It stops being good enough the moment a key serves more than one customer, feature or environment, and that usually happens quietly during an incident rather than as a decision.
Can I split a shared key's spend afterwards?
No. A key total is a sum, and the information needed to divide it was never captured. This is the one attribution failure that can't be fixed retroactively, which is why it's worth deciding before you need the answer.
Should I issue one key per customer?
Usually not past a handful. Key sprawl turns into a rotation, revocation and secret-storage problem faster than it turns into good reporting. Keep keys coarse for operational separation and carry customer identity in the call record instead.
What does per-call attribution give me that keys can't?
Cost per customer while sharing one key, cost per feature within one customer, cost per prompt version within one feature, and the ability to answer a question you didn't anticipate when you provisioned the key.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Keep reading
Sources: OpenAI API pricing. Last reviewed 2026-08-03, rates effective 2026-07-02. Plain text version.