Tokenomics Is Not the Answer, Cost Attribution Is

The industry has converged on a neat idea: the token is the atomic unit of AI value. Measure tokens the way cloud FinOps measured instance-hours, and AI spend becomes manageable.

The first half of that is right. The second half is where it goes wrong.

Nobody ever ran a cloud business by managing instance-hours. They ran it on cost per customer, cost per environment and gross margin per product line, and the instance-hours sat underneath as plumbing that a platform team owned and a finance team never saw. AI is at the stage where the plumbing is still being mistaken for the dashboard.

So let us be blunt about it. Tokenomics is real, it is genuinely difficult, and it is not the answer. No CFO should have to know what a cache write costs, or which of their providers counts cached tokens inside the prompt total. The answer is cost attribution: what did this customer, this feature, this team actually cost us, and was it worth it.

First, the Scene: a Token Is Not One Thing

Start with why tokenomics is hard, because the difficulty is real and it is worth understanding before dismissing it as the wrong altitude.

Most teams assume the measurement problem is already solved. They count tokens, so they think they know what they spent. They do not, because the atomic unit is not atomic. Here is what sits inside a single production request, and roughly what each class costs relative to the base input rate:

Input. Fresh prompt content the model has not seen before. Call it 1x, the baseline.
Cached input. Prompt content served from a warm cache, at roughly a tenth of the input rate on some providers and a quarter to a half on others. The largest single lever in most agent workloads.
Cache writes. What it costs to put content into the cache in the first place, at a premium over the input rate. You pay more once in order to pay a fraction thereafter, and providers offer several cache lifetimes at different prices.
Output. Generated text, usually three to five times the input rate, and more on reasoning models.
Reasoning. Billed at the output rate, for text your user never sees. Often the majority of the generation cost.
Audio and images. Priced on entirely separate scales. An audio token is not comparable to a text token in any useful way.
Tool and search calls. Built-in web search is billed per search, in dollars per thousand calls, and appears in no token count at all.

So a request reported as "22,700 tokens" is a sum of things whose unit prices differ by a factor of fifty, and the arithmetic goes wrong quickly if you flatten it. A typical agent request carrying a large cached system prompt costs about 2.85 cents when the classes are priced separately, and about 8.25 cents when the prompt is counted flat at the input rate. Nearly three times out, on one request, in the direction that makes you kill a feature that was actually profitable.

Worse, the same flat calculation is wrong in the opposite direction on the first request of a session, when that prompt is being written to the cache rather than read from it. Across a month the two errors partly cancel, which is precisely why the total looks defensible while the per-feature economics underneath it are not.

That is the scene. It is genuinely intricate, it is easy to get wrong, and everything built on top of a bad token model inherits the error.

But It Still Answers None of the Questions

Now assume you have solved all of that. Every request, every class, correctly priced. A perfect token count.

You still cannot answer a single question that gets asked in a board meeting:

What does it cost us to serve our largest customer, and are they profitable?
Is the AI feature we launched in March making money or subsidising itself out of the marketing budget?
How much of last month's spend was production traffic, and how much was engineers experimenting?
If usage doubles next quarter, what happens to gross margin?
Which of our plans is underpriced for the way people actually use it?

Token counts answer none of these, because a token measures volume and none of those questions are about volume. They are about who, what and why. The gap between a perfect token count and those answers is not more precision. It is a different axis entirely.

That is how teams end up having invested heavily in token telemetry and owning a beautiful chart nobody can act on. They measured the substrate very well and never attached it to the business.

And the intricacy above is an argument for automating that layer, not for elevating it. It should be solved exactly once, in the plumbing, by something that already knows every provider's conventions, and then never surface in a finance conversation again. If your CFO is being asked to reason about cache tiers, something has been pushed up the stack that should have stayed down it.

What Replaces It

Cost attribution means every request carries the business context that produced it, captured at the moment it happens: which customer, which feature, which environment, which team. Price the token classes correctly underneath, then roll the result up along those dimensions.

That produces the numbers a finance team can actually use:

Cost to serve, per customer. The only way to know which accounts are profitable, and the only defence against a heavy-tail usage pattern where a handful of accounts consume many multiples of the median.
Cost per feature. Whether the thing you shipped pays for itself.
Cost per outcome. Per resolved ticket, per document processed, per review completed. The figure that lets you compare an architecture change against a price change on equal terms.
Production versus development split. Internal experimentation belongs in R&D, not cost of revenue. Mixed together, production looks worse and R&D looks cheaper than either really is.

Every one of those is a sentence a CFO can act on without ever using the word token.

The Part You Cannot Fix Later

Attribution has one property that makes it urgent rather than merely desirable: it cannot be backfilled.

A provider invoice records that a key spent an amount in a month. It does not record which customer, which feature or which environment generated that spend, and no amount of later analysis reconstructs a dimension that was never captured at the moment of the request.

If you have shipped two quarters of AI features without per-request attribution, those two quarters are permanently unattributable. You cannot go back and ask what the enterprise tier cost to serve in Q2. The data to answer it does not exist anywhere, in any system, at any price.

That is unlike most reporting gaps, where the history can be rebuilt from source records. Here the source records were never written. The only available fix is to start capturing now so that the next two quarters are answerable.

Attribution Has to Beat the Invoice

Getting the dimensions right is half of it. The other half is timing, and this is where otherwise well-run programmes fail.

Behaviour changes on day 3. The invoice arrives on day 35. The board sees it on day 50. By then the product has shipped twice more and the cause is archaeology.

That lag would be tolerable if AI spend moved like cloud spend, grinding up and down in predictable increments. It does not, for two reasons.

It is non-deterministic. The same prompt does not reliably produce the same response, so it does not reliably consume the same tokens. You cannot forecast an individual request, only a distribution, and distributions have tails. A change in model, prompt or reasoning setting shifts the whole distribution without any visible change in the product.

It is agentic. One user action can fan out into dozens of model calls, and adding another agent to a chain is a configuration change rather than a hiring decision. Consumption multiplies without anything that looks like a launch.

Against a signal that behaves like that, a monthly invoice has a sampling rate of once per billing cycle. It is the wrong instrument. Budget alerting is the right one, and it needs to be more specific than a single company-wide number:

Thresholds that fire before the limit, not at it. A warning at 50 and 75 percent leaves room to act. An alert at 100 percent is a notification that the money is gone.
Burn rate, not just level. Project the current run rate to period end and alert on the trajectory. Spend on track to finish at triple budget is worth knowing on day 6, while it still looks small in absolute terms.
Budgets at the grain you can act on. One organisation-wide figure tells you something is wrong. A budget per key, feature, environment or customer tells you what.
A cadence measured in hours. The entire point is to beat the invoice. Anything reporting monthly has already conceded.
A deliberate decision about blocking. Alerting and enforcement are different. Most teams want to know immediately and decide themselves rather than have production start failing because a threshold tripped overnight. Hard caps have their place, usually on development keys and experiments rather than customer-facing traffic, but that should be a choice rather than a side effect.

Alerting without attribution is a smoke alarm with no address. You know spend is up, but not which feature, model or customer moved, so you cannot act. Attribution without alerting is a very good post-mortem. Only the pair closes the loop: detect, attribute, act.

And Only Then Can You Price

There is a harder question waiting downstream, and most companies building on top of LLMs have not answered it: how do you price your own product when your input cost is variable, usage is unpredictable, and your supplier can reprice under you with a blog post.

The honest answer is that you cannot price what you cannot attribute. Every available pricing model needs the same input:

Raising prices across the board needs to know the average cost to serve, or you are guessing at the increase.
Seat pricing with fair-use ceilings needs the usage distribution, because the ceiling only works if you know where the tail starts.
Usage-linked or credit pricing needs a defensible cost per unit, or you are reselling tokens at an unknown margin.
Outcome pricing, charging per resolved ticket or per document, needs cost per outcome above all, since that is the exact unit you are selling.

Without attribution, every one of those is a guess dressed as a strategy, and the first time a provider changes its rates you find out which. With attribution, repricing becomes arithmetic: you know what each unit costs today, so you know what a rate change does to margin before it hits.

The Point

Tokenomics is worth understanding. It is the physics of the thing, and getting it wrong quietly corrupts every number built on top of it.

But it is not the management layer, and treating it as one is why so many AI cost programmes produce dashboards nobody acts on. The token is the unit your provider bills in. It is not the unit your business runs on.

Attach every request to a customer, a feature, an environment and a team. Price the token classes correctly underneath, once, and never mention them again. Put budgets and burn-rate alerts on the same data so you find out in hours rather than at month end.

Then the conversation stops being about tokens and starts being about whether this customer is profitable, whether this feature pays for itself, and what to charge. Those are the questions that were being asked all along.

The Simple Version

For anyone about to build this, it is simpler than the preceding sections make it sound.

Tag every request, at the moment it is made, with the customer, the feature, the environment and the team. That is the whole ask. It is a header on a request, not a project.

Everything underneath should be somebody else's problem: pricing each token class at its own rate, tracking exact model versions as they silently repoint, keeping up with provider conventions that genuinely do conflict with each other, and catching the billed events that are not tokens at all. That layer is fiddly enough that we mispriced a cached-token calculation ourselves and corrected it earlier this year, which is an argument for not hand-rolling it rather than an invitation to go and study it.

So wire cost attribution in from the first request. It costs almost nothing on day one, it is the only part of this you cannot add later, and it is what turns a token count into an answer.

Sources

Anthropic, Prompt Caching: cached and uncached prompt tokens as separate categories, plus the tiered cache lifetimes.
OpenAI, Prompt Caching: cached tokens reported as a portion of the prompt total.
Google, Gemini Context Caching: cached content counted inside the prompt token total.
DeepSeek, KV Cache: prompt tokens partitioned into cache hit and cache miss counts.

AI SpendOps attributes every request to a customer, feature, environment and team across 16+ providers, prices every token class correctly underneath, and puts budgets and burn-rate alerts on the same data. Start with your first 3 months free, or see how the proxy works.

Tokenomics Is Not the Answer. Cost Attribution Is.