Tokenomics & Big-T workload classes

Tokenomics is the economics of AI tokens — what a unit of finished work costs, and how that cost grows as usage grows. The Tokenomics Foundation (Linux Foundation, 2026) standardises the vocabulary; Brutor measures the numbers, because the gateway already sits in the request path of every model call, tool call, skill and delegation an AI System makes.

Note

A token here is the unit a language model reads, generates and bills by — roughly four characters of English. Nothing to do with the cryptocurrency use of the same word.

Big-T notation: cost has a shape, not just a size

Big-O notation describes how an algorithm’s work grows with its input. Big-T notation does the same for AI cost: it classifies a workload not by what it costs today, but by how its cost grows as usage grows.

Class	What’s going on	How the bill grows
T(1)	A cache answers most requests; the model is rarely called	Barely grows with usage
T(log n)	Plain code trims the input before the model sees it	Grows slower than usage
T(n)	One model call per task	With usage, predictably — the healthy default
T(n·k)	The system makes k model calls per task — reasoning steps, tool calls, replayed context. k is invisible on the invoice	Usage × k
T(n·k·a)	Agents hand work to other agents; a second multiplier compounds the first	Compounds with usage
T(∞)	A loop with no exit condition	No ceiling at all

The violet curve is why agent workloads get underestimated in pilots: T(n·k·a) runs below T(n·k) for most of the range and only overtakes it late. A workload that is comfortable at ten users and ruinous at a thousand didn’t change — it was T(n·k) all along and was budgeted as if it were T(n).

How Brutor derives the class — measured, not estimated

The standard assigns a class by reading a workload’s architecture. Brutor derives it from what actually ran, using the run ledger:

Symbol	Source
n	Finished runs (replays excluded)
k	Median model calls per run — the median, so one outlier run cannot reclassify a system
a	Maximum delegation depth observed
cache share	Cache hits ÷ governed actions

Classification precedence: delegation on ≥ 5% of runs → T(n·k·a); median k > 2 → T(n·k); cache share ≥ 50% → T(1); otherwise T(n). A chatty loop with a good cache is still a chatty loop.

Two classes are never asserted: T(log n) (the ledger cannot see deterministic pre-filtering that happens before the gateway) and T(∞) (delegation-depth caps and budgets make an unbounded loop structurally impossible on governed traffic — the class exists to be prevented, not observed).

Absence of evidence is never a class

Below 20 finished runs in the window the card shows no class at all. A class computed over a handful of runs is noise wearing notation — a blank you can trust beats a number you can’t.

The 30-day judgment window

The class — like health and the verdict — is always computed on a fixed 30-day window, whatever time range you pick on the dashboard. The window selector scales measurements (spend, runs); it never changes judgments, so there is no view in which a struggling system looks fine.

What the card shows

Every AI System card in Mission Control carries three tokenomics numbers:

1. Spend over the selected window.
2. Cost per completed task — total spend ÷ runs that actually finished. If the system’s contract declares a max_cost_per_run_usd ceiling in its operating envelope, the number turns red the moment it crosses. No provider can compute this figure: only the system orchestrating the work knows where one task ends and the next begins.
3. The class chip. On group cards the chip shows the worst class in the subtree — rendered as “contains T(…)” — never an average.

Cost-complexity findings

Because the class is recomputed continuously, a change in class is a finding, in the same list as behavioural drift and liveness:

• Moving up the ladder (say T(n) → T(n·k)) raises a cost-class drift event — severity high when the arrival class is T(n·k·a).
• The event carries a cause when one lines up (a contract minted or a binding changed within the preceding 72 hours); otherwise it says unexplained plainly rather than dressing up a guess.
• Moving down the ladder is recorded too, at low severity — that is your levers working, not an alarm.
• A standing class finding never stacks, and a further transition supersedes it.

You respond the way you respond to any finding: tighten a limit, change the routing, or accept it and raise the ceiling.

The levers, in Big-T terms

Lever	What it does to the class
Semantic cache	Moves repeat traffic toward T(1)
Cheaper / routed models	Lowers the price of every T(n) call
Budgets, quotas & rate limits	Bound the bill before the money is spent
Delegation-depth caps	Put a hard ceiling on a
Batch processing	Provider batch rates for off-peak T(n·k) work

Limits without measurement keep you solvent but teach you nothing; measurement without limits explains the overrun beautifully, afterwards. The gateway’s ledger feeds both from the same record.