On August 4, 2026, the Linux Foundation announced the Tokenomics Foundation, a vendor-neutral body chartered to build open standards for AI cost and value, with thirty founding members that include Accenture, IBM, JPMorganChase, Oracle, SAP, ServiceNow, Broadcom, and Cast.ai. Its first open-sourced deliverable isn't a pricing table or a governance checklist. It's a notation. Big-T, written by Adobe's Dan Neff, borrows the vocabulary computer science already has for this exact problem, Big-O complexity analysis, and applies it to token spend: a workload's cost doesn't just depend on how many requests you get, it depends on how many model calls each request triggers and how deep the agents calling agents go. The framework's own name for the worst class on its list, orchestrators spawning sub-agents that spawn further sub-agents, is blunt: the O(n²) of AI. And lever one of the five the framework recommends to escalate out of that class, ahead of prompt engineering, caching, and governance, is model routing. An industry group that includes three of the ten largest companies on earth just put a name on the problem this blog exists to write about, and opened its own answer with routing first. Here's the notation, the worked numbers behind it, and what "lever one" actually takes to run continuously instead of as a slide in an architecture review.
The vocabulary nobody had.
Ask five engineers why their agent's token bill tripled and you'll get five different vague answers: "it's doing more," "the context got longer," "the model changed." None of those are wrong, and none of them are precise enough to act on. Big-T's contribution is a shared formula for the actual shape of the cost: T(n · k · a), where n is the number of requests or the input size, k is the number of model calls triggered per request, and a is agent depth, how many layers of sub-agents get spawned to handle one top-level task. Two systems can serve the same n requests and land in wildly different cost brackets depending on what k and a are doing behind the scenes, and Big-T's central claim is that most teams have never measured k or a at all. They see the invoice; they don't see the exponent.
The framework organizes workloads into six classes on a ladder, each with a distinct fix:
| Class | What it means | Fix |
|---|---|---|
| T(1) Constant | Model isn't called per request, cache hit or static lookup answers it | Cache and precompute aggressively |
| T(log n) Sublinear | Deterministic code shrinks the input before inference, retrieval done correctly | Filter and retrieve before the model sees anything |
| T(n) Linear | One model call per request, cost tracks input size directly | Trim per-call overhead, hold this as the default |
| T(n·k) Multiplicative | k invisible model calls per request, reasoning tokens, context replay | Compose tool pipelines, instrument for hidden k |
| T(n·k·a) Agent-multiplicative | Orchestrators spawning sub-agents that spawn further sub-agents | Bound agent depth, add circuit breakers |
| T(∞) Unbounded | Retry loops or agent chains with no termination condition | Hard termination conditions, no exceptions |
The paper calls out the failure mode directly: the same task, served through five context-replaying chat turns instead of one composable call, moves from T(n·k) to T(n), an order-of-magnitude token difference for identical output, purely because of how the interface was designed. That's the point of naming the classes. "Class" isn't a property of the task, it's a property of the architecture you built around the task, and it gets decided once, at design time, then compounds silently on every request after.
Why now: four demand curves hit the same twelve months.
Big-T frames the timing with what it calls the compounding-demand thesis, four things happening at once. Frontier models consume more tokens per task with each generation. Larger context windows invite larger prompts, because the ceiling moved so the habit followed. Agentic architectures multiply the number of calls per task by design, that's the whole point of an agent loop. And adoption itself is compounding on top of all three. Meanwhile per-token prices keep falling, which should be the offsetting force, except the framework names the mechanism that cancels it out: a Jevons paradox, where cheaper tokens don't reduce spend, they get reinvested into higher usage. We covered the pricing side of this split directly: frontier tokens got 36% more expensive over the last year while mid and budget tiers fell 36%, and neither number tells you what your bill will do, because your bill is a function of price times consumption times class, and class is the variable most teams have never looked at.
Goldman Sachs' number for where this goes: global token usage multiplying 24x between 2026 and 2030, to roughly 120 quadrillion tokens a month. Cast.ai, one of the foundation's founding members, adds the other half of the picture that pure token-counting misses: median enterprise GPU utilization sits around 5%, meaning most of what shows up on an AI infrastructure bill isn't billed tokens at all, it's idle hardware nobody right-sized. Big-T's reference model is explicit that token counting alone undercounts the real cost of AI; the framework asks for the full stack, tokens plus the compute sitting around waiting for them.
The worked example: 34x, and only one of the four moves is a model swap.
The paper's most concrete artifact is a summarized comparison across ten cited studies, walking one task through four increasingly disciplined architectures:
| Architecture | Method | Cost | Class |
|---|---|---|---|
| 1. Multi-chat replay | Context resent in full on every summary turn | $3.04 | T(n·k) |
| 2. Isolated chats | Separate chats eliminate context replay | $0.65 | T(n) |
| 3. Right-sized routing | Model matched to task difficulty, not defaulted up | $0.13 | T(n) |
| 4. Engineered pipeline | Isolated contexts + routing + bounded output templates | $0.09 | T(n) |
Read the deltas in order and the lesson isn't "switch to a cheaper model," it's that the biggest single jump, $3.04 to $0.65, comes from fixing an architecture bug (context replayed on every turn), not from touching the model at all. The second jump, $0.65 to $0.13, is routing: the same architecture, the same isolated contexts, now sending each call to the model that actually fits the task instead of a flat default. The last step, $0.13 to $0.09, is output discipline, a bounded template trimming the axis most teams never look at, response length. Three different levers, three different orders of magnitude of effort to implement, and routing is the one in the middle: bigger payoff than prompt formatting, lower engineering lift than an architecture rewrite.
The five levers, and where routing sits.
Big-T names five levers for moving a workload down the ladder, and it ranks model routing first:
- Model routing. Send each task to the cheapest model that clears a quality threshold, not the default frontier model for every call.
- Prompt engineering and serialization. Compact formats, tabular over verbose JSON, can roughly halve tokens for the same data, and the TOON format's own benchmark reports retrieval accuracy essentially even with JSON.
- Caching as a design principle. Prompt-prefix caching cuts input cost; semantic caching skips the call entirely on a repeat question.
- Abstraction transparency. Expose token-level telemetry per call instead of hiding usage behind a flat credit bundle a team can't decompose.
- Workload classification and governance. Tie high-consumption workloads to the business outcome they're supposed to produce, and cut the ones that aren't producing it.
The framework's own five-step rollout is worth stating plainly, because it's the same order the worked example demonstrates: get visibility into consumption by model and workload first, classify your highest-spend workloads on the ladder, ask whether the class is justified by the value produced, change the class where the architecture allows it (compose pipelines, cache, filter before inference), and only then optimize within the class using the remaining four levers.
That ordering matters for what "lever one" actually requires in practice. Routing isn't the first thing you touch chronologically, it's the first lever you reach for once you already know which calls are misclassified, and knowing that requires the visibility step to have happened already. A team that skips straight to "route everything" without first fixing T(n·k) architecture bugs is routing a bloated context to a cheaper model and calling it optimized; the model changed, the waste didn't.
What "routing" means once, versus routing on every request.
Here's the gap between the framework and a production system: Big-T's routing lever, as published, is a design-time decision. You classify a workload, you pick the model tier that fits its class, you ship it. That's correct as a first pass and it's exactly what the worked example demonstrates. What it doesn't cover is what happens after ship: the same workload's actual difficulty varies request to request, a "simple" endpoint gets an unusually hard prompt on Tuesday, a provider reprices the model you routed to six weeks ago (as DeepSeek did to its own budget tier in the same window this framework launched), and the static routing table written during the architecture review doesn't know either happened.
This is the layer Nadir sits on. Rather than a routing decision made once per workload and left to drift, Nadir's classifier scores each individual request against current provider pricing and a quality floor set per API key, so the T(n) versus T(n·k) question the Big-T framework asks at design time gets re-asked automatically for as long as the endpoint runs. When a benchmark is configured and priced, `nadir_metadata.benchmark_comparison.savings_usd` gives a per-request answer to the framework's own central cost question. Two lines of code point an existing OpenAI or Anthropic client at Nadir's endpoint; nothing about the architecture in the worked example above needs to be rebuilt to get lever one running continuously instead of once.
A five-question self-audit.
Before reaching for any of the five levers, Big-T's own rollout order says get visibility first. In practice that means answering five questions about your highest-spend endpoint, in order:
- *What's n?* Requests or input size, the number you already have in your logs.
- *What's k, and is it visible?* Count actual model calls per request, including retries, reasoning-token turns, and any hidden re-summarization step. Most teams undercount this because it doesn't show up in application-level logging, only in the provider invoice.
- *What's a?* If the endpoint touches an agent framework, count sub-agent spawns per top-level task. A single "handle this ticket" call that fans out to three specialist sub-agents is already T(n·k·a), whether or not anyone designed it to be.
- Is the resulting class justified by the output? A T(n·k) support-ticket classifier producing a one-word label is a bug, not an architecture choice. The same class on a multi-step research agent producing a cited report might be exactly right.
- Would fixing the interface, not the model, change the class? Before routing to a cheaper model, check whether the call pattern itself, five turns replaying context instead of one composable call, is what's actually inflating k. Fixing that first (the $3.04 to $0.65 jump in the worked example) is usually cheaper engineering than a routing layer, and it has to happen before routing can do its own job cleanly.
Conclusion.
The Tokenomics Foundation's Big-T notation is the clearest sign yet that model routing has stopped being a scrappy cost hack and become something Fortune 500 finance and platform teams expect a standard to name. That's a good problem for the industry to have named out loud, and it validates a straightforward reading of the numbers: the biggest win in the worked example was an architecture fix nobody needed a new vendor for, and the second-biggest was routing, applied once, at design time, to a workload that doesn't stay the same shape it had on the day someone classified it. A published standard makes the vocabulary sharable across a finance team and an engineering team who couldn't previously agree on what "the AI is expensive" meant. It doesn't run the routing decision for you, on every request, as pricing and difficulty drift under a workload that was classified once and never revisited.
Sources: [Linux Foundation, "Linux Foundation Launches the Tokenomics Foundation to Define the Economics and ROI of AI Value," August 4, 2026](https://www.linuxfoundation.org/press/linux-foundation-launches-the-tokenomics-foundation-to-define-the-economics-and-roi-of-ai-value). [Dan Neff, "Big-T Notation," Tokenomics Foundation](https://www.tokeneconomics.com/projects/big-t-notation/). [AIwire/HPCwire, "Linux Foundation Forms Tokenomics Foundation for AI Cost and Value Standards," August 5, 2026](https://www.hpcwire.com/aiwire/2026/08/05/linux-foundation-forms-tokenomics-foundation-for-ai-cost-and-value-standards/). [Tech Times, "Tokenomics Foundation Launches: JPMorgan and IBM Back AI's First Billing Standards Body," August 4, 2026](https://www.techtimes.com/articles/323059/20260804/tokenomics-foundation-launches-jpmorgan-ibm-back-ais-first-billing-standards-body.htm). [The Next Web, "AI token prices fell 98% but enterprise bills tripled, now the industry wants a standards body to explain why"](https://thenextweb.com/news/token-prices-fell-98-enterprise-ai-bills-tripled-now-the-industry-wants-a-standards-body-to-explain-why).