AI Unit Economics: Tracing Token Spend Back to the Teams That Create It

Here is a conversation that happens in a lot of companies right now. Finance asks why the AI line grew 40 percent last month. Engineering says usage went up. Finance asks which product drove it. Engineering says it is hard to tell, because everything goes through one API key. Finance asks whether the growth is profitable. Nobody knows, and the meeting ends with a vague commitment to look into it.

That is not a tooling failure so much as a measurement gap. AI spend arrives as one undifferentiated number, and unlike a cloud bill, there is no instance to tag or resource to label. A million dollars of token spend can look completely uniform on the invoice while being generated by twelve teams, forty features, and a handful of customers with wildly different margins. AI unit economics is the discipline that closes that gap: it attributes spend to what caused it, then expresses it per unit of business value, so growth and waste stop hiding inside each other.

Why AI Spend Resists Normal Cost Allocation

Cloud cost allocation has a well-established playbook: tag resources, map accounts and subscriptions to teams, apply rules to the shared remainder. That playbook, which we cover in our engineering guide to cloud cost allocation, breaks down on AI spend for a structural reason. There is no resource to tag.

When a team provisions a virtual machine, the machine exists, persists, and carries metadata. When a team makes an API call to a model provider, the call happens, bills, and disappears. The provider's invoice knows the API key, the model, and the token count. It does not know which product made the call, which feature it served, which customer triggered it, or whether it was a retry. That context exists only in your application at the moment of the request, and if you do not capture it there, it is gone permanently.

This inverts the usual order of operations. In cloud FinOps, you can often reconstruct allocation after the fact from billing data and resource metadata. In AI FinOps you cannot, because the billing data is too thin. Attribution has to be designed into the application before the spend happens, which makes it an engineering decision rather than a finance one, and explains why so many organizations discover the gap only when the bill gets big enough to ask about.

The Metadata That Makes Attribution Possible

Everything in AI unit economics depends on what you attach to each model call. The good news is that the minimum viable set is short, and adding it is usually a small change in a shared client wrapper rather than a project.

The request or trace ID deserves particular attention in 2026, because agentic systems have broken the assumption that one user action equals one model call. A single agent task may involve planning calls, tool calls, retries, and a summarization pass, spread across two or three models. Without a shared identifier tying them together, you can measure cost per API call, which tells you almost nothing, but not cost per user action, which is the number the business actually cares about.

Choosing the Right Unit

Unit economics means nothing until you pick a unit, and the right one depends on how your business makes money. Three units cover most cases, and mature teams track more than one.

Cost per request or per action

The engineering unit. It answers whether a feature is getting more or less efficient over time, and it is the one that responds directly to optimization work: routing, caching, prompt trimming, and output caps all move it. It is also the earliest warning of trouble, because it rises before total spend does in a growing product.

Cost per feature

The product unit. It answers which capabilities are expensive to run, which is the input product managers need to decide what to build, what to gate behind a paid tier, and what to optimize. A feature that costs $0.40 per use and drives retention is a good investment; the same cost on a feature nobody uses is a line item to cut.

Cost per customer

The business unit, and the one that decides margin. In multi-tenant AI products, usage varies enormously between customers, and a small number of heavy users can consume a disproportionate share of spend. Without per-customer cost you cannot tell a profitable enterprise account from a loss-making one, and pricing becomes guesswork. This connects directly to the margin question we examine in our guide to AI gross margin and SaaS profitability.

Handling Shared and Unattributable Costs

Some AI spend genuinely does not belong to one team, and pretending otherwise produces numbers nobody trusts. Shared GPU clusters, embedding pipelines that serve several products, fine-tuning runs, evaluation harnesses, and the platform team's own tooling all fall into this category. The answer is not to leave them in an unallocated bucket, which grows until every team assumes its rivals are hiding there.

Instead, define an explicit rule and publish it. Allocate by measured usage where you can measure it, for example splitting a shared GPU cluster by GPU-hours consumed per namespace or per job. Allocate by an agreed proportion where you cannot, for example splitting a shared embedding pipeline by the number of documents each product contributed. Either way, the rule should be simple enough to explain in a sentence and stable enough that teams can plan against it. Teams will accept a number whose logic they can see; they will fight a number that appears from a black box.

Making the Numbers Change Behavior

Allocation that nobody acts on is just a more detailed invoice. Three practices turn the data into decisions.

• Give every number an owner. Each team, feature, and shared pool needs a named person who sees its cost and can change it. Cost that belongs to everyone belongs to nobody.
• Show cost where decisions are made. A monthly report is too slow for a system where a prompt change can double spend overnight. Engineers need per-request cost in the same place they see latency and error rates.
• Judge trends in unit terms, not totals. Rising total spend with falling cost per request is a business growing efficiently. Flat total spend with rising cost per request is a business quietly getting worse. Only the unit view distinguishes them.

This is where AI unit economics stops being a reporting exercise and becomes the shared-accountability practice described in our guide to FinOps for AI, and in the wider principles of FinOps.

A Worked Example

A company spends $80,000 a month on model APIs through a single key, and the number has grown steadily for two quarters. After instrumenting calls with team, feature, environment, and customer metadata, the picture resolves in about three weeks.

Two features account for 70 percent of spend. One is a document-summarization feature used by most customers, running on a frontier model because that is what the prototype used; moving it to a mid-tier model and caching the shared system prompt cuts its cost by roughly three-quarters with no complaints. The other is an agentic research feature that makes an average of 34 model calls per user action, most of them retries caused by a brittle tool integration; fixing the integration removes most of them.

Two smaller findings matter as much. Staging accounts for 11 percent of total spend, mostly an evaluation suite running on the most expensive model against production-sized inputs, which moves to batch on a cheaper model. And three enterprise customers on a flat-rate contract consume 22 percent of tokens, which reframes the next renewal conversation entirely. None of these were visible in the $80,000 total; all of them were obvious once the spend had labels.

Where This Gets Hard

Two honest difficulties are worth naming, because glossing over them is how these programs stall.

The first is that instrumentation requires engineering buy-in at the point where it feels like overhead. Adding metadata to every model call is simple, but it has to happen in the code path, usually in a shared client wrapper, and it competes with feature work. The argument that lands is not governance but debugging: the same metadata that enables cost allocation also tells engineers which feature regressed, which model is slow, and where retries are concentrated. Framed as observability rather than accounting, it gets built.

The second is that perfect attribution is unreachable, and chasing it delays everything. Some calls will be genuinely ambiguous, some shared costs will need an arbitrary split, and some legacy paths will never be instrumented. Attribute the large majority, document a defensible rule for the rest, and start acting on the data. A model that explains 90 percent of spend today is far more valuable than a perfect one that arrives next year.

The Bottom Line

AI unit economics is what turns an AI bill from a number you receive into a number you can reason about. The mechanism is unglamorous, attach metadata at the call, aggregate it into allocated cost, divide by a unit that matters to the business, and give each result an owner. But the effect is substantial, because it separates the two things a single invoice fuses together: spend that is buying growth and spend that is buying nothing.

Start with the smallest version that works. Instrument team, feature, environment, and model on every call, publish cost per request per feature, and give each feature an owner who sees it weekly. That alone answers the question finance opened with, and it does it before the bill grows large enough that the answer is expensive.