Earlier this year a friend at ElevenLabs told me he’d used up his $200 monthly AI budget. Not complained about it, told me. Like it was an achievement.
I pay for my own tokens. Around $600 a month, out of pocket. So my first reaction was not admiration, it was arithmetic.
That’s roughly the shape of the whole token maxing debate. Whether it looks smart or reckless depends almost entirely on who is holding the invoice.
First, some definitions, because the term is doing three jobs at once
There are three different things people mean when they say they’re maxing tokens, and they get conflated constantly:
| Name | What people mean |
|---|---|
| Context maxing | Filling the context window as full as it will go. Whole codebases, every retrieved document, the entire conversation history. The theory is that more context means better answers. |
| Reasoning maxing | Giving the model the largest possible thinking budget or output length, on the assumption that more tokens spent reasoning produces a better result. |
| Budget maxing | Deliberately spending the full allocated token budget every month, because unused budget is seen as unrealised productivity. |
This article is about the third one. It’s the one that got a name, a leaderboard, and then a retraction.
Where this came from
Early in 2026 several large companies started actively encouraging employees to consume as many tokens as possible. Meta was the loudest example. It ran an internal dashboard nicknamed “Claudeconomics” that ranked its top 250 most active users in real time. Top users earned titles like “Token Legend”. Employees coined the word “tokenmaxxing” for the competitive rush to rack up usage.
The numbers were genuinely startling. Meta employees consumed somewhere north of 60 trillion tokens in a 30 day period, with a single individual reportedly getting through around 280 billion. SemiAnalysis estimated this worked out to roughly $50,000 per employee per year at list prices.
Meta’s CTO Andrew Bosworth said at the time that his best engineer was spending the equivalent of his own salary in tokens, but was 5 to 10x more productive. His view was that this was easy money. Keep doing it. No limit.
Then in June, Meta sent a memo to around 6,000 employees mandating limits. The leaderboard was shut down two days after the SemiAnalysis report went public. The internal vocabulary shifted from “tokenmaxxing” to “tokenminimizing”.
Uber went through the same arc faster. It burned through its entire 2026 AI coding budget in four months and imposed a $1,500 per month per employee cap, with anything above that needing case by case approval. What makes Uber the more interesting data point is what their COO said about it: close to 95% of their engineers use AI tools monthly and around 70% of committed code is AI generated, but the link between token spend and measurable output “is not there yet”.
That’s the sentence I keep coming back to. Near total adoption, majority AI authored code, and still no demonstrated line from spend to output.
Who benefits from the hype
I want to be blunt about the incentive structure here, because I think it explains a lot of the noise.
The people loudest about maximising token consumption are, disproportionately, the people who sell tokens and the people who sell the hardware that produces tokens. A narrative in which unused budget equals wasted opportunity is extremely convenient if your revenue is metered per million tokens.
It’s worth noting how concentrated the actual spending is. Using Ramp data, SemiAnalysis found the top 1% of corporate customers spend close to $90,000 per employee per year on AI. The top 10% spend around $7,300. The median customer spends $136. Not $136 per month. Per year.
So when you read about token maxing, understand you are reading about the behaviour of a tiny sliver of extreme outliers, being reported as though it’s the frontier that everyone else is behind.
Goldman Sachs projects a 24x rise in enterprise token consumption by 2030. Maybe. But Sam Altman has himself acknowledged that companies keep telling him they’re spending a fortune on AI while knowing there’s a lot of waste in it. And a KPMG survey found only 26% of companies have comprehensive visibility into their AI costs. You can’t identify waste you can’t see.
There’s a second failure mode on the other side of this, and I don’t want to skip it. Plenty of people are still hesitant, hit the initial barrier of not knowing how the tools work or how to drive them, get a bad first result, and write the whole thing off. That’s also a mistake, and an expensive one. The answer to overspending is not underusing.
The case where it clearly worked
Any honest article about this has to deal with Bun.
Jarred Sumner rewrote Bun from Zig to Rust in 11 days. 535,496 lines of Zig became over a million lines of Rust. He ran up to 64 parallel Claude instances across roughly 50 workflows, producing 6,502 commits at a peak rate of around 1,300 lines per minute. It consumed 5.9 billion uncached input tokens, 690 million output tokens and 72 billion cached input token reads. Anthropic put the list price cost at about $165,000.
By any normal measure that is an enormous bill. It’s an engineer’s annual salary. It is also, fairly obviously, a bargain, because the alternative was a small team spending about a year on a migration branch while feature work and security fixes stalled behind it.
But look at why it worked, because this is the actual lesson and it gets skipped in most of the coverage:
- The old Zig code was a behavioural reference. There was a correct answer to compare against, file by file.
- There was a machine oracle for correctness. The Rust compiler and Bun’s existing CI suite. When the rewrite produced roughly 16,000 compiler errors, that wasn’t a disaster, it was a worklist.
- The work was embarrassingly parallel. 1,448 files that could largely be ported independently.
- There were written constraints: a PORTING.md and a LIFETIMES.tsv that every agent had to follow.
- There was adversarial review built into the loop. Each file had one implementer, two reviewers checking the Rust matched the Zig behaviour, and a fixer.
None of that is “give the agents a big budget and let them cook”. It’s a constrained, repeatable pipeline where the tokens were the cheap part and the process design was the expensive part.
And even then it wasn’t clean. 19 regressions were fixed after the fact, and Zig’s creator Andrew Kelley publicly called the result unreviewed slop. Reasonable people still disagree about whether the resulting codebase is genuinely maintainable.
So what are the actual parameters?
Pulling my own experience together with the public cases, here’s when high spend is justified and when it’s just consumption.
| Question | High spend is justified when |
|---|---|
| Is correctness machine verifiable? | A compiler, a test suite, or an eval can tell you the output is right. |
| Can the work be parallelised? | The work splits into independent chunks. |
| What is the value of compressing the calendar? | Doing it sooner is worth paying for. |
| Is the task actually at the frontier? | A cheaper model is not good enough for this task. |
| Is spend a metric anyone is judged on? | It is not. Once usage is a score, it stops measuring the work. |
1. Is correctness machine verifiable? This is the big one. If a compiler, a test suite, a type checker or a solid eval harness can tell you whether the output is right, you can afford to let the model attempt things many times cheaply. If the only oracle is a human reading the output carefully, your bottleneck is human review time and more tokens just widens the queue. Generating a million lines of unreviewable prose is not productivity.
2. Can the work be parallelised? Token spend converts to speed when the work splits into independent chunks. It converts to nothing much when the work is one long sequential reasoning chain that you have to babysit anyway.
3. What is the value of compressing the calendar? Bun’s real product wasn’t a million lines of Rust, it was getting a year of migration done in 11 days while continuing to ship. If there’s no strategic value to doing it faster, paying a premium for speed is just paying a premium.
4. Is the task actually at the frontier? This is where my own habits have changed most. I’ve been using LLMs seriously for about two and a half years now, for code and for documents like marketing plans, proposals, blog posts. For a long time I reached for the most capable model available by reflex. I don’t anymore. For a lot of work, building websites being the obvious example, cheaper models like GLM 5.2 or GPT 5.6 Luna are simply good enough. Paying frontier prices for commodity tasks is the most common form of waste I see, and it’s invisible if you’re not looking.
5. Is spend a metric anyone is judged on? The moment token consumption becomes a performance signal, it stops being a measure of anything. Meta discovered this the expensive way. Goodhart’s law does not make an exception for AI.
What failure actually looks like
Not one dramatic blowup. It’s quieter than that:
- Budget exhausted early in the period. Uber’s entire year gone in four months. You then spend the rest of the year in approval workflows, which costs more in human time than it saves.
- Adoption without attribution. 95% usage, 70% of code AI generated, and still nobody can draw the line to output. If you can’t attribute the spend, you can’t defend it in the next budget round.
- The review bottleneck. Generation gets cheap, verification doesn’t. Output piles up faster than anyone can check it and quality quietly degrades. This is the slop problem, and it’s a process failure, not a model failure.
- Frontier pricing for commodity work. The largest model on every task by default. Usually the single biggest line item you could cut without noticing any difference.
- Gamed metrics. Leaderboards, targets, penalties for underuse. People pad usage to hit a number, and now your telemetry is fiction.
- No cost visibility at all. Three quarters of companies are in this position. You cannot manage what you cannot see.
One thing I’d flag from my own recent experience: some of the classic justifications for heavy spend have quietly weakened. I used to lose a lot of tokens to coding agents going rogue or grinding away on a gnarly problem. That happens noticeably less now. Better models have absorbed some of the waste that heavy consumption used to be compensating for.
Where I’ve landed
Token maxing as a goal is a category error. Tokens are an input. Nobody ever measured a factory by how much electricity it drew.
Token maxing as a tactic, deployed deliberately on work that is verifiable, parallel and calendar-critical, is one of the highest leverage moves available right now. Bun proves that, and I don’t think the sceptics have a good answer to it.
The distinction is whether the spend is designed or default.
What I’d actually suggest, especially if it’s your own money:
- Set a budget, then track what you got for it. Even roughly. Even in a spreadsheet.
- Route by task, not by habit. Cheap models for the bulk, frontier models where the task genuinely demands it.
- Spend heavily where there’s a machine oracle. Spend carefully where a human is the only reviewer.
- Treat any leaderboard, quota or usage target as a red flag, not a scoreboard.
- If you’re underusing out of hesitancy, fix that first. Underuse is the more expensive error, it just doesn’t show up on an invoice.
The industry has already run this experiment for us, at a scale none of us could afford. It went from tokenmaxxing to tokenminimizing in roughly six months. The interesting question was never how many tokens you burned. It’s what came out the other end.