Your provider dashboard can tell you that model spend reached $12,000 last month. It cannot tell you whether the increase came from a successful feature, an unprofitable customer, a retry loop, or an employee tool that nobody owns.
That gap is the difference between AI cost tracking and AI cost attribution. Tracking totals the bill. Attribution connects each cost to the business activity that created it, then makes the result useful for product, engineering, and finance decisions.
Useful attribution connects raw provider and runtime evidence to the business dimensions and outcomes that teams actually manage.
What is AI cost attribution?
AI cost attribution is the process of assigning model, tool, and infrastructure costs to the customer, feature, workflow, agent, team, or outcome that caused them.
A useful attribution record answers five questions:
- What was consumed? Provider, model, service tier, token classes, tools, cache use, retries, and runtime resources.
- Who or what caused it? Customer, user, feature, workflow, agent, employee, team, and environment.
- What did it cost? The provider-reported usage priced with the applicable rate, plus any allocated shared costs.
- What value did it create? A resolved ticket, generated report, merged pull request, completed workflow, retained customer, or another measurable outcome.
- Can the number be defended? The calculation preserves its source, pricing version, allocation rule, and reconciliation status.
The FinOps Foundation's Unit Economics capability makes the key distinction: technical measures such as cost per token are useful, but business measures such as cost per tenant, transaction, or resolved case connect technology spend to value.
Why a provider total is not enough
Model providers bill different usage classes separately. Current pricing pages distinguish combinations of uncached input, cached input, cache writes, output, reasoning, tools, batch processing, and service tiers. You can see this directly in the official pricing documentation from OpenAI, Anthropic, and Google.
That means a single total_tokens × model_price estimate is often too crude. It can hide:
- output tokens that cost more than input tokens
- provider-managed cache reads and writes with different rates
- reasoning or multimodal usage
- separately billed tools, grounding, or retrieval
- batch, priority, flex, or reserved-capacity economics
- retries and failed workflows that consumed money but produced no value
Provider dashboards are still essential evidence. They are just the start of the calculation, not the business answer.
Build the cost record before the dashboard
Start with an auditable cost record for every request or agent step. A simplified variable-cost formula looks like this:
Do not flatten the inputs after calculating the total. Preserve the quantities, rates, currency, provider response identifiers, model version, service tier, and pricing source. If a provider later corrects usage or an invoice does not match telemetry, you need enough evidence to explain the variance.
OpenTelemetry's generative AI semantic conventions provide a useful base vocabulary for provider, model, operation, and token usage. Business context still needs to come from your application, identity system, or workflow engine.
The useful output is not another provider total. It is a defensible link from raw consumption to the owner and business decision behind it.
Attach business context at the moment of work
The most reliable attribution data is available while the request is being made. Your application already knows the customer, feature, workflow, or job that initiated the call. Attach stable identifiers there, then enrich them later with names, ownership, plan, revenue, or organizational hierarchy.
A practical event can carry dimensions like these:
| Dimension | Example | Decision it supports |
|---|---|---|
| Customer | tenant_42 | Cost to serve and gross margin |
| Feature | support_reply | Packaging and roadmap priority |
| Workflow | ticket_resolution | Cost per successful outcome |
| Agent and run | support_agent, run_918 | Loop, retry, and tool-step waste |
| Team | customer_platform | Ownership, budgets, and chargeback |
| Environment | production | Separate real demand from tests |
| Employee | user_173 | Internal AI adoption and policy |
Use opaque IDs instead of customer names or emails in telemetry whenever possible. Join human-readable labels in a controlled system. This improves consistency and reduces unnecessary personal data in the cost pipeline.
Provider usage, pricing version, tools, retries, and shared runtime cost.
Customer, feature, workflow, run, team, environment, and employee.
Cost per customer, feature, successful outcome, and attributable margin.
Price, package, budget, optimize, or investigate with the evidence attached.
Move from request cost to unit economics
Once cost and context are joined, aggregate around decisions rather than around invoices.
Cost per customer
The average is useful for planning, but the distribution is usually more actionable. Segment customers by plan, cohort, geography, or usage pattern. One customer with a runaway agent may look harmless inside a company-wide average.
Cost per feature
Compare cost with adoption, retention, revenue, or another feature outcome. Rising spend can be healthy when value rises faster. A low-cost feature can still be a poor investment if nobody uses it.
Cost per successful outcome
This measure catches waste that cost per request misses. If an agent retries four times before resolving a ticket, the request-level chart shows five ordinary calls. The outcome-level metric shows the full economic cost of one resolution.
- Per request
- $0.009
- Per run
- $0.045
- Failed-run cost per 1,000
- $9.90
At 78% success, 220 of 1,000 runs consume cost without a successful outcome. Shared infrastructure, tools, cache discounts, and review cost are not included.
Open the full calculator
Request price is only one input. Retry loops, tool calls, and failed runs determine the economics of the outcome.
AI gross margin
Be explicit about which costs are included. Direct model spend, shared gateway cost, GPU commitments, observability, and human review can each be valid, but mixing definitions between reports destroys trust.
A six-step implementation plan
1. Preserve provider evidence
Store provider-reported usage and identifiers when available. Mark estimates as estimates. Record the pricing source and effective date used for each calculation.
2. Normalize without erasing detail
Map providers into a common schema while retaining provider-specific fields. Cached input is still input, but its billed rate and behavior differ. Reasoning tokens may be included in an output total while also being useful as a separate diagnostic field.
3. Add stable attribution keys
Define a small required set, such as customer, feature, workflow, team, and environment. Keep the names consistent across services. Reject or quarantine malformed identifiers before they fragment your reports.
4. Define shared-cost rules
Some costs do not belong to one request. Allocate commitments, gateways, GPU idle time, or platform fees with a documented rule. Common methods include proportional usage, reserved capacity, equal split, or direct assignment. Show unallocated cost instead of silently hiding it.
5. Reconcile to bills
Compare normalized telemetry with provider invoices or billing exports on a regular cadence. Investigate timing, credits, minimum commitments, taxes, currency, late-arriving usage, and unsupported token classes. Attribution built on an incomplete total creates precise-looking fiction.
6. Connect cost to outcomes
Join operational outcomes only after cost evidence is stable. Start with one decision-ready unit, such as cost per resolved support ticket or cost per generated report. Expand when owners agree on the definition and use it in reviews.
Metrics worth putting on the first dashboard
Avoid launching with dozens of charts. Start with a compact operating view:
- total AI cost with telemetry-to-bill reconciliation status
- cost by customer, feature, team, and workflow
- cost per successful outcome
- AI contribution margin by customer or plan
- retry, failure, and abandoned-workflow cost
- cache write, cache read, and uncached input cost
- model and service-tier mix
- unattributed and unallocated cost percentage
Every chart should link back to the cost records behind it. A metric becomes much more useful when an engineer can move from a margin change to the exact workflows, models, and usage classes that caused it.
Common failure modes
Treating gateway cost as final truth. Gateways are valuable telemetry sources, but streaming, asynchronous jobs, routed model aliases, custom pricing, and provider corrections can create gaps. Keep independent evidence and reconcile it.
Using customer names as identifiers. Names change and collide. Use stable IDs, then join names for display.
Measuring only successful calls. Failed and abandoned work is part of cost to serve. Keep outcome status separate from billability.
Forcing every cost into a customer bucket. Internal experiments, shared capacity, and employee tools may have different owners. Preserve an explicit unattributed or shared category until a defensible rule exists.
Optimizing the cheapest model without quality evidence. A lower request price can increase retries, human review, or failed outcomes. Compare total outcome cost and quality before making a swap. Our AI coding agent cost and token benchmarks show how to structure that comparison with identical tasks and measurable evidence.
The practical starting point
Choose one high-volume workflow with a clear owner and outcome. Instrument its provider usage, customer, feature, run, team, and success state. Reconcile the total for one billing period. Then calculate one technical unit metric and one business unit metric.
For example:
- technical: cost per support-agent run
- business: cost per resolved support ticket
That pair gives engineering a controllable signal and leadership a value signal. Once both are trusted, repeat the pattern across features, customers, employee tools, and agent workflows.
trAIce is built for this model. It measures product and employee AI usage without placing a hosted gateway in the request path, keeps prompt capture opt-in, and connects cost records to customer, feature, user, team, agent, and outcome context. Try the AI cost calculator, compare plans, start free, or explore the interactive demo.