The Token Is the Wrong Unit of AI Value

The Tokenomics Foundation addresses a real and increasingly urgent problem. Enterprises are being asked to justify AI investments while the underlying unit of consumption remains almost impossible for a normal human being to anticipate. This is why we are deeply skeptical of tokens as a primary pricing metric.

Humans do not naturally think in tokens. A user can see the length of a prompt, but cannot reliably determine how a particular model will tokenize it. Tokenization can vary across models, languages, file formats, and multimodal inputs. The user also cannot know in advance how long the model’s response will be or how many reasoning tokens it may consume.

This problem becomes considerably worse with agents. The visible user prompt may represent only a small fraction of the actual workload. An agent harness may add system instructions, tool descriptions, schemas, retrieved documents, conversation history, memory, security policies, and application context. The agent may then retry a failed step, call several tools, invoke another model, delegate work to subagents, or revisit an earlier decision.

All of those actions can generate additional tokens and infrastructure consumption without the user seeing them. Even a technically sophisticated user may not know which calls the harness made or how much context was passed with each one. The result is a cost-projection nightmare.

A pricing model is not meaningfully transparent simply because the vendor publishes a price per million tokens. Transparency also requires the customer to understand how many billable units a workload is likely to consume. In agentic AI, that number may remain unknowable until after the workflow has completed.

Token telemetry can still be valuable. It can help organizations reconcile bills, compare models, identify unusually expensive calls, and allocate observed consumption to teams or applications. However, that is retrospective accounting. It does not necessarily provide the predictability required for budgeting, product pricing, capacity planning, or business-case development. The distinction matters. Tokens may be a useful machine-level consumption metric. They are a poor human-level unit of value.

Tokens remain a necessary technical metric. They give engineering and FinOps teams a consistent way to observe model consumption, compare input and output patterns, detect anomalies, and identify inefficient context usage. Our objection is not to measuring tokens. It is to treating token counts as though they provide a human-legible forecast of total cost or a meaningful measure of the value AI produces.

The Linux Foundation appears to recognize part of this problem. Its roadmap extends beyond cost per token toward cost per call, total cost to serve, and business-value frameworks. That is directionally correct, but cost per call may still be too coarse. One call may answer a simple question, while another initiates a multi-agent workflow involving retrieval, tool use, reasoning, retries, and human approval.

Enterprises therefore need economics attached to the complete unit of work. Depending on the use case, that could mean:

• Cost per customer case resolved
• Cost per software defect remediated
• Cost per document processed
• Cost per approved agent action
• Cost per workflow completed successfully
• Cost per trusted answer
• Cost per outcome that did not require human rework

Those metrics must also account for quality. A cheaper model or workflow is not more economical if it produces inaccurate results that require human correction. Similarly, an agent that completes 80% of a task autonomously may not create meaningful value if the remaining 20% requires expensive investigation and remediation. The correct metric is not merely cost per output. It is cost per acceptable outcome.

This also places new responsibility on agent-platform and model vendors. Enterprises cannot calculate accurate unit economics without visibility into what occurred inside the workflow. Platforms must expose consumption by model, agent, tool, retrieval step, retry, and subtask. They should also show which costs were directly requested by the user and which were generated by the orchestration layer. Without that attribution, organizations will receive more detailed bills without gaining meaningful financial control.

The Foundation’s success should therefore be measured by whether it can make hidden AI consumption legible. A specification that normalizes token charges across providers would be useful, but insufficient. The harder requirement is connecting those charges to the workload, user, agent, decision, and business outcome that created them.