The FinOps Foundation didn't launch the Tokenomics Foundation because AI cost management was a solved problem with a new name attached. As JR Storment has written, token economics is the discipline through which AI consumption gets metered, attributed, and connected to business outcomes, and most enterprises still have no reliable way to do that. A new discipline doesn't get built around a problem that's already handled.
The instinct is to solve this the way teams have always solved cloud cost problems: tag resources, wrap calls in an SDK, enforce naming conventions. That playbook worked for traditional infrastructure. It does not work for AI infrastructure, and the reasons are architectural, not procedural.
A newer category of approach, kernel-level measurement using eBPF, sidesteps the instrumentation problem entirely by observing consumption directly at the operating system level, without tags, SDKs, or code changes. This is what "tokenomics without tags, SDKs, or code changes" refers to. Here's why the instrumentation approach breaks down, and how kernel-level attribution works differently.
What Is AI Cost Attribution (and Why Is It Broken Today)?
AI cost attribution is the practice of tracing AI spend, GPU cycles, model API calls, token consumption, back to the specific customer, feature, team, or agent responsible for it. It's the AI-era equivalent of cloud cost allocation, with one critical difference: the infrastructure it has to measure doesn't hold still long enough for traditional methods to catch it.
Traditional cost allocation relies on instrumentation. Tag a resource, and you know who owns it. Wrap an API call in an SDK, and you know which team made it. That approach is imperfect even in traditional cloud environments, tag coverage is a perpetual work in progress, but it's good enough, because the infrastructure underneath it is relatively static and ownership is relatively clear.
AI infrastructure breaks every one of those assumptions.
A single managed model API account serves dozens of teams at once. A shared GPU cluster runs workloads for multiple products simultaneously, with no resource-level boundary between them. An LLM gateway aggregates requests from agents, pipelines, and human users into one outbound stream, stripping out the caller's identity in the process. An agentic workload can spawn sub-agents that trigger downstream costs, compute, memory, network, that have no traceable link back to the line item they originated from.
There's no tag that survives a hop through an LLM proxy. There's no SDK you can wrap around a shared GPU. And even where instrumentation could theoretically work, AI workloads move faster than instrumentation can be deployed: an agent can spawn a thousand sub-agents overnight, and the bill lands long before anyone updates the tracking code.
The attribution gap in AI spend isn't a process problem. It's a structural consequence of how AI infrastructure actually works.
Why Traditional Approaches Hit a Ceiling
The tools built to solve this generally fall into one of three categories.
Billing-layer tools work after the fact, reconciling provider invoices into reports. They tell you what was spent, in aggregate, well after the workload that generated the cost has finished running.
Kubernetes-agent tools instrument the orchestration layer, tracking pod and container-level resource use. They work as long as the workload stays inside Kubernetes and inside a single cluster boundary. They lose visibility the moment a request crosses a managed API, a shared GPU, or an LLM gateway.
Metadata-inference tools attempt to skip manual tagging altogether by inferring ownership from available metadata and proposing virtual tags automatically. This is a meaningful improvement over manual tagging, but it inherits the same ceiling: it can only attribute what metadata exists to describe, and at the layer where AI consumption actually happens, that metadata doesn't exist.
All three approaches are reconstructing attribution after the fact, from signals that sit above the layer where the actual consumption occurs. None of them can see inside a shared GPU. None of them can follow a token through a gateway back to the agent that triggered it.
The platforms that can are the ones measuring from underneath all three layers, not from beside them: at the kernel, where consumption is observed directly rather than inferred.
How Kernel-Level Attribution Works
A kernel-level approach deploys an eBPF sensor directly inside the operating system. Deployment typically takes minutes: no code changes, no Kubernetes manifest edits, no SDK to integrate.
Once running, the sensor observes actual consumption as it happens: every token, every model request, every GPU cycle, and maps each unit back to the process, container, pod, and request responsible. That runtime data can then be joined with provider billing from sources like Anthropic, OpenAI, Google Gemini, and AWS Bedrock, automatically splitting cached tokens, reasoning tokens, input tokens, and output tokens.
The result is per-customer, per-feature, per-agent token economics, produced continuously, without instrumentation, without tagging, and without code changes. Because the sensor operates at the kernel, it sees the consumption directly. There's nothing to infer, and nothing for an agent, a gateway, or a shared GPU to hide behind.
What Kernel-Level Attribution Changes for Each Team
For VP of Engineering teams, kernel-level attribution means defensible chargeback. GPU costs get traced to the workload that generated them, which means the end of contested billing disputes between teams sharing infrastructure.
For FinOps practitioners, it means the end of the orphaned spreadsheet. Tags decay. Tagging conventions fall out of date the moment a new service ships. Kernel-level measurement doesn't depend on anyone remembering to tag anything.
For CFOs and Finance leaders, it means ROI visibility tied to specific features and customer segments, not account-level estimates. Knowing that a feature drives renewal likelihood is a different kind of insight than knowing what the account spent in aggregate last month.
Why This Matters Now
The pattern holds across every prior cloud cost category: compute optimization, commitment management, Kubernetes cost allocation. Organizations that establish the right measurement foundation early make every subsequent decision better. Those that defer attribution until the bills are already large spend years reconstructing context they could have had from day one.
AI spend is moving faster than any previous category, and the data backs that up. A Sapio Research survey of 500 Finance leaders found that 79% of enterprises have already experienced AI cost overruns, and only 15% can calculate AI ROI without significant bottlenecks. The window to establish the right foundation is now, not after the next surprise bill.
How DoiT Approaches This
DoiT manages more than $8 billion in cloud spend across 4,500 customers in 27 countries, and has watched this measurement pattern repeat across every major cloud cost category. Attribute™ by DoiT applies the kernel-level approach described above: an eBPF sensor that deploys in about fifteen minutes, with no tags, no SDKs, and no code changes, producing per-customer, per-feature, per-agent token economics by the end of the day it's installed.
DoiT is also a marketing partner of the Tokenomics Foundation, working alongside JR Storment and the FinOps Foundation to help define open industry standards for AI token economics as the category matures.
Book a demo to see Attribute™ in your own environment.