Per-User LLM Cost Tracking: Attributing AI Spend

Per-user LLM cost tracking answers a question most AI products cannot: which accounts are actually driving the bill? A monthly total tells you what you spent. It says nothing about whether ten users generated eighty per cent of it, whether your cheapest plan is quietly your most expensive to serve, or whether a single automated script is eating margin you thought you had. Without attribution to the user, your AI cost is a lump — and you cannot price, cap, or defend a lump.

This is the natural companion to shadow AI spending: once you have found the spend, you have to assign it to whoever caused it. Per-feature attribution tells you what costs money; per-user attribution tells you who.

Why the total lies to you

LLM usage is almost never evenly distributed. It follows a steep curve: a small fraction of users generate the large majority of tokens. That is not a pathology — it is the normal shape of usage. But it means an average is actively misleading. “Average cost per user” divides a number dominated by a handful of heavy accounts across everyone, producing a figure that describes nobody.

The consequences are concrete. You set a flat price based on the average, and your heavy users torch the margin while your light users subsidise them. You cannot tell an abusive integration from a delighted power user, because both look like “high usage” in the aggregate. And when a customer asks why their invoice moved, you have no per-account answer.

What per-user attribution requires

The mechanism is simple in principle: every LLM call carries a stable user identifier, and cost is summed along that dimension. In practice, a few decisions matter.

• Pick a stable key. A user ID, tenant ID, or account ID that survives sessions. Email is fragile; internal IDs are better.
• Tag at the call site, not after. Attribution reconstructed from logs at month-end is expensive and lossy. Attach the identifier when the call is made. Token cost tracking captures user, feature, and model together on every call.
• Carry it across providers. If a user’s requests fan out to OpenAI, Anthropic, and an open model, all three slices must roll up to the same identifier or the picture fractures.
• Preserve the model dimension too. A user who triggers expensive-model calls costs far more than one on the cheap path, even at equal request counts. User plus model is where the truth lives.

Finding your cost whales

Once spend is attributed per user, the first exercise is ranking. Sort accounts by cost and look at the top of the list. You will almost always find a handful that dominate. For each, ask one question: is this a healthy heavy user, or a leak?

• A power user on an enterprise plan generating proportional value is fine — you may even want more of them.
• A free-tier account consuming frontier-model tokens all day is a margin hole.
• A single account making machine-regular calls at machine-regular intervals is probably an integration or a script, and may want rate-limiting rather than a bigger invoice.

The ranking turns an anonymous total into a short, actionable list. You cannot act on “we spent too much”; you can act on “these six accounts are eighty per cent of spend, and two of them are on free plans.”

From attribution to unit economics

Per-user cost is the raw material for real unit economics. With it, you can compute cost-to-serve for each pricing tier and check that your prices actually clear your costs. You can identify tiers that are structurally unprofitable — where the median user in a plan costs more to serve than the plan charges — and either reprice, cap, or route them to cheaper models. And you can model the marginal cost of a new signup instead of guessing it.

As an illustrative example only: suppose a product charges a flat monthly fee and discovers that its top decile of users each cost, say, several hundred rupees a month in LLM spend against a fee well below that. The numbers here are made up to show the shape of the analysis — but the shape is the point. Flat pricing over a steep usage curve leaks margin at the top, and per-user tracking is the only way to see exactly where.

Guardrails without punishing good users

Attribution is diagnosis; the treatment is targeted controls. Per-user data lets you act surgically instead of throttling everyone:

• Budget alerts scoped per account or tenant fire when an individual user’s spend crosses a threshold — so an abusive integration surfaces the same day, not on the invoice.
• Anomaly detection learns each account’s normal usage and flags the ones that deviate. A steady user who suddenly 50x’s their volume stands out against their own history, whether the cause is a new feature they love or a runaway loop they didn’t intend.

The goal is not to penalise heavy use. It is to distinguish the heavy use you want more of from the heavy use that is quietly costing you money, and to respond to each appropriately.

FAQ

What is per-user LLM cost tracking? It is attributing every LLM API call — and its token cost — to the individual user, account, or tenant that triggered it, so you can see who drives spend rather than only the monthly total.

Why isn’t average cost per user enough? LLM usage follows a steep curve where a few accounts dominate. An average divides that skewed total across everyone and describes nobody, hiding both your cost whales and your unprofitable pricing tiers.

How do I implement it? Tag every call at the call site with a stable user identifier and the model used, carry that identifier across every provider, and roll spend up along it. Token cost tracking captures user, feature, and model on each call.

How does this help pricing? Per-user cost gives you cost-to-serve by account and by tier, so you can find structurally unprofitable plans, set defensible prices, and model the marginal cost of a new signup instead of guessing.

---

Per-user attribution turns an anonymous AI bill into a ranked, actionable list of who is really driving it. Start attributing spend with AI Vyuh FinOps token cost tracking, add budget alerts and anomaly detection per account, or browse more on the blog. Pricing across many tenants? Email finops@aivyuh.com or explore enterprise.