From Token Maxing to Token Minimizing

You wouldn't hire a professor to say good morning. Yet every time I open a chat with "Hey Saira, are you there?", that's what I'm doing. Which is, frankly, stupid. 🎓

Saira is my AI chief of staff. (If you'd like one of your own, my free ebook shows you how to build your own AI agent.) My greeting is a harmless habit. This year, a lot of companies turned the same habit into a target. They called it tokenmaxxing, or token maxing: ranking people by how many tokens they burned. Tokens are the small pieces of text an AI reads and writes, and you pay for every one of them.

Now the pendulum is swinging back, and companies are swapping their leaderboards for budgets and caps. So is the next big thing in AI going to be token minimizing, not token maxing? I believe it is, but not the way most companies are doing it. Capping tokens is the same mistake as ranking them. If you run AI pilots, the decision you own is a different one: which steps deserve a model at all.

The leaderboard and the cap count the same thing

Token maxing peaked this spring. In March, Nvidia's Jensen Huang said he'd be "deeply alarmed" if a $500,000 engineer didn't use at least half that amount in tokens [1]. Keep in mind that Nvidia sells the chips those tokens run on.

Inside Meta, an employee built a leaderboard that ranked colleagues by the tokens they burned, with titles like "Token Legend." At Amazon, some staff ran AI on trivial tasks to climb a similar board. Both boards were gone within weeks [2].

This week, Amazon made the lesson public. In a memo posted on its company news site, its engineering leadership wrote that tokenmaxxing "is at odds with frugality." And: "If your work does not benefit from current AI tooling, that is a finding, not a failing" [2].

So now come the budgets. Uber ran through its AI coding budget for 2026 within months, and by August its CTO was calling it the end of the "tokenmaxxing era." Accenture now caps the Claude use it pays for at $29 a month for many of its staff [3]. As a safety fuse, a cap makes sense. It stops a runaway agent from burning money all weekend.

But look at what a cap measures. It counts tokens, just like the leaderboard did, with a ceiling instead of a prize. It can't tell you which tokens were wasted and which ones did the real thinking. So your people will learn to stay under the line. They'll hold back the big model on the hard question that needs it, and keep spending it on good morning.

A cap is just a leaderboard turned upside down.

Programmers have been here before. In 1988, the computer scientist Edsger Dijkstra wrote that lines of code should be counted as "lines spent," not "lines produced" [4]. Tokens work the same way. They belong on the cost side of the ledger. The leaderboard treated that cost as output, and the cap treats it as the problem. Neither one tells you where the value is.

The real problem is the answers you can't check

A cap answers a question about the bill. Coding teams like Uber's are the exception, because they run AI all day long. For most companies, I don't think cost is what's stopping anyone yet. Token prices are subsidized today: OpenAI, for one, still spends far more than it earns [5]. And the CEOs I talk to aren't anywhere near their token budgets. That's because their AI isn't running at scale yet.

Here's why. A language model gives excellent answers most of the time. A few percent of the time, it makes something up, and you can't tell which answers those are [6]. That's what keeps their pilots out of production.

In April 2025, the support bot of Cursor, a popular coding tool, told a customer that one subscription works on one device only. There was no such policy. Users said they were cancelling before a cofounder posted that the bot had gotten it wrong [7]. That question had one right answer, and a simple lookup would have given it every time.

Code has bugs too. But it does the same thing every time, so a test can catch the bug before a customer does. That's something you can trust in production.

You can't scale what you can't check.

Token Triage decides which steps deserve a model

So stop counting tokens and look at the work itself. A good hospital doesn't send every patient to the professor. Someone sorts them first, and only the hard cases go upstairs. Token Triage does the same for your AI. It's three questions you ask about every step in a workflow before you give it a model. I use them for my own agents, and they start with the cheapest option.

1. Can a rule do it? Then let the smart model write the code and the tests, and step away. Once the code runs, it costs nothing in tokens.
2. Is it a simple choice between a few options, like where to send a message or how to label it? Then a cheaper, specialized model can handle that one step, often one built for exactly that kind of call.
3. Is it new, messy, or broken? Then call in the frontier model, the biggest and most capable one. It builds the system, fixes it when a test fails, and protects it against attacks.

Today, most people select the heaviest model and leave it. I'm guilty of it too. Token Triage turns that around. The biggest model still does the hardest work: it writes the code, the tests and the fixes. Then it steps aside, and you only call it back when a test fails.

Airbnb showed what that looks like at scale. In 2025, it described how it had used AI models to move thousands of test files to a new framework. Every file had to pass its tests and other automatic checks before it moved on. When a check failed, the model got the errors back and tried again. A job Airbnb had estimated at a year and a half of engineering time took six weeks [8].

Engineers still spent days tuning the process and fixed the last few percent of files by hand. But the model never decided when a file was done.

The tests did.

I'm not the first to point in this direction. Even Anthropic, which sells some of the biggest models, tells builders to start with the simplest solution and to add complexity only when they need it [9].

In my inbox, the gate comes before the genius

Here's how I use this myself. Before any language model reads my mail, a decision model judges it first. A decision model is a fast model that can't write a sentence. It only makes a call, like "safe" or "suspicious." Mine runs on Jev, from a company called TypeSafe. That's question two in practice, and I've written about where decision models fit before.

I built it to protect myself against prompt injection, where someone hides instructions for the AI inside an email. Suspicious messages are set aside before the language model ever sees them. Since then, the decision model also sorts the rest of my mail by type.

So every message gets judged first, and the expensive model only reads what gets through. (I wrote about what else that inbox clears away in an earlier post.) I use fewer tokens, and the system is safer, because the language model only sees mail that has already been judged.

Fewer tokens turned out to mean fewer surprises.

The same gate works for any workflow where outsiders send you text, from customer emails to supplier invoices.

Take the invoices. Checking that an invoice matches a purchase order is a rule, so the big model writes it once as code. Telling an invoice from a reminder or a complaint is a simple choice for a specialized model. The odd one, a disputed amount with an angry note, goes to the frontier model or to a person on your team.

In your company, you can run Token Triage on every AI pilot. Go through each step and mark it: code, small model, or frontier model. My guess is you'll need the frontier model for fewer steps than you expect. Your IT team can build it. Deciding where the real thinking happens is your call.

Cheaper, smarter models won't make this go away

You might think I have this backwards. Prices per token have been falling fast for years, and the AI researcher and educator Andrew Ng has advised teams "to focus on building a useful application rather than on optimizing LLM costs" [10]. And the history of AI suggests that big, general models tend to beat hand-built rules in the end.

On cost, he's right. If your only reason to use fewer tokens is the bill, wait a year and the problem shrinks. Some steps should also move to the model. Reading a messy handwritten form or judging the tone of an angry email is work that code has always done badly.

But the bill was never my argument. A cheaper model still makes things up a few percent of the time, and you still can't tell which answers those are.

A lower price doesn't make an answer more reliable.

And the code in Token Triage isn't written by hand. The big model writes it. You aren't betting against AI. You're asking it to leave behind something you can check.

The professor can wait for the real question

So back to my greeting. Run "Hey Saira, are you there?" through Token Triage. Can a rule do it? Yes. A simple rule could answer "I'm here" and bring in the big model only when the real question comes.

I'll probably keep saying it anyway, and the professor will keep saying good morning. In a chat, that's fine. But in a workflow your company runs all day, every day, that same habit is what keeps your pilot from going live.

So stop counting tokens, up or down. Count something else: the steps your AI made boring. Every step that became plain, tested code is a step you can trust, and a step that no longer needs a model. That's the number I'd want on a leadership dashboard.

The smartest thing a smart model can do is write itself out of the job.

Decide which steps in your AI pilot deserve a model, and make the rest boring.

Books

Two books. One argument. A field manual to think the Agent-First Era, and a novel to feel it.

Peter van HeesPeter van Hees

References

1. Lee Chong Ming, "Jensen Huang says he would be 'deeply alarmed' if his $500,000 engineer did not consume at least $250,000 of tokens," Business Insider (via AOL), 20 March 2026, https://www.aol.com/news/jensen-huang-says-deeply-alarmed-040314321.html ; Matthias Bastian, "Nvidia CEO Jensen Huang says he'd be "deeply alarmed" if a $500K developer spent less than $250K on AI tokens," The Decoder, 21 March 2026, https://the-decoder.com/nvidia-ceo-jensen-huang-says-hed-be-deeply-alarmed-if-a-500k-developer-spent-less-than-250k-on-ai-tokens
2. Jacqueline Munis, "A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user—and Zuckerberg doesn't even rank in the top 250," Fortune, 9 April 2026, https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/ ; AJ Dellinger, "Cast Adrift, Meta Employees Have No Idea Who the 'Token Legend' Is Anymore," Gizmodo, 8 April 2026, https://gizmodo.com/?p=2000744189 ; Kay Ewbank, "Amazon Moves To Reduce TokenMaxxing," I Programmer, 1 June 2026, https://www.i-programmer.info/news/105-artificial-intelligence/18905-amazon-moves-to-reduce-tokenmaxxing.html ; Terk Terkowitz (Amazon), "An update from Amazon engineering leadership on the role of the developer in the age of AI," About Amazon, 27 October 2026, https://www.aboutamazon.com/news/company-news/amazon-software-engineer-role-guideline-ai ; Mia Osmonbekov, "Amazon warns against tokenmaxxing and tells engineers to use their judgment when using AI," Fortune, 28 October 2026, https://fortune.com/2026/10/28/amazon-token-maxxing-ai-work/
3. Sasha Rogelberg, "After blowing through AI budget in a matter of months, Uber CTO says tokenmaxxing era is over," Fortune, 7 August 2026, https://fortune.com/2026/08/07/uber-ai-spending-tokenmaxxing-is-over-cto ; Ana-Maria Stanciuc, "Uber's tech chief says the AI 'tokenmaxxing' era is ending," The Next Web, 6 August 2026, https://thenextweb.com/news/uber-cto-tokenmaxxing-era-ending-ai-spending ; Alina Maria Stan, "Accenture caps staff Claude spending at $29 a month, 404 Media reports," The Next Web, 16 October 2026, https://thenextweb.com/news/accenture-claude-29-a-month-cap
4. Edsger W. Dijkstra, "On the cruelty of really teaching computing science" (EWD 1036), Austin, 2 December 1988, https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
5. Jon Swartz, "OpenAI's Fast-Growing Revenues Outpaced by Massive Scale of Losses Ahead of Expected IPO," Techstrong.ai, 17 June 2026, https://techstrong.ai/articles/openais-fast-growing-revenues-outpaced-by-massive-scale-of-losses-ahead-of-expected-ipo/ ; Ed Zitron, "Exclusive: OpenAI Losses Increased Nearly 8X in 2025, With Spending Hitting $34 Billion," Where's Your Ed At, 15 June 2026, https://wheresyoured.at/exclusive-openai-financials
6. Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala, and Edwin Zhang, "Why Language Models Hallucinate," arXiv:2509.04664, 4 September 2025, https://arxiv.org/abs/2509.04664 ; Sebastian Farquhar, Jannik Kossen, Lorenz Kuhn, and Yarin Gal, "Detecting hallucinations in large language models using semantic entropy," Nature 630, 625-630, 19 June 2024, https://doi.org/10.1038/s41586-024-07421-0
7. Sharon Goldman, "A customer support AI went rogue—and it's a warning for every company considering replacing workers with automation," Fortune, 19 April 2025, https://fortune.com/article/customer-support-ai-cursor-went-rogue ; Aminu Abdullahi, "AI Chatbot Gone Rogue: Cursor Users Misled by Fabricated Policy," eWeek, 22 April 2025, https://www.eweek.com/news/cursor-ai-chatbot-hallucination-fake-policy/
8. Charles Covey-Brandt, "Accelerating Large-Scale Test Migration with LLMs," Airbnb Engineering, 2025, https://airbnb.tech/?p=366 ; Sergio De Simone, "How Airbnb Used LLMs to Accelerate Test Migration," InfoQ, 28 March 2025, https://www.infoq.com/news/2025/03/airbnb-llm-test-migration/
9. Erik Schluntz and Barry Zhang, "Building effective agents," Anthropic, 19 December 2024, https://www.anthropic.com/engineering/building-effective-agents
10. Andrew Ng, "Falling LLM Token Prices and What They Mean for AI Companies," The Batch, DeepLearning.AI, 28 August 2024, https://www.deeplearning.ai/the-batch/falling-llm-token-prices-and-what-they-mean-for-ai-companies