You know your total LLM spend for the month. You probably know it broken down by feature. What most teams don't have — and what changes the whole conversation once they get it — is spend broken down by user. Not because it's hard to build, but because nobody asked the question until the bill started feeling disconnected from the subscription price it's supposed to be funding.
1. A flat subscription price assumes roughly uniform usage. On AI products, usage is rarely uniform — it typically follows a power-law distribution.
2. Without per-user cost attribution, you can't tell whether a segment of your user base is quietly unprofitable.
3. The fix isn't cutting off heavy users — it's usage tiers, soft limits, or targeted optimization of the specific patterns they trigger.
Why Total Spend Hides the Real Problem
Total spend answers "how much did LLM APIs cost this month." It doesn't answer the question that actually determines whether your pricing works: "is each user paying enough to cover what they cost?" Those are different questions, and a business can look healthy on the first while being broken on the second — average revenue exceeds average cost, so the aggregate math looks fine, right up until someone breaks it down by user and finds a meaningful segment where cost exceeds what they pay.
This is a known pattern in usage-based products generally, not unique to AI: a minority of users driving the majority of usage is the norm across metered systems, not the exception. What makes it sharper on LLM-powered products is the variance in what a single request can cost — a one-line question and a full-document analysis can differ by two or three orders of magnitude in token count, so a handful of power users doing heavy work can dominate cost in a way that's much less common with, say, API request counts on a traditional SaaS product.
Illustrative distribution shape based on typical power-law usage patterns — your own numbers will differ, and finding out exactly how skewed your usage actually is the entire point of measuring it directly rather than assuming.
Want to see your own distribution?
Add the X-Preto-User-Id header to your requests and see per-user cost broken down in your dashboard tomorrow.
See Your Cost Per User — FreeAdd X-Preto-User-Id header. See per-user costs in your dashboard tomorrow.
What to Actually Do Once You Have the Data
Add a usage tier
If your heaviest users are genuinely getting more value — they're using the product more because it's working for them — a higher tier that charges proportionally more is usually the right response, not a penalty. Power users are frequently willing to pay for the capacity they're already consuming; the mismatch is that nobody offered them the option.
Add soft usage limits with an upgrade prompt
Rather than a hard cutoff, a limit that prompts an upgrade at the point a user is about to exceed what their current tier covers converts the cost problem into a revenue opportunity — the user who's already gotten enough value to hit the ceiling is the user most likely to pay for more of it.
Optimize the specific patterns heavy users trigger
Per-user cost data often reveals that a small number of workflows — not the users themselves — are driving the disproportionate cost. If heavy users are concentrated in one or two expensive request patterns, that's a routing or caching opportunity that benefits the whole product, not just a pricing fix for one segment.
The Technical Piece: Tagging Requests by User
Per-user attribution has to happen at the point requests pass through your LLM proxy or gateway — tag each request with a user identifier as it's sent, so cost can be aggregated by user afterward without reconstruction. Trying to stitch this together after the fact from application logs is fragile: it depends on logging discipline staying consistent across every code path that calls the LLM, and in practice it drifts as the codebase grows. Tagging at the infrastructure layer, once, is more durable than trying to enforce a logging convention everywhere a call originates.
Once that tagging is in place, the analysis itself is straightforward — sort users by cost, compare against what each pays, and the unprofitable segment (if one exists) becomes visible immediately rather than requiring a special investigation to find.
Why This Is Worth Doing Before It's Urgent
The teams that build per-user cost visibility before it's a crisis get to make a calm pricing decision. The teams that don't usually find out the hard way — a margin that looks fine in aggregate, followed by a quarter where growth in usage outpaces growth in revenue, followed by someone finally asking "wait, which users are actually costing us money" under pressure instead of as routine practice. The data is the same either way. The difference is whether you're looking at it before or after it's forced the question.
Per-user cost sits alongside cost-per-request as one of the two attribution numbers worth tracking from day one — see the unit economics most AI SaaS pitch decks don't show for how the two connect to margin. And once you know which users are expensive, the model-choice waste pattern is often the fastest fix for their specific usage.
Frequently Asked Questions
Why does per-user LLM cost attribution matter if total spend is already tracked?
How skewed is LLM usage across users typically?
What should I do once I find my unprofitable users?
How do I attribute LLM cost to individual users technically?
Find out what each user actually costs you.
Add one header to your requests and Preto breaks down cost by user automatically — see your distribution in your dashboard tomorrow.
See Your Cost Per User — FreeFree forever up to 10K requests. No credit card required.
