The following article originally appeared on Tim O’Brien’s Medium blog and is being republished here with the author’s permission.
AI costs are easy to count and hard to understand, and judging effort by a token volume? While that might feel like a valid measure of value or complexity, it doesn’t capture the details that define whether a workload was worth completing.
If someone’s bragging about how many tokens they’ve used, or if you work at a company that is measuring individual token consumption as a measure of individual productivity? You have either already realized or are about to realize that tokenmaxxing is an expensive misstep.
The bill can show you how many tokens a system consumed, which models it called, and how much those calls cost. What it cannot tell you is whether the system accomplished anything worth paying for, and this is the reality behind the current AI hangover.
FinOps has always had a blind spot around databases. We can measure storage, compute, queries, replicas, and utilization, but none of those numbers tells us what the database is for, why it was designed that way, or whether the cost is justified.
A database has a purpose. It supports a product, a transaction, a customer experience, or a business process. Its economics depend on architecture, workload, availability, latency, data design, and the consequences of failure. This is why it’s always been a fool’s errand to list databases in the same “efficiency opportunity” table as stateless workloads measured on compute.
AI is much closer to that than it is to ordinary metered infrastructure, but it’s even more complicated. There’s a level of speculative value for development efforts that rely on large networks of nondeterministic agents. Was yesterday really worth $500 of spend on Fable 5 for an hour? We’ll see.
You can spend hundreds of dollars a day on an AI task, but there is no useful way to decide whether that’s expensive without understanding what the system is trying to accomplish. A coding agent replacing hours of engineering work, a classifier sorting low-value documents, and an orchestrator coordinating dozens of downstream tasks might all generate the same daily bill. They are not economically comparable.
Again, this is similar to databases. A costly database may be wasteful, or it may be supporting a critical transaction path with demanding availability and latency requirements. You cannot know from the bill alone. The spend only makes sense in the context of the purpose, the architecture, and the consequences of getting it wrong.
That’s why the current enthusiasm around “tokenomics” makes me nervous. Not because token accounting is useless. Tokens are visible, measurable, and often directly connected to the bill. Of course, we should count them. But giving token accounting a name does not close the blind spot.
You cannot roll into a company, look at its token consumption, and say, “You should use Opus” or “You should use a cheaper model,” and consider the work finished. What worries me here is that a large portion of the FinOps world consists of vendors that are trying to do just that—companies selling this idea that you can show up and “just optimize.”
What’s the model doing? Is it writing code, classifying documents, recognizing speech, coordinating agents, or making decisions that require human review? Does a cheaper model create more retries? Does an expensive model reduce downstream work? What happens when it fails? Those questions determine the “economics,” but implying that tokens are a common currency is another misstep.
A token from one model isn’t equivalent to a token from another. A million tokens used by an orchestrator aren’t the same as a million tokens used for a high-value specialist task. A cheap call that produces bad work may cost more than an expensive call that succeeds immediately.
The useful measure isn’t simply the token. It’s the total cost of accomplishing the thing the system exists to do.
This becomes even more obvious as AI architectures become layered. A company might use a mid-tier model to coordinate work, a frontier model for difficult tasks, a local model for sensitive data, and a specialist service for speech. Some of that will be billed by the token, some by the minute, the seat, or the request. Some will run on hardware the company already owns.
Zoom out, and you’ll see that the notion of token as a proxy for spend is complicated by the iOS 27 release and a world in which your inference engine might be leveraging more local hardware in concert with remote calls for higher-powered LLMs.
I can see a near future in which we’re more focused on licensing costs and less focused on token consumption.
The next step for AI financial management is not to abandon token accounting. It’s to connect consumption to the workflow, the quality of the result, the architecture, and the business outcome.
Sure, count the tokens. But don’t mistake a new name for solving an underlying problem the space has had for a while—no one’s had a good discussion about “value” in the FinOps space, and everyone’s still chasing after simple efficiency reports.
. . .
Join us on Monday, August 31, for AI Codecon: Building with Open Source AI to explore the open-weight models, self-hosted stacks, and tooling ecosystem developers and technical experts are using to run models on their own terms. If tokenomics (or its limitations) is your thing, don’t miss IBM Research’s Gabe Goodhart on how off-loading scoped tasks to local models can help to minimize AI costs while maximizing agent value, then stay for talks on building the public AI stack, owning the agentic loop, avoiding prompt debt, and so much more. Register for free to save your spot.