How to calculate your LLM cost, and margin, per customer

AI Pricing Lab · Updated 2026-07-17

Plenty of guides cover tracking LLM costs for engineering purposes. Almost none of them finish the job, which is joining cost to revenue so you can see margin per customer and make a pricing decision. This one goes end to end, with a worked example. It assumes nothing more than API logs and a Stripe account.

Step 1: Attribute every model call to a customer

The prerequisite is a customer identifier on every request. Three ways to get it, in increasing order of effort:

• Metadata fields. OpenAI and Anthropic both accept a user or metadata field on API calls. Pass your internal account ID and it comes back in usage exports.
• An observability layer. Tools like Helicone, Langfuse, or a LiteLLM proxy record per-request usage with custom properties. If you already run one, you have the data and just need to group it.
• Application logs. If neither exists, log account ID, model, input tokens, and output tokens on every call. One logging line, one afternoon of backfill regret.

If you can only reconstruct the last 30 days, start there. A month of real attribution beats a year of blended averages.

Step 2: Price the usage

Multiply tokens by your actual per-token rates, per model, remembering that input and output are priced differently and that cached input is usually cheaper. Then add the per-request costs that are easy to forget: embeddings, vector database queries, transcription, image generation, web search calls. For most products these secondary costs are 10 to 30 percent on top of raw inference, and for retrieval-heavy products they can rival it.

Step 3: Join against Stripe revenue

Export monthly revenue per customer (invoice totals or subscription MRR). Join on your account ID. You now have three columns per customer: revenue, AI cost, and margin. This is the join almost nobody does, because cost lives in engineering dashboards and revenue lives in Stripe, and no single tool owns both. It is also the only join that turns cost data into a pricing decision.

Step 4: Read the distribution, not the average

Compute three numbers over cost per customer: the median (P50), the 90th percentile (P90), and the 99th (P99). AI usage is power-law distributed; a small share of accounts consumes most of the compute. The blended margin can look respectable while the tail bleeds.

A worked example. Say you charge a flat $99/month and serve 100 customers, with this month's attributed AI costs:

The blended number says 78 percent and everything is fine. The per-customer view says your two or three heaviest accounts are consuming a quarter of your model bill and paying 3 percent of your revenue. Both statements are true. Only one of them tells you what to do.

Why your most engaged user may be your worst customer

This is the uncomfortable part. In a flat-priced AI product, engagement and unprofitability are the same variable. The customer who loves the product most, runs it hardest, and evangelizes it loudest is also the one consuming $400 of inference against a $99 subscription. The reported Copilot numbers made this famous: an average loss of $20 per user per month, with some users costing $80, on a $10 plan. You cannot see this condition in retention dashboards, where it looks like success. It only shows up in margin per customer.

Step 5: Decide what to do with the bottom decile

Three moves, in order of preference:

• Meter them. Add a usage allowance to their tier with overage past it. This is repricing, not punishment: their bill tracks their cost, and your P50 customers are untouched. Our pricing models guide covers structures, and the repricing playbook covers the migration.
• Cap them. A hard or soft cap stops the bleeding this week while you design the real fix. Communicate it plainly; silent throttling destroys trust.
• Fire them. Rarely, an account's usage is so far outside your model that no reasonable price works. A candid conversation and a migration window beats slow-bleeding resentment on both sides.