Stop Tokenmaxxing. Start Asking What You Got For It.

In March, Jensen Huang gave the tech world a new way to feel inadequate. On the All-In Podcast, the Nvidia CEO said he would be "deeply alarmed" if one of his $500,000 engineers burned less than $250,000 a year in AI tokens. Spend only $5,000, he said, and "I will go ape." His analogy was sharp: an engineer who will not spend on tokens is like a chip designer who insists on paper and pencil while everyone else uses CAD.

Huang's underlying point is right, and worth taking seriously. His argument was about amplification: hand a great engineer the best tools and they compound into something far more productive, and refusing those tools is as self-defeating as clinging to paper and pencil while the rest of the world moved to CAD. That is a claim about leverage, not about spending for its own sake.

But notice what the number does not say. It does not say what those $250,000 in tokens should produce. Stripped of the context he gave it, "$250,000 in tokens" is easy to hear as a target in itself, a threshold to clear rather than the byproduct of ambitious work. And a figure that travels without its context tends to become the goal. That is how a genuinely smart point about amplification gets flattened into something much dumber on the way down. We even have a word for the flattened version now, and plenty of people wear it as a badge: tokenmaxxing. The pursuit of token consumption as an end in itself, as if a bigger number on the meter were the accomplishment.

About a month later, Uber showed what that looks like at scale. By April it had burned its entire 2026 AI budget, four months into the year, after Claude Code spread across roughly 5,000 engineers faster than finance could model. And it would be too easy to file this under simple waste, because the details cut the other way. The tool did not break, and the engineers were not gaming it. They pointed it at precisely the work it was built for: running agents in parallel, refactoring sprawling codebases, generating test suites, writing backend code. The average engineer ran $150 to $250 a month, power users $500 to $2,000, and Uber's own CTO managed to spend $1,200 in a single two-hour demo. Judged by productivity, the rollout looked like a success; judged by the budget, it was a runaway.

What makes Uber worth citing is a detail in how it managed all this: the company had ranked engineers on internal leaderboards by their Claude Code usage. It is impossible to say how much that particular incentive drove the bill, and plenty of the climb was simply the tool proving useful, with agentic adoption jumping from 32% of engineers in February to 84% by March. But a leaderboard makes the culture's real scoreboard explicit. When consumption is the number you rank people by, consumption is the thing you are quietly asking for.

When Uber's COO later tried to connect all those consumed tokens to results, he could not draw the line: maybe more was shipping, he allowed, but it was very hard to claim the company was producing meaningfully more useful features for customers. So the same spending was a triumph and a disaster at once, and a consumption number can never tell you which. It records how much you burned, never whether burning it was worth doing.

That is tokenmaxxing made literal: a number that goes up, mistaken for progress. And it should feel familiar, because we have made this exact error before. We once counted lines of code and called the person with the most the most productive. We learned, slowly and expensively, that ten thousand lines can be worth less than the twenty that delete them.

So here is the argument I want to make, and it is not the one you might expect from someone who works on cost management. I am not telling you to spend less. Sometimes the right move is to spend a fortune in tokens. The mistake is not the spending. The mistake is the scoreboard.

Consumption is an input wearing an output's costume

Tokens are seductive to measure for the same reason lines of code were. They are countable, they show up on a dashboard, and they go up when you are busy. Real output, the kind that matters, is slower and harder to see. Did the feature ship? Was it correct? Could someone else understand it? Did it move a number a customer cares about? Those questions take weeks to answer. Token spend answers instantly, and instant answers are the ones organizations fall in love with.

But an instant answer to the wrong question is still the wrong answer. A coding agent that loops for four hours and 400,000 tokens on a bug a human fixes in one line has consumed magnificently and produced almost nothing. A ten-thousand-line "comprehensive refactor" that no one can safely review is not ten thousand lines of progress. It is ten thousand lines of new liability. High consumption and high value sometimes travel together. The error is assuming they always do.

The opposite mistake is just as easy

Here is the trap that catches people who read the Uber story and overcorrect. If tokenmaxxing is dumb, the fix must be to cap everyone hard and treat frugality as a virtue: hand out $250 a month, switch off the expensive models, reward the people who spend least. Some companies are already doing exactly this.

It is the same mistake in a mirror. Whether the message a culture absorbs is "spend big or something is wrong" or "spend as little as possible," it lands in the same place: a consumption number is the scoreboard. One version wants it high, the other wants it low, and neither one asked the only question that matters. What did we get?

Worth remembering, too, that the viral horror stories are the tail, not the typical case. Anthropic's own documentation puts average Claude Code usage at $150 to $250 per developer a month, with 90% of developers staying under $30 on any given day. Most people are not tokenmaxxing. The headlines are about the extremes, and building your whole policy around an extreme, in either direction, is how you get a bad policy.

A better question than "how much?"

If neither "more" nor "less" is the goal, what do you actually steer by? Start with the outcome and work backward. Before a big agent run, write down what a good result looks like and roughly what it is worth. If you cannot articulate that, the problem is not your token budget. It is that you have not defined the job. A surprising amount of tokenmaxxing is really procrastination in an expensive costume: throwing compute at a problem you have not bothered to specify, because generating something feels like progress while thinking is hard.

If you want something to glance at, you could look at what you got back relative to what you spent. Call it return per inference if you need a name for it. But be careful: the moment you turn that ratio into a target, you have just built a newer, shinier scoreboard, and you are back where you started. It is worth a glance only because it points at the question tokenmaxxing skips entirely, which is what the spending actually produced. It will not capture everything. Not code quality, not what your team learned, not the outage you quietly avoided. Nothing will. Productivity does not collapse into a single number, and pretending otherwise is the mistake we are trying to climb out of, not a cleverer version of it.

But tokens are getting cheaper

The strongest objection is that all of this is temporary. Inference gets cheaper every quarter, so why fuss over waste that will soon cost nothing?

Because the token was never the expensive part. When generation is free, the bottleneck moves to the things that stay scarce: the latency of waiting on a run, the human hours spent reviewing output, the complexity a codebase has to carry forever, the cost of a confident mistake shipped because no one could check the work in time. Abundant intelligence does not make judgment abundant. As the machines get cheaper at producing, the rare and valuable skill becomes knowing what is worth producing, and being able to trust what comes back. Tokenmaxxing optimizes the one input that is racing toward free while ignoring everything that remains expensive.

What to actually do Monday

Do not maximize tokens. Do not minimize them either. Delete the leaderboard. Spend what the problem is worth, which sometimes is a fortune and sometimes is nothing, and judge the result by whether it was correct, understood, and useful. The engineers who win the next few years will not be the ones who consumed the most intelligence or the least. They will be the ones who knew what they were trying to get, and could tell whether they got it.

The irony is that once you stop chasing the consumption number, you finally get a reason to look at it honestly: not as a scoreboard to top, but as one input you weigh against the outcome it bought. That is the whole reason we build cost management for AI, and it is also why we would rather you spend well than spend little.

Sources

1. Jensen Huang Says $500K Engineers Should Use at Least $250K in Tokens, Business Insider.
2. Uber Burns Its 2026 AI Budget In Four Months On Claude Code, Forbes.
3. Uber Burned Through Its Entire 2026 AI Budget in Four Months. Now Its COO Is Questioning Whether It's Worth It, Fortune (via Yahoo Finance).
4. Manage costs effectively, Claude Code Docs (Anthropic).