AI Cost Attribution for Product Teams: Tracking Which Features and Users Drive Your LLM Spend

Why Total Spend Is the Wrong Number to Watch

Your cloud provider bill tells you how much you spent on AI inference last month. It does not tell you whether that spend was justified, which features drove it, or which users are unprofitable to serve.

Consider a product with three AI-powered features: a document summarizer, an autocomplete assistant, and a research agent. Total monthly AI spend is $40,000. That number is actionable only if you know that the document summarizer accounts for $32,000 (79%), the autocomplete for $5,000, and the agent for $3,000.

Now the questions become concrete: Is the document summarizer generating enough value to justify its cost? Is it disproportionately used by free-tier accounts? What would happen to the unit economics if you capped document length or compressed prompts? None of these questions are answerable from a total spend number.

The three questions cost attribution lets you answer

Which features are unprofitable?

Compare per-feature AI cost to per-feature revenue contribution at your current usage mix.

Which user cohorts are too expensive to serve?

Compare cost per active user by tier to ARPU (average revenue per user). Free-tier power users are often the culprit.

Where should engineering invest in cost optimization?

The highest-cost features are the highest-leverage optimization targets. Focus engineering effort where it moves the total bill, not where it is technically interesting.

The Attribution Hierarchy: User, Feature, Team, Environment

Cost attribution works by tagging every LLM API call with metadata before it is sent. The tags become dimensions in your cost reporting. The hierarchy you define determines the granularity at which you can answer questions.

Level 1: Environment

productionstagingdevelopment

Staging and development calls should never appear in your production cost baseline. Without this tag, a load test or developer experiment can distort month-over-month comparisons and cause false cost alarms.

Level 2: Team or Service

platform-teamgrowth-teamml-infra

Multiple internal teams calling shared infrastructure need attribution so you can identify which team is consuming disproportionate capacity, enforce per-team budgets, and run internal showback reporting.

Level 3: Feature or Surface

doc-summarizerautocompleteresearch-agent

This is the highest-value dimension for product decisions. Per-feature cost lets you calculate unit economics for each surface, prioritize optimization work, and make informed decisions about feature sunset or throttling.

Level 4: User or Account

user_idaccount_iduser_tier

Per-user attribution identifies your most expensive users and lets you segment cost by pricing tier. The combination of user_id and user_tier reveals whether free-tier or paid accounts drive disproportionate cost.

Level 5: Request Type (optional)

batchrealtimebackground-job

If your architecture distinguishes between synchronous user requests and background processing, separating these lets you make different latency and cost tradeoffs for each. Background jobs are often candidates for cheaper or slower models.

Start with levels 1 through 3. User-level attribution (level 4) adds significant value but also adds complexity when users are anonymous or when you have a shared-account model. Add it once levels 1 through 3 are instrumented and reliable.

How to Instrument Your LLM Calls for Attribution

The instrumentation approach depends on whether you call model providers directly or through a gateway. Both work. The gateway approach is significantly easier to maintain at scale.

Direct API calls with logging middleware

Wrap every LLM call in a logging function that captures the tags, token counts from the response object, and calculated cost. Write these records to your data warehouse or a cost tracking service. Works well for small teams with one or two providers.

As provider count grows, each wrapper must handle different response formats and pricing structures. Maintenance burden scales linearly.

LLM gateway with metadata headers

Pass attribution tags as metadata headers or request fields to the gateway. The gateway logs every call with token counts, cost, latency, and your tags in a unified schema. The gateway handles provider differences so your application code stays clean.

Requires standing up and maintaining a gateway. The setup cost pays off once you have two or more providers or multiple teams sharing infrastructure.

The tagging schema is a product decision, not an engineering one

Engineering will implement whatever tagging schema you specify, but they cannot define the feature taxonomy for you. Before instrumentation begins, produce a canonical list of every AI-powered surface in your product with its official tag name. If two engineers tag the same feature differently, your attribution reports will be fragmented and useless. This happens constantly on teams that skip the upfront alignment step.

Learn Unit Economics in the AI PM Masterclass

The Masterclass covers cost attribution, unit economics, and the financial models AI PMs use to make shipping and pricing decisions. Taught live by a former Apple and Salesforce Sr. Director PM.

Cost vs. Value: Building the Per-Feature P&L

Once attribution is working, the next step is connecting cost data to value data. This produces a per-feature profit and loss view: what each AI surface costs to operate vs. what value it generates.

Cost inputs

Monthly AI inference cost (from attribution data)
Engineering time amortized over the feature lifetime
Customer support cost for AI-related issues
Evaluation and monitoring overhead

Value inputs

Revenue directly attributable to the feature (conversion lift, upsell, retention)
Cost savings vs. human alternative (support deflection rate x support agent cost)
Engagement signal delta (DAU, session length, action completion rate for users of the feature vs. without)
Strategic value: is this feature a differentiator that affects deal win rates?

Most AI features will not have clean revenue attribution. Start with what you can measure: cost savings on deflected support tickets, engagement lift, or conversion rate differences between users who engage with the AI feature and those who do not. Even a rough value estimate is better than no estimate when making prioritization decisions.

The goal is not accounting precision. It is giving you enough signal to answer: should we invest in making this feature better, hold it at current investment, or sunset it?

Setting and Enforcing Per-Feature Cost Budgets

Attribution without budgets is a reporting exercise. Attribution with budgets is a control plane. Once you know what each feature costs, you can set spending limits and have the infrastructure enforce them automatically.

Monthly budget alerts

Set a threshold (e.g., 80% of monthly budget) that triggers an alert before the budget is exhausted. This gives engineering time to investigate and throttle before the limit is hit, not after.

Hard caps with graceful degradation

When a feature hits its cap, the gateway returns a throttled response rather than an error. Design a fallback UX in advance: a cached result, a simplified output, or a clear message that the feature is temporarily limited.

Per-user consumption limits

Free-tier users who make heavy use of AI features can flip the unit economics of the entire tier. Per-user caps (daily or monthly token limits) protect against this without cutting off the average user.

Anomaly detection

A single runaway background job or a prompt injection attack that loops the model can exhaust budgets in minutes. Set anomaly thresholds that trigger automatic pause when per-minute spend exceeds a multiple of the normal rate.

Budget enforcement requires tight coordination between product, engineering, and finance. The PM owns defining the budget numbers and the degradation behavior. Engineering owns the implementation. Finance owns reconciliation against actual spend. Make sure all three parties have agreed on the policy before the system goes live.

The Cost Attribution Report: What to Publish and How Often

Attribution data is most useful when it reaches decision-makers in a consistent format on a predictable cadence. The following report structure works across most AI product teams.

Weekly cost dashboard (engineering and PM)

Per-feature spend this week vs. last week vs. budget. Call volume by feature. Cost per call trend. Any alerts triggered. Purpose: catch anomalies and regressions before they become monthly problems.

Monthly unit economics review (PM and finance)

Cost per active user by tier. Cost per feature as a percentage of revenue. Top 3 cost optimization opportunities. Budget vs. actual variance. Purpose: make decisions about pricing tier design, feature investment, and cost reduction priorities.

Quarterly strategic review (leadership)

AI cost as a percentage of gross margin. Cost trajectory vs. usage growth (is cost scaling linearly or are we improving unit economics?). Feature-level ROI summary. Purpose: demonstrate that AI investment is being managed responsibly and improving over time.