The Linux Foundation launched a standards body for AI token economics. Here's what it means for people who build and use MCP tools.
Last week the Linux Foundation launched something called the Tokenomics Foundation. Thirty founding members. Accenture, IBM, JPMorganChase, Oracle, SAP, ServiceNow. A governing board, a technical steering committee on the way, and a mandate to standardize how enterprises measure the cost and ROI of AI.
If your first reaction was "tokenomics is a crypto word," they thought of that. Their docs address it in the second paragraph: this is not Web3 token supply design. Here, a token is the atomic unit of AI, and tokenomics is a plain contraction of tokens and economics. The name is going to cause confusion for a year anyway, but that's their problem.
Here's why it's your problem, in a good way, if you build or use MCP tools.
What actually happened
For two years, enterprise AI spend has been a line item nobody could explain. Goldman Sachs is forecasting token consumption to grow 24x by 2030. CFOs are looking at bills that tripled in a quarter and asking questions the engineering org can't answer with anything better than a screenshot of a usage dashboard.
The FinOps Foundation spent a decade building the discipline for exactly this problem in cloud spend. Shared vocabulary, a billing data spec (FOCUS), certifications, the whole apparatus. The Tokenomics Foundation is that playbook pointed at AI. Same executive director, even. J.R. Storment now runs both.
Their roadmap, condensed: define what tokens actually cost (input, output, reasoning, cache), build a reference model for the full cost of AI beyond tokens, standardize "cost to serve" as cost per call rather than cost per token, and extend FOCUS so token spend shows up in billing data the same way EC2 instances do.
They also shipped their first framework already. It's called Big-T Notation, written by Dan Neff at Adobe, and it's the piece worth your attention.
Big-T: Big-O for token spend
Big-O notation never told you an algorithm's exact runtime. It told you how runtime grows as input scales, which let engineers make architecture decisions without benchmarking every input.
Big-T applies the same idea to tokens. It classifies AI workloads by how their token consumption grows as usage scales, complexity increases, or autonomy expands. It's deliberately informal. No proofs, no master theorem. A thinking tool so that engineers, architects, and finance people can argue about token cost trajectories using the same words.
This is the first vocabulary I've seen from the enterprise side that admits what practitioners have known for a while: the interesting variable isn't the price per token. It's the shape of consumption growth, and that shape is an architecture decision.
Upstream Solutions for Downstream Problems
Look at the member list again. It's dominated by FinOps platform vendors and consultancies. Their instinct, honed over a decade of cloud cost management, is to treat this as a measurement problem. Instrument the spend, dashboard it, allocate it, forecast it. That's real work and it matters.
But measurement is downstream of consumption, and consumption is downstream of retrieval.
The single largest controllable variable in most agentic workloads is what goes into the context window. An agent that reads a 214,000-token repo to answer a question about dependency injection, versus one that retrieves the 480 tokens of the actual function, is not a 10% optimization. It's two or three orders of magnitude, per query, forever. No amount of dashboarding closes that gap. Only architecture does.
The Tokenomics Foundation's own docs actually get this. Their Consumption stage explicitly covers model routing, prompt engineering, quantization, and caching. Retrieval discipline belongs on that list, and I suspect it will end up there, because the working groups are going to go looking for consumption levers and the context window is the biggest one in the building.
What this means for MCP developers
Three practical things.
First, the vocabulary is about to standardize, and you want your tooling to speak it. When "cost to serve" becomes a defined metric expressed as cost per call, tools that report their token behavior in compatible terms become legible to enterprise buyers, and tools that don't become line items nobody can defend. If you ship an MCP server today, start thinking about what your per-call token profile looks like as a reportable number.
Second, telemetry is about to matter more than benchmarks. A benchmark is a claim about a lab. Telemetry is a claim about the field. As FOCUS extends into token spend, the tools that can show measured, methodology-disclosed consumption data from real deployments will have standing in the standards conversation that marketing pages never will. If you're instrumenting anything, disclose what you count, what you model, and what you can't see. The distinction between measured and modelled is going to be the credibility line.
Third, the doors are open right now and mostly empty. The governing board met July 30. The technical steering committee is forming as I write this. Storment told Fortune they expect nearly monthly framework releases through the end of the year, with drafts debuting at Tokenomicon in Amsterdam in September. Working group charters are being drawn up by whoever shows up. In a standards body's first ninety days, a practitioner with real data has leverage that will not exist once the org chart hardens.
Full disclosure: I build MCP retrieval tooling (the jMunch suite), so I have obvious skin in the "retrieval is the lever" argument, and I'm pursuing exactly the participation I'm describing. Discount accordingly. But the underlying claim doesn't depend on my tools. Whatever retrieval layer you use, build one, buy one, or write your own, the consumption curve it produces is about to become a number your CFO has a standard for.
The FinOps people found the context window. The question is whether the people who actually work in it show up to help define what they find...
Top comments (0)