Key Takeaways
- AI tokenomics models how tokens are generated, consumed, priced, and converted into value, and token spend is not the same as token value.
- Agentic systems break single-call cost models because one user request fans out into many tool calls, retries, and sub-agent runs.
- A usable tokenomics model has to be built from production telemetry rather than spreadsheets, so cost can be attributed to specific agents, steps, and outcomes.
Why Token Spend Outruns Every Forecast in Production
An insurance support agent looked cheap before launch. The pre-launch estimate priced a single prompt and a single completion per customer question, and the projected monthly bill was modest. In its first month in production, the same agent ran 6x over that budget.
Nothing about the agent had changed. The estimate had simply modeled the wrong thing. It assumed one prompt in and one completion out, when each customer question actually triggered a chain of work.
In production, one question set off retrieval calls, tool invocations, and a multi-step reasoning loop before the agent produced an answer. Real token consumption was a multiple of the forecast, not a small overage on top of it.
Finance saw the number on the provider invoice. Engineering could not answer the follow-up question. No one could say which agent, which step, or which customer segment drove the overage. Token expenditure and the economic value it produces are distinct quantities [1], and the team had visibility into neither. Tokens are the variable cost of intelligence, the unit that scales directly with usage [2], so an unmodeled agent is an unbounded line item.
Where Spreadsheet Tokenomics Breaks for Agents
Most teams model token cost the same way. They open a spreadsheet and multiply tokens per request by requests per month by price per token. The arithmetic is correct for a single LLM call. It falls apart the moment an agent ships.
An agent does not make one call per request. One request expands into a decision tree of calls, and the spreadsheet has no cell for that structure. Retries, tool invocations, and sub-agent runs all consume tokens that the single-call formula never counted.
There is also a definitional trap that many teams conflate. Crypto tokenomics treats a token as a unit of ownership. AI tokenomics treats a token as a unit of computation. Modeling AI cost with a mental model borrowed from crypto leads teams to price the wrong asset.
Static estimates carry a second blind spot: token cost drift. Provider pricing and model routing change between billing cycles [3], so the cost per trace you modeled in January is not the cost per trace you pay in March. Cost drift is a signal teams already struggle to track from a static sheet, which is why it belongs in telemetry, not a forecast.
A Token Model That Separates Spend From Value
AI tokenomics is the study of how tokens are generated, consumed, priced, allocated, and optimized across AI systems [1]. It gives a modeling discipline to a cost that used to be a rounding error and is now a primary operating expense.
The core distinction is between two quantities that teams routinely collapse into one. Token spend is what you pay the provider. Token value is the marginal productivity of that spend inside the workflow [1]. Two runs can cost the same number of tokens and produce wildly different value, and a model that tracks only spend cannot tell them apart.
Model cost as tokens per step times price per token [4], summed across every step in a run. Then divide the business value of the run by that cost to get value per token. Spend goes in the denominator; the outcome goes in the numerator.
Tokens are not homogeneous, which is why measurement has to be precise. Input tokens are what you send to the model. Output tokens are what it returns. A third category matters most and hides best: reasoning tokens that the model generates internally and bills you for but never surfaces in the visible response [1]. A model that counts only the tokens a human can see undercounts the ones you actually pay for.
Modeling Tokens Across the Agentic Hierarchy
The single-call identity has to stretch to fit an agent. The unit of analysis is no longer the API call. It is the agentic hierarchy, the full decision tree of agent calls, tool invocations, and sub-agent outputs that one request sets in motion.
Model cost per run as the sum over all spans in that tree, not per API call. Summing spans is what captures retries and fan-out; summing calls silently drops them. A span is one unit of work in the run, whether that is an LLM completion, a retrieval, or a tool invocation.
The multiplier is larger than most estimates assume. A 400-token user question can cost 40,000 tokens by the time retrieval, tool calls, and a reasoning loop finish. Span-level telemetry that rolls up to the run timeline is what makes that 100x visible; aggregate insights across the entire hierarchy turn a single invoice number into a per-run cost you can decompose.
Instrumenting Token Data From Production Telemetry
A token model is only as good as the data feeding it, and this is where most models quietly fail. The framework above needs per-span token counts, the model name, and the resolved price, each tagged with the agent, the tenant, and the outcome. Without those tags, you can total spend but you cannot attribute it.
Capture the data at the span level as the run executes. A single span record should carry enough to reconstruct both cost and context later.
{
"span_id": "a3f9c2",
"trace_id": "req-8817",
"agent": "claims-support",
"tenant": "acct-4412",
"span_type": "llm_completion",
"model": "gpt-5.4",
"tokens": { "input": 1840, "output": 320, "reasoning": 2100 },
"unit_price_usd": { "input": 0.0000025, "output": 0.000015 },
"resolved_at": "2026-07-10T14:03:11Z",
"outcome": "ticket_resolved"
}Two practitioner rules make the record trustworthy. First, capture input, output, and reasoning tokens separately, because they price differently and reasoning tokens are the ones that escape naive counts. Second, resolve and store the price at request time rather than at reporting time, since provider pricing changes and a stale price silently rewrites your history.
Rolling those spans up to a run cost is then a straightforward aggregation over the trace.
def run_cost(spans):
total = 0.0
for s in spans:
t = s["tokens"]
p = s["unit_price_usd"]
total += t["input"] * p["input"]
# reasoning tokens bill at the output rate
total += (t["output"] + t["reasoning"]) * p["output"]
return total
This is also the point where agent-side and gateway-side capture have to be stitched into one view. A gateway sees the calls that pass through it. The agent sees the sub-agent calls and tool loops that do not. Only agent observability that joins both records the full run.
Token Cost Traps That Escape Standard Dashboards
Standard cost dashboards undercount agentic token spend in four repeatable ways.
- Hidden Reasoning Tokens: reasoning models emit tokens you are billed for but never see in the response [1], so a dashboard keyed to visible output understates cost.
- Retry and Fallback Fan-Out: automatic retries and model fallbacks multiply per-request token cost without changing the request count.
- Cache Accounting: prompt caching changes the effective cost per token, and a model that ignores cache hits overstates spend against the invoice.
- Gateway-Only Measurement: metering tokens only at the gateway misses sub-agent calls that route around it, so per-run cost is undercounted for exactly the multi-agent workloads that cost the most.
- Evaluation overhead: LLM-as-a-judge evaluations bill per trace against external APIs, a cost most token models never itemize. In-environment evaluators remove that line item; size yours with the evaluation TCO calculator.
What Changes When Token Cost Becomes Observable
Once the model runs on live telemetry instead of a forecast, attribution stops being a guess. Cost resolves to a specific agent, a specific tenant, a specific feature, and for coding agents, a specific pull request. Fleet-wide token and dollar intelligence, including cost per pull request, is what turns a single provider invoice into a bill you can route to the team that generated it.
Optimization decisions become evidence-based rather than intuitive. With per-span cost in hand, a team can follow a repeatable sequence to reduce spend without degrading output:
- Locate the cost: rank spans by token cost per run to find where the spend concentrates.
- Choose the lever: cache a repeated prompt prefix [5], compress a bloated context, route a simple step to a cheaper model, or cut an unnecessary reasoning loop.
- Measure against value: re-run the value-per-token calculation to confirm the change cut cost without cutting the outcome.
Value tracking is the payoff. Pair the cost per run with an outcome signal, a resolved ticket or a merged pull request, and the model finally reports value per token instead of spend per token. That is the number that tells you whether an expensive run was worth it.
Two problems remain unsolved. Measuring the productivity of hidden reasoning tokens, and allocating token budget dynamically across a run as its value becomes clear, are both open research questions [1]. A model that separates spend from value is the prerequisite for solving them, not the solution itself.
Conclusion
The insurance team that could not explain its 6x overage can now answer the question it stalled on. Every token traces to a span, the span traces to an agent and a step, and the step traces to an outcome. The invoice is no longer a mystery; it is a breakdown you can act on.
The cost side of AI tokenomics is now tractable with the right telemetry. The next frontier is the value side: modeling not just what a token costs, but what it was worth.
See how agentic observability captures per-span token cost across a full run.
References
[1] Q. Zhu, "AI Tokenomics: The Economics of Tokens, Computation, and Pricing in Foundation Models," arXiv, Jun. 2026. [Online]. Available: https://arxiv.org/abs/2606.24616
[2] Hugging Face, "Tokenization Algorithms: Summary of the Tokenizers," Hugging Face Transformers Documentation, 2026. [Online]. Available: https://huggingface.co/docs/transformers/en/tokenizer_summary. Accessed: Jul. 15, 2026.
[3] S. Willison, "LLM Pricing," simonwillison.net, 2026. [Online]. Available: https://simonwillison.net/tags/llm-pricing/. Accessed: Jul. 10, 2026.
[4] Anthropic, "Pricing," Claude Platform Docs, 2026. [Online]. Available: https://platform.claude.com/docs/en/about-claude/pricing. Accessed: Jul. 15, 2026.
[5] Anthropic, "Prompt Caching," Claude Platform Docs, 2026. [Online]. Available: https://platform.claude.com/docs/en/build-with-claude/prompt-caching. Accessed: Jul. 10, 2026.