How to Attribute LLM Cost to Customers

Revenue is up. Your AI bill is up more. You open your provider's billing page hoping for an explanation, and you get exactly one number for the entire month, no names, no accounts, no breakdown. So you can't answer the only question that actually matters: is the customer who just doubled my usage also doubling my profit, or quietly eating it?

That gap is the whole problem. You can't attribute LLM cost to customers with the data your AI provider gives you, because the provider doesn't know your customers exist. It only sees requests coming from your product.

The short answer: write the customer's name on every AI request before it leaves your product; keep a small receipt of what each one used; turn those receipts into dollars using your provider's price list; then stack the receipts by customer.

Label, record, price, group. Four steps, and the rest of this article is just detail on each one.

If any of that felt vague, here's the plain version. Every time your product asks the AI to do something, summarize this document, answer this question, clean up this text, that's one small purchase. Today, all of those purchases land on one combined bill with no names on them. You're going to start writing names on them.

Why one big AI bill tells you nothing

Think of your AI bill like an electricity bill for an entire apartment building. The meter at the front of the building is accurate. It's also useless if what you actually want to know is which apartment left the heating on all month.

Your AI provider is that building meter. It bills you per API call — every time your product asks the AI provider to do something, that's one request going out and one charge coming back. The provider stamps that request with your account, not with Customer A's account, because from the outside, all your customers look like one big customer: you.

So the fix isn't better reporting from your provider. The fix is putting a label on each request before it leaves your product.

What "attribute LLM cost to customers" actually means

Here's the version I'd explain to a founder over coffee.

Every AI request your product makes is a small purchase. Right now those purchases arrive on one combined receipt. What you want is a name written on each receipt, so you can sort the pile by customer at the end of the month.

That name is a customer ID, the unique label your software already uses internally to tell one account from another. Your app has one. Your database has one. Your Stripe records have one. It just isn't currently travelling along with your AI requests.

Attaching that ID to each request is what people mean by per-customer AI cost attribution. Everything else, dashboards, margin reports, alerts, is built on top of that one habit.

The four steps to attribute LLM cost to customers

1. Label the request

Before your product sends anything to the AI provider, it should attach two pieces of information: which customer triggered this, and which feature they were using.

That extra information rides along with the request as metadata — think of it as a sticky note on the envelope. It doesn't change what the AI does. It just makes the request identifiable later.

Add the feature name now even if you only care about customers today. It costs nothing extra, and it's the difference between "Customer C is expensive" and "Customer C is expensive because of the bulk summarizer." I've regretted skipping this. I've never regretted adding it.

2. Record what came back

When the AI provider answers, it tells you how much work it did, measured in tokens, small chunks of text, roughly three-quarters of a word each. Providers charge separately for the text going in (input tokens) and the text coming out (output tokens), usually at different rates, and each model has its own price.

So for every request you want a small record kept: customer, feature, model, input tokens, output tokens, timestamp. That's it. Six fields.

This is what your developer would call logging: writing a line into a table somewhere every time something happens, the same way a shop keeps a till roll.

3. Turn usage into money

Tokens aren't dollars until you apply the provider's price list. Multiply input tokens by the input rate for that model, output tokens by the output rate, add them together, and you have the cost of that single request.

The trap here is model prices change, and models get swapped. If your developer hardcodes today's price into the calculation and you switch models in April, your March-to-May comparison is quietly wrong. Store the model name on every record so the pricing can be applied correctly later.

4. Group by customer

Now the boring, valuable part: add up every record carrying the same customer ID. One combined bill becomes customer-level AI spend.

Using hypothetical numbers, a $2,000 month might look like this:

Those numbers are illustrative, not from my products. But the shape is the point: Customer B and Customer C are on the same price list as Customer A and cost you ten to forty times more to serve. Customer C is losing you money every single month, and on a single blended bill you'd never see it.

What I would actually ask my developer to do

You don't need to build this, and you don't need to read the code. What you need is to be specific about the outcome. If I were handing this over, the brief would be one paragraph:

"Every request we send to the AI provider needs to carry the customer ID and the feature name. For every response, store the customer, feature, model, input tokens, output tokens and timestamp. I want to be able to pull AI cost per customer and per feature for any date range."

That's the whole ask. How they implement it, where the code sits, and which table it writes to are their call, not yours. If a developer tells you this is a big project, it's usually a signal that AI calls are scattered across the codebase rather than a signal that the request is unreasonable.

The four things that quietly break the numbers

Once the basic system works, the accuracy problems are always the same four.

The second attempt you forgot about. Sometimes a request doesn't go through, the provider is slow, or something times out, and your product quietly asks again. You get charged for both tries, the same way a failed delivery still costs the courier a trip. If you only count the attempt that worked, your numbers will always look a little better than your actual bill. Ask your developer whether failed attempts are being counted too.

The answers you're reusing. Most products keep a copy of answers they've already paid for, so the next person asking the same thing gets the saved copy instead of a fresh, paid one. The technical name for that stored copy is a cache. The original answer cost you money; handing out the copy costs almost nothing. If your reporting charges every customer full price whether they got the original or the copy, you'll flag a cheap customer as an expensive one.

The work that happens while nobody's watching. Plenty of AI cost isn't triggered by someone clicking a button, re-processing a customer's uploaded files after an update, generating their weekly report at 3 am, keeping their documents organized so search stays fast. Real money, no human involved. It's like a shop restocking shelves overnight: nobody's in the store, but it still costs you. Each of those jobs is being done for a specific customer, so it should carry that customer's name like everything else. Skip this and a big slice of your AI COGS ends up in an "unknown" pile that you can't explain.

Your own usage. Your demo account, and the practice copy of your product your developer works on before changes go live, are sitting on the same bill as your paying customers. If nobody separates them, your cost numbers are permanently inflated by your own team's activity.

Get these four right, and you're at maybe 95% accuracy, which is plenty. Chasing the last 5% is not a good use of a founder's month.

What you do with the numbers

Attribution isn't the goal. Deciding something is the goal. Once you can see customer profitability after AI costs, three decisions get much easier.

Pricing. If your heaviest 10% of accounts consume half the AI budget, flat pricing is a slow leak. That usually points to usage limits on the lower plans, or a usage component on top of the base price.

Sales. I've spent 7+ years selling B2B SaaS, and this is the part I'd have wanted years ago: knowing the cost-to-serve before promising "unlimited" in a deal. Unlimited AI usage is an easy thing to sell and an expensive thing to honour. Knowing your average and worst-case AI cost per customer turns that from a gut call into a number.

Retention. Not every unprofitable customer should be repriced. A heavy user on a cheap plan can be your most engaged account and your best expansion candidate. That's an argument for moving them up a plan, not for treating them as a problem.

See how you can monitor "Plan Level Profitability"

Do you actually need this yet?

Honestly? If you have ten customers, no. I wouldn't spend two weeks building an attribution system to answer a question I could answer by exporting last month's usage into a spreadsheet on a Sunday afternoon.

Here's roughly where I would draw the line:

The tell that you've crossed the line is simple: you're making a pricing or plan decision, and you can't back it with a number.

Check out our "Free LLM Spend Analyzer"

Questions I get asked

Can't my AI provider just show me this? No. The provider bills your account, not your customers. It has no idea who Customer C is, so nobody outside your product can work out your LLM cost per customer for you. The labelling has to happen inside your own product.

How accurate does this need to be? Close enough to make a decision. If you're within a few percent, you'll spot the unprofitable accounts, and that's what you're doing this for.

What if one request serves multiple customers? Split it by whatever fair rule you can defend, usually per record processed, and write the rule down. Consistency matters more than precision here.

Where I would go next

If you're already exporting usage and sorting it by hand every month, you've proved the problem. That's the point where I'd stop maintaining a spreadsheet that breaks every time a model price changes. AI Observly is built to show AI cost by customer, feature, and plan without you building and babysitting the reporting layer yourself.

Check out AI Observly's Per-Customer Cost Attribution