Your Token Bill Is Lying to You

Uber gave 5,000 engineers an AI coding agent in December. By April, the entire annual AI budget was gone. Not because the tool failed - because it worked. Seventy percent of committed code was AI-generated. The finance team just had no idea what "working" would cost.

I watched the same movie up close. At a company I recently worked for, we enthusiastically rolled out one of the leading AI development environments to people well beyond the engineering team. Take-up was huge. The bill was bigger: six weeks in, our AI spend was running $8.5 million above what we'd budgeted for the entire year. We hadn't bought more software - we'd exhausted our premium token allotment and crossed into metered consumption.

The cost of many leading AI models has fallen by well over 90 percent in the past two years, and enterprise AI bills have tripled anyway. That's what happens when consumption grows faster than price falls and nobody in finance is holding the meter. If you're a CFO, CIO, CTO, COO or business-unit leader, here are seven things I'd want on your radar.

1. You can't allocate what you can't see

The tools your people are using - Claude, Cursor, Factory and the rest - were built as consumer products first. They know who signed in. They don't know why. When a developer and a salesperson and a support analyst all burn tokens through the same corporate subscription, the bill attributes cost to a person, not to the engagement, the project code, or the client matter it belongs to.

Attribution only works where a machine originates the call: software your own teams build can stamp a project code on every API request because someone wrote that into the code. A person working through an interactive tool can't. Your developer touches three projects in one afternoon; her tool's traffic looks identical all day. Today's provider invoices don't split that usage by project. Unless you build that layer yourself, the attribution exists at the user level - not the work itself.

In a consulting firm that's an engagement code. In a bank it's a project code. Either way, if you can't push AI cost to where the work happened, you can't price the work, you can't recover the cost, and you can't tell which parts of the business AI is actually helping. Most of these tools give you a usage leaderboard. A leaderboard is not a cost allocation system.

2. The software you buy has a meter inside it

More and more of the software entering your estate has a model wired directly into it - extracting data from tax documents, summarizing contracts, processing filings. Some of it you buy; plenty of it your own teams build. Either way, it tends to run on heavy-duty frontier models because heavy-duty models demo well. Then someone points the product at real volumes - thousands of documents instead of the ten in the pilot - and the consumption curve goes vertical.

And notice how this software is priced. The first wave of enterprise AI purchases looked like Copilot: per-seat, all-you-can-eat, easy to budget. The wave arriving now doesn't. New SaaS is increasingly credit-metered, with credits that burn faster or slower depending on which model does the work - which, economically, behaves much like BYOK - and much of the rest, including nearly everything your teams build, is bring-your-own-key outright: tokens flowing through your own API account at metered rates, less whatever your enterprise agreement earned you. Either way, there's no ceiling absorbing the overage. Every document the product processes lands on your bill.

The shift from chat to autonomous agents changes the economics again. A conventional assistant may make only a handful of model calls. An agent can make hundreds while it works, turning what looked like a software license into a variable operating cost.

One more assumption buried in your forecast: that model prices keep falling. They've fallen dramatically over the last two years, but whether they continue falling or begin climbing as compute tightens and providers chase margin is genuinely unclear - and it's not your decision. Your consumption forecast inherits someone else's pricing strategy. Current pricing reflects an unusually competitive market. Whether today's economics prove durable once the industry consolidates remains an open question.

This is the pattern behind the budget stories: companies burning a year of AI spend in a quarter, renewal quotes coming back at multiples of the prior contract, products quietly becoming the largest consumers of tokens in the organization. All of it is employees and software doing exactly what you bought them to do - at a scale nobody costed.

3. The AI budget isn't contained anymore

For most large organizations, AI spend started life as a technology line item. Copilot is the perfect example: nearly every large enterprise has licensed it, and it gives every employee a little more efficiency against the day-to-day tasks in front of them. Per-seat, predictable, and sitting comfortably inside an IT budget somebody owns.

That containment is over. The moment people outside technology - operations, risk, innovation, the front office of a bank - understand what stronger models with real tool use can do, they start consuming tokens on behalf of the whole organization. And they should: much of the highest-value work these tools unlock has nothing to do with development. But a budget that used to be self-contained in a technology function is now being drawn down by every business unit that's discovered the power, and almost nobody re-cuts the budget to match. The spend didn't grow inside its box. The box dissolved.

The governance usually dissolves with it. Technology negotiates enterprise agreements. Finance pays the invoices. Business units consume the tokens. Platform teams optimize models. Procurement manages renewals. Everyone owns a slice of AI economics, which often means nobody owns the whole. Until someone is accountable for AI consumption as a financial asset - not just another technology purchase - budget surprises are inevitable. Cloud computing taught us how to govern variable infrastructure spend. AI extends the same challenge into every knowledge worker and every business process.

4. Stop using a sledgehammer for everything

There's a simple discipline that many organizations haven't adopted yet: use the expensive frontier model to design the approach, then let a cheaper model execute the repetitive work.

Planning is where much of the judgment lives. Execution often benefits more from consistency than brilliance. Many workflows can reduce costs dramatically this way without sacrificing quality. The teams that have burned through their budgets have learned this the hard way, and vendors are increasingly recommending the same pattern themselves. It should be policy rather than folklore.

If your organization's default is "premier model for everything," you're paying sledgehammer prices to hang picture frames.

5. "We'll just run it in-house" - depends which "it"

Someone on your board might suggest running open-weight models internally to escape the token bill. It's a fair instinct, but it needs one distinction before it becomes a plan: there are two very different kinds of model you can run yourself, and they lead to two very different answers.

The largest open-weight models such as Kimi K3, DeepSeek and the biggest Qwen variants now sit close to the frontier models in capability, but they're big and serving a model in that class means a rack of data-centre GPUs and six figures in hardware before power, cooling and the specialists to keep it alive - which is why renting that capability through an API is almost always cheaper than owning it.

The smaller open-weight models are a different conversation. Models that fit on commercially available hardware - a Mac Studio loaded with memory, an NVIDIA DGX Spark, or similar - can quietly grind through long-running internal work: scanning repositories, classifying documents, overnight batch jobs where nobody is waiting on the answer and the data never leaves the building.

Neither category is good or bad. The mistake is asking, "Can we run models locally?" when the real question is which class of work you're running, and which class of model it actually needs. It's the sledgehammer point again, in hardware form.

6. Models are a new kind of technical debt

Every piece of AI-enabled software in your estate is built against a specific model - and models get retired. GPT-3.5 powered a generation of applications; it's already largely gone from the APIs. When a model is deprecated, the software built on it doesn't gracefully degrade. It has to be retooled, retested and redeployed. That's keep-the-lights-on spend your amortization schedule doesn't know about. (Under IFRS, this all lives in IAS 38 territory - what you can capitalize versus what hits the P&L - and your auditors will have views.)

Two subtler forms of the same debt.

First, 'prompt' rot. Unlike traditional software, prompts are coupled to a moving dependency rather than a fixed interface. A prompt that worked beautifully on one model can quietly misbehave on its successor because newer models interpret instructions differently. Nothing "breaks." The output simply gets worse, and unless someone is watching, nobody notices.

Second is 'scale' rot. Software tested on small files gets used on large ones, and model performance can degrade substantially long before you reach the advertised context limit. Nothing throws an error. You just get a confident, well-formatted, wrong answer.

If you're a public company of any kind, there's a framework you already certify against four times a year: your disclosure controls and ICFR, under NI 52-109 in Canada and SOX in the United States. The moment AI-generated output feeds a number in your financial statements - an accrual, an estimate, a valuation input - it's inside your control environment, and your auditors will eventually ask how you know it's right.

Some industries carry a second, sharper version of the same obligation. In banking, for example, model risk functions already maintain inventories under SR 11-7 in the U.S. or OSFI's E-23 in Canada. The generative models arriving inside vendor products and internal software belong there too, with validation, monitoring and retirement plans of their own.

AI models are becoming another class of production dependency that has to be inventoried, monitored, validated and periodically replaced. That's as much a governance problem as it is a technology problem.

7. The savings you booked won't show up on their own

Almost every AI business case, bought or built, rests on efficiency: fewer people touching a process, better margin. Efficiency only becomes savings when a cost that existed before actually comes out. Let's say a permanent employee runs you $170,000 per year plus indirects. If headcount doesn't change and no other cost mechanism is retired, you haven't saved anything. You've made the same fixed cost base more productive and added a token bill on top.

Sometimes that's exactly the right outcome. Agents take on the replaceable work, the people you already have work alongside them, and the freed capacity goes into serving more customers. The gain appears as higher throughput rather than lower cost. But that's a revenue case, and it should be measured as one. More capacity may be what the business needs, but it's not a saving unless a cost actually comes out.

Software development might be the clearest case. Building software is right now the biggest AI use case there is - writing new code, or rewriting old systems into modern languages that are more maintainable and optimized for 2026. The takeout potential is obvious. But ask any line of business, and most would tell you they wanted more software, not less - they were constrained by budget, not appetite. The world still runs a software deficit, not a surplus.

The deficit sits in two places: software you already committed to - what starts as a minimum viable product plan typically sheds a substantial share of its features on the way to release to meet the budget envelope - and software you never funded at all. So when your teams can build faster and cheaper, the savings might not move. They may simply deliver more of the features that had already been planned, or finally build what never made the cut. That can be exactly the right outcome. Just decide it's the goal, and measure it as one.

To be clear, real takeout exists. The richest seam may be surrogates - the outside parties a business leans on because it never had the capacity in-house. If your general counsel routinely taps outside counsel to keep up, and AI gives the in-house team the throughput to stop, that's genuine cost that can come out. The diligence is in taking the next step: if outside counsel sits on a retainer, using them less saves nothing until the retainer changes. Most businesses carry more surrogates than they recognize, and the incentives run against finding the internal ones - when payroll is the biggest line in the envelope, managers are rewarded for keeping people, not releasing them.

Planning season is tough when all of your real ROI is in the future and often spans past a fiscal year. The sponsors who sold the ROI forecast 15, maybe 25 percent cost takeout or margin enhancement. Then you ask each business to build its plan bottom-up with exactly that guidance, and they come back with one or two percent. The gap is structural: the people who claim the ROI are rarely the ones who have to execute it. The takeout has to happen inside businesses that were never truly signed up to deliver it.

Think of AI as an investment portfolio, not a project. Last year, most enterprise AI investment chased cost takeout, and a share of the portfolio should keep doing exactly that, with the discipline above attached. But carve out a predetermined share of the portfolio - a quarter, maybe a third - for revenue-accretive investment: margin-producing, sponsored by someone with their name against the revenue and a date it's due, and tested honestly for cannibalization of your current product, because new revenue that's just old revenue arriving through a new channel doesn't count the same way.

That is where AI can change the shape of the business, not just the cost of running it. Changing the economics of margin-critical work. Disintermediating your own surrogates before someone else does. If a piece of your business is going to be reinvented, you want to be the one doing the reinventing.

That's a portfolio a CXO can actually hold a business to - the takeout named and harvested on one side, the revenue owned and dated on the other.

The question for the CXO

None of this argues for slowing down. The productivity is real; Uber's was.

The argument is that AI consumption is becoming a new enterprise utility: metered, variable, and increasingly embedded in everything the organization does. It behaves unlike almost anything else in the technology budget. It scales with enthusiasm, hides inside products, decays like technical debt, and often fails silently.

Treat it the way you'd treat any other material financial exposure: allocate it, govern it, tier it, forecast it at production volumes, plan for model retirement, validate where it matters, and make sure the savings are actually harvested rather than merely assumed.

And measure it with the right unit. The unit of management should not be tokens consumed. It should be cost per completed business outcome - a contract reviewed, a document processed, a support case resolved, a feature shipped. Tokens tell you what you spent. Outcomes tell you what you bought.

The companies that get this right won't be the ones that spent the least. They'll be the ones that understood the economics well enough to spend deliberately - and could explain exactly where the money went, why it created value, and who was accountable for both.