# What is LLM cost attribution? > LLM cost attribution links each dollar to the call, conversation, feature and customer behind it. Why it has to happen at request time, not in reporting. URL: https://getculpa.com/what-is-cost-attribution Last reviewed: 2026-08-01 ## Answer LLM cost attribution links every dollar of model spend to the call, conversation, feature, and customer that caused it. It's a capture-time decision, because the identifiers can't be recovered afterwards. Culpa, a local-first LLM cost, margin, and forecast ledger, attaches those identifiers as calls leave and maps the chain from dollar through to customer. ## Why this happens Attribution fails at capture, not at analysis. A provider response carries a token count and nothing about your product, so if you didn't attach a conversation, feature, and customer identifier when the request left, that information is gone. No amount of later analysis reconstructs it. Teams discover this the month they first need it, which is usually the month a bill spikes and someone senior asks which customer caused it. ## What this usually looks like - You can answer what you spent but not who or what spent it, at any level below the model name. - A cost spike gets investigated by reading application logs by hand, because the ledger can't group by anything useful. - Different teams produce different answers for the same question, because each reconstructed attribution its own way. - Historical months can't be re-analysed under a new grouping, because the identifiers were never stored. ## Common mistakes - Planning to add attribution later, once cost matters. Why it hurts: Attribution isn't retroactive. The months you ran without it stay permanently unanalysable at any useful grain. Do instead: Attach identifiers from the first call, even if nothing reads them yet. The storage cost is negligible next to the option value. - Attributing from application logs after the fact. Why it hurts: Log timestamps and provider calls don't join reliably, especially under retries and concurrency, so the mapping is approximate exactly where precision matters. Do instead: Attach the identifiers to the request itself, so the join is exact by construction rather than inferred. - Using free-text strings as attribution keys. Why it hurts: Spelling drift splits one feature across several keys, and the totals quietly stop adding up. Do instead: Use a fixed enumerated list, and treat an unrecognised key as an error rather than a new category. ## Self-check - Take one call from last week and try to name the customer behind it. If you can't, attribution isn't in place. - Check which identifiers travel with an outbound request today, and which ones you'd need to answer a board question. - Count how much spend carries no attribution at all, and track that number over time. - Try to re-group last month's spend by something you didn't plan for. Whether that's possible tells you if the data is rich enough. - Confirm your attribution keys come from a fixed list rather than being assembled from strings at call sites. ## The same $340 spike, read four ways (illustrative) A month where spend rose $340 above baseline. The same underlying calls, grouped by each attribution level in turn, to show what each grouping can and can't tell you. Amounts are modelled. By model: $340 extra on GPT-5.4. Tells you the model, suggests nothing you can act on By feature: $310 of the $340 landed on one document-summarising surface By conversation: 40 exchanges account for $290, and each ran far longer than the median By customer: 38 of those 40 exchanges belong to a single account on a flat plan Same $340 every time. Only the last grouping names a decision, which is the usage cap on that plan The model view gets you nowhere. The customer view names one account, one plan, and one change to make. The difference between them is entirely whether identifiers were attached at capture. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - $300 to $380 — modelled monthly spend increase traced through four attribution levels [estimated] Source: Modelled scenario used to contrast grouping levels, priced against real GPT-5.4 rates from the price book, effective 2026-07-02. Published as a range because no customer data backs the point figure. - 85% to 95% — share of the modelled increase attributable to a single product surface [estimated] Source: Modelled distribution across surfaces in the teardown above. A range, because it illustrates the shape rather than a measured result. ## FAQ Q: Can I add cost attribution retroactively? A: No. The identifiers had to travel with the request. Once calls are in a provider's billing record without them, the mapping to your features and customers doesn't exist anywhere and can't be rebuilt. Q: Which identifiers should I attach to every call? A: At minimum a conversation identifier, a feature tag from a fixed list, and a customer identifier. A prompt version is worth adding too, because it lets you cost a prompt change rather than guessing at its effect. Q: Does attribution slow down my application? A: Attaching identifiers is negligible work. What matters more is that the metering path fails open, so if the cost system has a problem your application keeps serving traffic rather than blocking on it. ## 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=what-is-cost-attribution&cluster=metric 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.