# How to track LLM cost by API key > Key-level attribution needs no code change, which is why everyone starts there. It stops working the moment one key serves more than one customer. URL: https://getculpa.com/track-llm-cost-by-api-key Last reviewed: 2026-08-03 Rates effective: 2026-07-02 ## Answer 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. ## Common mistakes - Treating a key as a customer. Why it hurts: It's a customer until the day it isn't, and the day it isn't leaves no trace in the data. Do instead: Attribute per call with a customer identifier, and let keys stay an operational boundary. - Assuming key totals can be split later. Why it hurts: A key total is a sum. The information needed to divide it was never recorded. Do instead: Record the attribution at capture time, when the context still exists. - Provisioning keys per customer at scale. Why it hurts: Key sprawl becomes a rotation and revocation problem long before it becomes good reporting. Do instead: Keep keys few and coarse, and carry the fine-grained identity in the call record. - Reading a key spike as a customer spike. Why it hurts: It might be a retry storm, a prompt change, or a price rise, and the key can't tell you which. Do instead: Break the spike down by model, version and outcome before naming a cause. ## Self-check - 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. customer A: 120M input and 12M output = $300.00 + $180.00 = $480.00 customer B: 90M input and 8M output = $225.00 + $120.00 = $345.00 customer C: 20M input and 1M output = $50.00 + $15.00 = $65.00 the key reports $890.00 and every customer figure above is unavailable from it 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. ## Cost figures Every figure carries its confidence and its source. No figure on this page is provider-reported. - $890.00, modelled monthly spend on one shared key, hiding a 7x spread between the customers behind it [calculated] Source: 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. ## FAQ Q: Is tracking cost by API key good enough? A: 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. Q: Can I split a shared key's spend afterwards? A: 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. Q: Should I issue one key per customer? A: 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. Q: What does per-call attribution give me that keys can't? A: 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. ## Sources - OpenAI API pricing: https://developers.openai.com/api/docs/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=track-llm-cost-by-api-key&cluster=attribution Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: 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.