Why the vendor invoice is never enough

LLM vendors bill by tokens, and tokens by themselves carry almost no attribution. A single OpenAI API key can be shared by a production chatbot, a nightly batch job, a staging environment, and three engineers experimenting with prompts — and the invoice will show them all as one line item.

The failure mode this creates is specific: you can't answer the three questions that matter.

• Is this feature profitable? Without attribution, you know what the feature costs in engineering time but not in inference. The profitability math is incomplete.
• Is this customer over-consuming? One customer's heavy usage can show up as a line item that the whole pricing model silently subsidizes.
• Is this experiment out of control? A spike you can't assign to anything is a spike you can't stop, because you don't know where to look.

The result is that cost conversations happen in arrears, at invoice time, with no data to act on. Attribution moves them forward: you see the leak while it's happening and in the right place.

The three levels of attribution

Not everything needs the same depth. Work out which level you need before you build anything, because the effort rises fast with the precision.

A small company usually needs the first level this week, the second within a quarter, and the third the moment customers become involved. Build in that order.

Level one: keys and tags

The cheapest meaningful attribution is to stop sharing one key across everything. Every major LLM provider lets you create multiple API keys, and most let you tag or name them.

Create one key per environment (production, staging, dev) and one per significant application or team. This alone turns a single opaque invoice into a handful of understandable buckets. It isn't precise enough to know which feature inside production drove the spend, but it's enough to know whether the growth experiment, the batch job, or the production chatbot is the expensive one — which is the most common question.

Level two: metadata on the request

To get down to features, you attach metadata to each request and read it back in the usage data. Providers expose per-request usage — OpenAI's usage API and Anthropic's usage endpoint both return per-request token counts — and the request itself can carry identifying metadata such as a feature name or a workflow id.

The pattern is simple: when your code calls the model, include a small structured label — feature, prompt template, model intent — and record the request's token usage against that label in your own database or log. From there you can sum tokens per feature and multiply by the model's rate. This is the level that makes the profitability question answerable.

Level three: customer attribution

When you bill customers or offer self-serve tiers, you need to know how much of your inference spend each account drives. The mechanism is the same as level two — metadata on the request — except the label is a customer or account id.

This is the attribution that protects margins. A customer on a flat tier who generates ten times the average inference volume is a margin leak you can now see, quantify, and price for. It's also what makes usage-based or hybrid pricing possible, because you can finally point at the cost a given account imposes.

What to attribute, and what not to overdo

Attribution has a cost of its own, and over-instrumenting is a real failure mode. A few rules keep it proportionate:

• Attribute what you'll act on. If nobody will use a given dimension, don't collect it. Data you never read is maintenance, not insight.
• Attribute at write time, not invoice time. Reading the vendor invoice and guessing is guesswork. The per-request usage records are the source of truth; the invoice is just the sum.
• Keep the metadata stable. A feature label that changes with every deploy breaks the sums. Version it or treat it as fixed at call time.
• Watch your own sampling. If you sample usage records to keep storage low, remember the sums are estimates, and make sure the sampling rate is constant enough to compare across time.

The goal is a weekly or monthly picture you trust: total spend by team, by feature, by customer, with the spikes legible. Precision beyond that rarely changes a decision.

The compounding effect

Attribution pays off twice. The first payoff is operational: leaks get found, experiments get budgets, and cost conversations stop being fights over a number nobody can explain. The second is strategic: once you can see cost per feature and per customer, pricing, model right-sizing, and build-vs-buy decisions all become data exercises instead of opinions.

That's the difference between a company that discovered AI costs too late and one that never lost track of them. The tool that gets you there — collecting per-request usage against stable metadata and summing it by dimension — is well within reach, and you can start at level one this week.

If you'd rather not assemble the pipeline yourself, AICosts.ai ingests usage and billing from 50+ providers, normalizes it, and surfaces per-team, per-feature, and per-customer cost breakdowns automatically — so the attribution work happens once, in the platform, rather than in your own database.

FAQ

• Why can't I just read the vendor invoice to see what cost what? Vendors bill by tokens, and tokens carry no attribution. A single shared API key mixes production, staging, features, and experiments into one line item. You can't tell which feature, team, or customer drove the spend, which is exactly the information you need to manage it.
• What's the easiest way to start attributing AI costs? Stop sharing one API key. Create separate keys (or tags) per environment and per significant application, and sum usage by key from the provider's usage API. This takes minutes and answers the most common question: which workload is the expensive one.
• How do I attribute costs to individual features? Attach a stable feature label to each model request and record the per-request token usage against that label in your own database or log, then sum by label and multiply by the model's rate. The provider's usage endpoint gives you the per-request token counts; your metadata tells you which feature they belong to.
• Do I need per-request tracking for customer-level attribution? Yes. Customer attribution uses the same mechanism — a customer or account id in the request metadata, recorded against usage. Without it you can't tell which accounts over-consume relative to their pricing, which is the main margin risk in AI-heavy products.
• How much attribution is too much? If a dimension won't change a decision, don't collect it. Team/environment attribution is enough for most companies to start; feature and customer attribution add value as those questions become real. Collect at write time from usage records, keep labels stable, and don't let instrumentation become a project of its own.