Your office building has one electricity meter. At the end of the month, you get a bill for the whole building. You know the total cost of electricity for the month. You do not know which floor consumed what, which tenant ran the servers that spiked the bill, or whether the conference rooms or the server rooms are driving the peak.
Most AI deployments start with the same problem. One API bill covers the entire organization. You know what you spent on AI this month. You do not know which product, which team, which feature, or which customer interaction drove that number.
Why Attribution Matters
Without attribution, you cannot make informed decisions. If one product is generating 80% of the AI spend but contributing 10% of the revenue, you cannot have that conversation. If one team is calling the same model fifty times per user session when ten would suffice, you cannot see it. The aggregate number tells you nothing about where to act.
Granular attribution changes the conversation. It lets product teams see the cost of their AI features. It lets finance allocate AI spend to the products that generate revenue from it. It lets engineering identify the calls that are wasteful before they compound into a budget crisis.
This is not hypothetical. Organizations that have deployed AI without attribution often discover, when they finally add metering, that a small number of features account for a large fraction of spend, and that some of that spend produces little measurable value. The visibility enables the conversation. The conversation enables the decision.
What Makes Attribution Hard
The difficulty is not the metering itself. Capturing token counts per request is straightforward. The difficulty is mapping those counts to organizational units in a way that is consistent and meaningful.
A single user request might touch multiple features. A single feature might use multiple models. A single model might serve multiple products. The attribution hierarchy you build has to reflect how your organization actually thinks about cost responsibility, not just the technical call graph.
Consider a customer support AI. The support feature uses a model. The model is shared across support and sales. The support feature serves multiple products. If the AI bill arrives as one number, you might conclude that “support AI” costs X. But if product A generates 70% of support volume while contributing 10% of revenue, the attribution story is more complicated. The meter has to be able to answer that question.
Building this mapping requires instrumentation upstream. User ID, session ID, feature flag, product line: these all need to travel with the request so that the cost can be allocated at the end of the billing period. If your tracing does not carry this context, you cannot attribute costs downstream. You end up with a meter that tells you the building total and nothing else.
The Metering Stack
Token counts per call are the starting point. Every API call returns usage data: input tokens, output tokens, sometimes cost per token depending on the provider. This is the raw measurement.
The attribution layer sits above this. It takes the raw token counts and assigns them to organizational dimensions: product, team, feature, customer segment. This assignment can happen at call time (attach metadata to each call and store it) or at reporting time (join call logs with product catalogs and user records).
Real-time attribution enables live dashboards and alerting. Batch attribution enables periodic reporting and budget reviews. Both are useful for different purposes. Real-time attribution matters when costs can spike unexpectedly and you need to respond quickly. Batch attribution matters for structured budget reviews and chargeback calculations.
The storage and processing for attribution is not trivial. If you are making millions of AI calls per day, storing per-call attribution metadata and joining it for reporting requires a data pipeline that is itself worth building and maintaining.
The Optimization Question
Attribution enables optimization, but optimization requires more than attribution. You need to know not just what something costs, but whether the cost is worth it.
A feature that generates 40% of AI spend and drives 60% of conversions is efficient. A feature that generates 40% of AI spend and drives 5% of conversions is wasteful, but only if removing it does not affect those conversions. Attribution tells you the spend. Attribution plus outcome measurement tells you the efficiency.
If your AI spend is growing faster than your revenue, the conversation is not just about which features cost the most. It is about which features justify their cost. Attribution is the starting point for that conversation, not the ending point.
Cost per Outcome
The most useful framing is cost per outcome, not just cost per call. A feature that costs $1000 per day but generates $10000 per day in revenue is more efficient than a feature that costs $100 per day but generates $50 per day in revenue.
Measuring cost per outcome requires linking AI spend to business outcomes. This is a data engineering problem as much as an AI problem. You need to be able to trace from a specific AI call to a specific user action to a specific business outcome. The chain is long and the data is often incomplete.
Organizations that build this tracing often find surprising results. Features that seemed expensive turn out to be essential. Features that seemed cheap turn out to be unnecessary. The data changes the conversation.
Real-World Scenario: The Feature Audit
An organization launches a new AI feature: personalized product recommendations on the homepage. The engineering team is proud. The feature uses a large model call for every page load. After a quarter, finance asks whether the feature is worth the cost.
The attribution system shows the feature accounts for 35% of total AI spend. The outcome analysis shows it drives 8% more conversions on the homepage. Finance calculates the revenue impact: 8% of homepage conversions times average order value equals $Y. The AI feature costs $Z. The calculation is straightforward: does $Y exceed $Z?
In this case, it does. The feature stays. But the same analysis applied to a different feature might reach a different conclusion. Without attribution and outcome measurement, both features would be treated the same: necessary because they exist.
Real-World Scenario: The Call Reduction Initiative
Engineering notices that one product’s AI costs have grown 300% in six months while usage has only grown 50%. The attribution system breaks down the cost by conversation type. It发现: the product is making 40 API calls per user session for a task that could be done in 5.
The cause is an architecture decision made during prototyping, when the team was building fast and not paying for inference. The same architecture survived into production. Attribution surfaces the problem. Engineering refactors to batch similar calls and cache responses where appropriate. The cost drops 60% without a noticeable change in user experience.
Attribution did not fix the problem. It identified where to look.
The Shared Infrastructure Problem
When multiple products share an AI infrastructure, attribution gets harder. The model serves all products. The API bill is one number. You need to divide that number across products in a way that reflects actual usage.
Simple division by call count is often wrong. A product that makes twice as many calls may be making twice as many cheap calls while another product makes half as many expensive calls. The cost per call varies by request complexity.
Dividing by compute time is more accurate but harder to measure. It requires instrumentation that captures not just token counts but actual GPU time consumed per request. This instrumentation is not always available from the model provider.
The right attribution method depends on what the provider exposes and what level of accuracy you need. For rough budget allocation, call counts may suffice. For chargeback to specific teams, you may need compute time.
Cost Comparison Across Providers
AI costs vary across providers and across model versions within the same provider. A call to GPT-4 costs more than a call to GPT-3.5. A call to Claude costs different from a call to Gemini. A call to a open-source model hosted on your own infrastructure has different cost structure than any of these.
Attribution should capture not just total spend but spend by provider and model. This enables cost comparison: is product A using an expensive model when a cheaper one would suffice? Is the premium for the latest model version worth the improvement in output quality?
This comparison requires attribution that tracks provider and model version, not just total token counts. If you only know total spend, you cannot make these distinctions.
The comparison also requires outcome measurement. A cheaper model that produces lower quality outputs may cost less per call but require more human review, negating the savings. The cost comparison has to account for total cost of quality, not just API cost.
The Cost of Complexity
Building a sophisticated attribution system has its own costs. You need instrumentation engineering, data pipelines, dashboards, and processes. The attribution system itself becomes something to build, maintain, and trust.
This cost has to be justified by the decisions it enables. If your total AI spend is $10,000 per month and is not growing, the ROI on a six-month attribution engineering project may be negative. If your AI spend is $500,000 per month and growing, attribution engineering pays for itself in the first optimization cycle it enables.
The complexity of attribution should match the complexity of your AI usage. Simple per-feature attribution may be enough for a small organization with a handful of AI features. Multi-dimensional attribution with real-time dashboards may be necessary for a large organization with complex shared infrastructure.
The Free Rider Problem
Without attribution, you get the free rider problem. One team invests in optimizing their AI usage. The savings appear in the aggregate bill, which benefits everyone. The team that invested gets no specific benefit, while all teams share the savings.
Attribution changes the incentive structure. Teams that optimize their AI usage see the savings reflected in their specific attribution. The investment in optimization has a clear return for the team making it.
This is why internal cost allocation works better than internal subsidies. If a central team absorbs all AI costs and provides AI capabilities for free to product teams, there is no incentive for product teams to use AI efficiently. If product teams see the cost of their AI usage, they have reason to optimize.
The Dark Spend Problem
Without attribution, you may have what finance calls “dark spend”: AI costs that you cannot explain. They appear in the bill but you cannot trace them to a product, a team, or a feature. They may be growing, but you do not know why.
Dark spend is a governance problem as much as a measurement problem. If you cannot trace costs, you cannot control them. If you cannot control them, they will grow until someone notices and demands action.
Attribution eliminates dark spend by making every cost traceable. When every dollar of AI spend is attributed to a product and a team, no spend can hide. The product team sees their costs. They own them. They optimize them.
Real-World Scenario: The Budget Crisis
A company experiences an unexpected AI bill spike. The bill is 40% higher than projected. Without attribution, the CFO demands answers from engineering, and engineering cannot provide them. The best they can say is “we used more AI than we expected.”
With attribution, engineering can tell the CFO exactly what happened. A new feature launched three weeks ago, and its AI costs have grown faster than expected. The feature is generating revenue, but at a higher cost per conversion than projected. The CFO has the information needed to decide whether to optimize the feature, increase the AI budget, or accept the higher costs.
Without attribution, the budget crisis would have led to across-the-board AI restrictions that would have affected features that were working well. With attribution, the response was targeted.
Real-World Scenario: The Provider Migration
An organization has been using one model provider for two years. A competing provider releases a new model that is significantly cheaper for equivalent quality. The organization wants to know whether migration would be worth the engineering effort.
Attribution data shows exactly how much they are spending on each model, each feature, each call type. The comparison is precise: if they switched providers, they would save X dollars per month. The engineering cost of migration is Y. The payback period is Y divided by X.
Without attribution, they cannot make this calculation. They do not know how much each feature costs, so they cannot know whether migration would save money or whether it would require trade-offs in quality or capability that cost more than the API savings.
Attribution makes the business case for infrastructure investments visible.
Decision Rules
Implement granular attribution when:
- AI spend is large enough to warrant dedicated budget conversations
- Multiple teams or products share an AI infrastructure budget
- You need to evaluate the cost-effectiveness of specific AI features
- You have or are building the instrumentation infrastructure to carry attribution context
- You are making decisions about which AI features to invest in or cut
- You want teams to have incentive to optimize their AI usage
- You are considering provider migration and need to understand the economics
- You need to explain AI costs to finance or leadership
Do not implement granular attribution when:
- AI spend is small relative to other infrastructure costs
- A single team owns the entire AI budget and has direct control over all usage
- The engineering cost of carrying attribution context exceeds the organizational benefit
- Your organization is not ready to act on cost information even if it had it
- You are still in the exploration phase and do not yet know which features will survive
- Your model provider does not expose usage data at a granularity you can capture
- Your AI usage patterns are stable and you have no cost concerns
A single meter is fine for a shed. It is not fine for a campus with multiple tenants who need to know their share. The meter is not the goal; the decisions it enables are the goal.
