Tokenmaxxing Is Dead. Your Forecast Was Never the Problem.

In March, Jensen Huang told the All-In Podcast that if a $500,000 engineer came back at year's end having spent only $5,000 on tokens, "I will go ape something else." His benchmark: "If that $500,000 engineer did not consume at least $250,000 worth of tokens, I am going to be deeply alarmed."

In May, Sam Altman said he was excited to see what tokenmaxxing startups would build. Meta ran an internal competition rewarding token usage. Uber put up leaderboards ranking teams by AI usage, which seems clever right up until it isn't.

Last week the AP ran the obituary. Vincent Gusdorf, who runs AI analytics at Moody's Ratings, delivered the eulogy in one line: "It's very easy to create something you don't need with AI."

Five months from flex to cautionary tale.

I spent the last few years as a founding engineer at a fintech, which is a polite way of saying I stared at ledgers until the numbers stopped making sense and then made them make sense again. From that seat, the post-mortem everyone is writing looks wrong. The story being told is that companies overspent. The more interesting story is that they couldn't have known they were about to.

Michael Parekh put it better than I can, so I'll borrow it: token prices are falling hard, and token bills are rising hard. Same market, same quarter, often the same customers.

The falling half is real. Optimum Partners looked at 2.4 billion enterprise API calls and found the blended cost dropped from $18.40 per million tokens in Q1 2025 to $6.07 a year later.

The rising half rarely makes the headline. Frontier pricing has roughly doubled since January, because each new generation charges a premium for capability. The cheap stuff got cheaper, the good stuff got pricier, and if your budget assumed "prices fall every year," you built it on a half-truth.

Then there's the invoice.

Uber exhausted its entire 2026 AI budget by April. Four months into a twelve-month year. CTO Praveen Neppalli Naga told The Information the budget he thought he'd need was already blown away. Claude Code had reached roughly 5,000 engineers, adoption jumping from 32% in February to 84% by March.

Uber spent $3.4 billion on R&D last year. This is not a company that can't afford software. It's a company whose finance model had no idea what it was looking at.

Nor is it an outlier. The FinOps Foundation found 73% of enterprises exceeded their AI cost projections this year, and 98% of practitioners now actively manage AI spend, up from 31% two years ago. That's not adoption. That's a fire drill.

Here's where I think the industry is misdiagnosing itself.

When a budget blows up, the reflex is to assume somebody spent carelessly. So the fixes on offer are all about restraint after the fact. Downgrade the model. Trim the seats. Send a Slack message asking everyone to be mindful about AI usage. (That one has never worked for anything, ever, but we keep trying.)

The more aggressive version of this is the kill switch: watch consumption in real time and cut the agent off when it runs hot. I understand the appeal, and I don't think many engineering teams actually want it. Nobody wants a production feature terminated mid-run because a threshold tripped at 3am. That's not governance, that's an outage with a budget-shaped excuse.

The problem isn't that companies forecast badly. It's that a forecast for an AI feature has no relationship to the thing that eventually ships.

Think about how the cost of an agent feature is actually determined. How much context you stuff into each call. Whether it runs synchronously for a waiting user or async in a batch. Which harness it runs in. How many tool calls per task. Your retry policy. Which model tier you route to. Whether you added a verification pass.

Every one of those is an architectural decision made at design time. None of them is a runtime accident. Which means the cost of a feature is substantially knowable before a single token is spent, if anyone bothers to write the assumptions down.

Almost nobody does. And on the rare occasion someone does, the estimate goes into a doc and dies there.

Then development happens, which is to say the assumptions quietly change. Someone bumps the context window to fix a quality issue. Someone adds a second tool call. Someone switches from mid-tier to frontier because the evals looked better. Someone wraps it in a verification loop so the output can be trusted.

Every one of those decisions is defensible. Most of them are correct. And not one of them triggers anybody re-running the math. The feature ships, the invoice arrives eight weeks later, and finance gets to discover the architecture retroactively, through a number.

That's the gap. Not spending discipline. Not observability. The complete absence of a connection between the estimate and the build.

We already know how to do this, because engineering does it with every other scarce resource.

Latency budgets exist. Push p99 past the threshold and the pipeline goes red before the change ships. Bundle size budgets exist, and the front-end world takes them seriously enough to fail a build over a few extra kilobytes. Error budgets exist, with an entire SRE discipline built on them, and they work differently in a way worth noticing: burning one doesn't block a merge, it triggers a conversation and often a feature freeze.

None of those are kill switches. They're constraints stated up front, checked continuously, and escalated to a human when something needs to give. Sometimes the right answer is "yes, this feature is worth the extra 200ms, ship it." The point isn't to prevent the decision. It's to make sure a decision actually gets made, by someone who owns the tradeoff, before it's expensive to reverse.

Cost is the constraint where we've barely started. A few early tools have noticed. There are PR checks now that estimate what a prompt change does to your bill and fail a status check if the delta breaks a budget, and one of them describes itself, wonderfully, as bundlewatch for tokens. They borrow the pattern the cloud world already built for infrastructure spend.

Which tells you the instinct is right and the coverage is thin. These tools diff prompts and replay canned scenarios. They'll catch a prompt getting 4% more expensive. They won't tell you that switching a feature from async batch to a synchronous user-facing path, with a retry policy and a verification pass, just moved it from $40K a month to $180K. That isn't a prompt change. It's an architecture change, and it doesn't show up as a diff in a file anyone is watching.

And none of them answer the question that actually matters, which is who gets told. A failed CI check stops a developer. It doesn't put a number in front of the VP who signed off on $40K and would quite like to know before the quarter ends.

The rest of the tooling landscape enters even later. Observability platforms start at runtime, which is after the architecture is set. FinOps tooling starts at the invoice, which is after runtime. Both are looking at the consequences of a decision nobody was measuring when it was made.

The interesting work is upstream of all of it: making a forecast into a set of explicit, checkable assumptions, and giving the person who owns the budget a number before the thing ships rather than a bill afterwards.

The Token Effort covers AI cost governance: forecasting, attribution, and the gap between what gets estimated and what gets built. Expect token economics, the tooling landscape, agentic commerce, and the strange new job titles companies are inventing to cope.

Three days ago the Linux Foundation launched the Tokenomics Foundation with 29 founding members, including JPMorgan Chase, IBM, Oracle and SAP. Good sign the problem is real. Also a good sign that most of what gets written about it from here will come from people with something to sell you.

New issues weekly. If you're living through this inside a company right now, hit reply and tell me about it. I collect these.