Who's Actually Spending Your AI Budget? Cost Attribution by Feature and Tenant

Most teams can tell you their total LLM bill. Almost none can tell you which feature, tenant, or user drove it. Attribute every request to a feature, tenant, and user at call time, and the spend distribution almost always turns out to be a Pareto curve: a small slice of usage — often one aggressive tenant or one runaway feature — accounts for the majority of cost.

Quick answer: Tag every LLM call with feature_id, tenant_id, and user_id metadata at the point of the request, pipe it into your usage logs, and aggregate cost by dimension. Without that tagging, you're optimizing a blended average that no single customer or feature actually resembles.

Why a Blended AI Bill Lies to You

A single monthly number from your model provider tells you what you spent, not why. It averages together a low-cost autocomplete feature, a token-hungry document summarizer, and one enterprise tenant running batch jobs overnight. Optimizing against that average means you're guessing.

The blended bill problem is structurally the same one finance teams solved decades ago with activity-based costing: you can't manage a cost center you haven't decomposed into its actual cost drivers. Robert Kaplan and Robin Cooper's original activity-based costing research at Harvard Business School made the case that overhead allocated by broad averages (like headcount or revenue share) systematically misattributes cost to the wrong products — and management acts on the wrong signal as a result. LLM spend is overhead with the same failure mode, just newer.

Three symptoms tell you your organization has this problem:

• Nobody can answer "which feature is our most expensive to run" without a special one-off analysis.
• Pricing and packaging decisions are made off gross margin, not feature-level margin.
• A single customer complaint about "AI is slow" can't be traced to whether that tenant is simply sending 50x the request volume of everyone else.

Instrument Every Call: The Metadata Checklist

Attribution is only as good as the metadata attached at request time — retrofitting it from logs after the fact is unreliable because raw provider logs rarely preserve business context. Add a structured metadata block to every LLM call before you ship the feature, not after finance asks for a breakdown.

At minimum, tag each request with:

Where This Metadata Lives

Most teams pass this as a wrapper object around their model client call, then emit it to whatever event pipeline already handles product analytics — Segment, a Kafka topic, or a warehouse table. The point isn't the specific tool; it's that cost data joins the same dimensional model as your product usage data, so you can slice cost by the same feature and account IDs your product analytics already use.

Handling Multi-Step and Agentic Calls

A single user action can trigger a chain of model calls — a planning call, tool calls, a synthesis call. Tag every step with a shared trace_id and the same feature_id/tenant_id, or you'll undercount the true cost of agentic features by only capturing the final call. This matters more every quarter as agentic workflows spread; see our breakdown of routing requests to cheap, fast, or default-tier models for how step-level tagging also unlocks per-step routing decisions.

Build the Attribution Pipeline, Not Just a Dashboard

A cost dashboard that shows "total spend over time" is not attribution — it's a restatement of the invoice. Real attribution requires a join between your usage events and either your billing API's per-request cost or a computed cost model based on token counts and published per-token pricing.

The pipeline has three stages:

1. Capture — every call emits the metadata block above, logged at request time, not reconstructed later.
2. Cost — join token counts against current model pricing (or your provider's cost API where available) to get a dollar figure per call.
3. Aggregate — roll up by feature_id, tenant_id, and user_id independently, so you can answer "which feature" and "which tenant" as separate questions.

Keep the raw per-call records, not just aggregates. When a monthly total spikes, you'll want to drill from feature-level to tenant-level to individual-request level without re-instrumenting.

What to Watch Weekly

Once the pipeline exists, a few standing views catch most problems early:

• Cost per feature, week over week — catches a feature whose prompt or context window silently grew.
• Cost per tenant vs. tenant's contract tier — catches free-tier or lower-tier accounts consuming disproportionate spend.
• Cost per active user, by feature — catches abuse or bot-like usage patterns hiding inside a normal-looking tenant total.

The Pareto Distribution Attribution Reveals

Once you split blended spend into feature x tenant x user, the shape is rarely flat. It resembles the classic 80/20 pattern Vilfredo Pareto first observed in wealth distribution and that Joseph Juran later generalized into quality management as the "vital few and trivial many" — a small number of causes driving most of the effect.

A realistic (illustrative, not a live customer) breakdown might look like this:

The top handful of accounts routinely account for a wildly disproportionate share of spend relative to their request volume — usually because they're sending longer inputs, requesting larger outputs, or hitting a feature with a bloated system prompt.

The Enterprise-Tenant Abuse Pattern

A common pattern once you look at tenant-level attribution: one enterprise account, often your largest logo, dominates total AI cost — not because of malice, but because of an integration pattern nobody reviewed. A batch job re-summarizing an entire document library nightly. A support-triage feature re-sending full conversation history on every turn instead of just the delta. A power user with a script calling your API in a loop.

None of these show up in a blended average. They only surface when you can filter cost by tenant_id and feature_id simultaneously and see one cell in that matrix light up. Once you can see it, the fix is usually cheap: cap context window growth, add pagination to batch jobs, or move the tenant to a rate-limited plan tier — all far less expensive than model-level cost cuts. Two levers worth checking first are whether a semantic cache would deduplicate repeated queries from that tenant, and whether prompt caching mechanics apply to a system prompt that's being resent unchanged on every call.

Turn Attribution Into Pricing and Roadmap Decisions

Attribution data is only valuable if it changes a decision. The two decisions it should inform most directly are pricing (does this tenant's usage pattern fit their contract) and roadmap (which feature's cost trajectory needs engineering attention before it needs a price increase).

Pricing Decisions

Roadmap Decisions

Feature-level attribution turns "AI is expensive" from a vague finance complaint into a specific, scoped engineering problem: this feature, this cost driver, this fix. That's a fundamentally different conversation than asking engineering to "reduce AI costs" against no target.

It also sharpens trade-off conversations between features competing for the same optimization budget — the same discipline covered in our complete guide to trade-off analysis for product teams, which walks through weighing competing constraints (cost, latency, quality) against each other systematically rather than by gut feel.

Where Prodinja Fits

Key Takeaways

• A single blended LLM bill hides which feature, tenant, or user actually drives cost — you need dimensional attribution to see it.
• Tag every call with feature_id, tenant_id, user_id, model, token counts, and cache status at request time, not reconstructed after the fact.
• Cost attribution almost always reveals a Pareto distribution: a small share of requests, often from one enterprise tenant, drives a disproportionate share of spend.
• Multi-step and agentic calls need a shared trace_id so you don't undercount chained model calls as a single cheap request.
• Attribution data should directly change two decisions: whether a tenant's contract tier matches their usage, and which feature's cost trajectory needs engineering attention.
• Checking for caching opportunities (semantic and prompt-level) is usually the cheapest fix once you've identified the cost driver.