Ask most technology leaders what their organisation spent on tokens last week, on which workload, and whether it produced anything worth the cost, and the honest answer is that they cannot tell you. Not because the data does not exist somewhere in a vendor’s billing system, but because nobody built the instrumentation to bring it back to the people who need to act on it, in time for the answer to matter. That gap is not a reporting inconvenience waiting for a better dashboard. It is an architecture decision that was never made, and it is the first thing enterprises taking token economics seriously need to fix.
The Invoice Is Not Visibility
The default state of token cost visibility in most enterprises today is a monthly vendor invoice: a single aggregated number, arriving weeks after the spend occurred, with no meaningful breakdown by application, team, or business outcome. That invoice tells finance what was spent. It does not tell anyone what drove it, whether the driver was a legitimate business workload or a misconfigured retry loop, or whether the spend is trending toward a number that will require a difficult conversation next quarter.
This is worse than the equivalent problem was in cloud FinOps, because cloud infrastructure at least arrives tagged: a virtual machine belongs to an account, a project, a cost centre, by construction. Token spend arrives as a single API line item, generated by whichever part of the application happened to make the call, with no inherent attribution to the feature, the team, or the business initiative that triggered it. Building that attribution is not something a billing dashboard can retrofit after the fact. It has to be designed into the system that makes the calls.
What Real-Time Attribution Actually Requires
Real-time token observability means being able to answer, within the same day, what was spent, by which workload, on whose behalf, and whether the output justified the cost. That requires three things most enterprises have not built. First, consistent tagging of every model call with the identity of the feature, team, and business initiative that triggered it, propagated through the call chain the way distributed tracing propagates a request ID through a microservices architecture. Second, aggregation infrastructure that rolls those tagged calls up into a view business and IT leadership can actually read, in near real time, rather than in a monthly batch export. Third, the discipline to build this instrumentation at the point a new AI feature is designed, not as a retrofit once someone asks why the bill jumped.
None of this is exotic engineering. Enterprises already know how to do distributed tracing, how to build cost allocation tags, how to construct near-real-time dashboards. The reason it has not been applied to token spend is that token spend has not yet been treated as a first-class architectural concern the way request latency or error rate has. That is a choice, and it is the choice that needs to change first.
Why This Has to Be Joint Infrastructure
The instinct in most organisations is to treat token metering as an engineering dashboard: a Grafana panel that the platform team looks at, disconnected from the business conversation about AI investment. That instinct undersells what the instrumentation is actually for. The business leader deciding whether to expand an AI-powered feature to a new customer segment needs the same visibility as the engineer deciding whether a prompt redesign is worth the effort. If the metering only exists in a system engineering looks at, the business conversation about AI investment continues to happen without the cost data that should inform it, and the two conversations stay disconnected exactly where they most need to connect.
Built correctly, token observability infrastructure serves both audiences from the same data: the technical breakdown engineering needs to optimise a specific workload, and the aggregated, outcome-linked view that lets a business leader ask whether a feature’s token cost is proportionate to the value it produces. That dual purpose is what makes it infrastructure worth building deliberately, rather than a side effect of whichever logging framework happened to be easiest to wire up.
The Reporting Trap
The most common mistake enterprises make once they decide token visibility matters is to treat it as a business intelligence problem: export the vendor invoice data into a warehouse, build a dashboard on top, and call the visibility gap closed. This produces a dashboard that is technically accurate and practically useless, because it still reports last month’s aggregate spend rather than this week’s per-workload behaviour, and it still cannot tell anyone which specific implementation choice is driving the number.
The distinction matters because it determines where the fix belongs. A BI problem gets solved by analysts building better reports on existing data. An architecture problem gets solved by engineering teams instrumenting the systems that generate the data in the first place, so that better data exists to report on. Token consumption visibility is the second kind of problem, and enterprises that treat it as the first kind will keep producing more polished versions of a report that was never going to answer the question that matters.
The Instrumentation Enterprises Need Before They Optimise
Visibility is not the end state. It is the precondition for the next discipline enterprises need to build: deciding, with actual data, where token spend is justified and where it is not. That decision is impossible to make well without the instrumentation described here, and any optimisation effort built on top of guesswork instead of measurement will optimise the wrong things, confidently. The enterprises getting ahead of token economics are building the metering first, precisely because everything that follows depends on it.
