Short answer: tokenmaxxing is the habit of burning as many AI tokens as possible to look productive, often to climb an internal usage leaderboard. Tokens are a cost, not a result. The teams getting the most from AI do the opposite: they get the same or better work from fewer tokens, using caching, skills, compaction and the right model for each task, and they judge AI on the business outcome it changes.
This year a strange new metric arrived in large technology companies: who used the most AI. Leaderboards ranked employees by the tokens they consumed. Some people climbed them by asking AI questions they could have answered themselves. The internet named it tokenmaxxing.
It’s easy to laugh at. It’s harder to notice the same instinct in your own business, where the board pack now has an “AI adoption” slide showing licences issued and active users, and nobody can say what those users produced. That’s the same mistake on a smaller budget.
What is tokenmaxxing?
A token is the unit AI models read and write in, roughly three quarters of a word. AI providers bill by the token, so token counts are a precise measure of how much AI someone used, and how much it cost.
Tokenmaxxing is treating that number as a score. The best-documented examples so far:
- Meta. An employee built an internal leaderboard, called “Claudeonomics”, ranking more than 85,000 staff by token use and handing the top users titles like “Token Legend”. The Information reported Meta staff used about 60.2 trillion tokens in 30 days, which The Pragmatic Engineer estimated at around US$900M at list API prices. The board came down within days of being reported.
- Microsoft and Salesforce. The same report describes senior leaders near the top of a token leaderboard despite writing little code, and minimum monthly AI spend expectations for engineers, with some building throwaway projects to stay above their peers.
- Amazon. The Financial Times reported that employees ran the company’s internal AI tool on trivial tasks to inflate their counts, according to Fortune.
The experts CIO spoke to broadly agreed: token counts are easy to game, and making them the KPI rewards the volume people produce rather than the outcomes they deliver.
Why token counts don’t measure business value
Tokens measure input, not output. A long prompt, a rambling answer and an agent stuck in a loop all score well. A one-line question that saves an afternoon scores badly. The metric rewards the opposite of efficiency.
Any measure that becomes a target stops measuring. This is Goodhart’s Law, and software engineering has learned it before. Lines of code were once used to rank programmers, until everyone noticed that the best change often deletes code. Tokens are lines of code for the AI era.
More tokens means more cost. A business pays for every token, either directly or through the licence it negotiates next year. Rewarding consumption is rewarding spend. No CFO would rank a sales team by who spent the most on travel.
Volume can hide damage. Engineers interviewed by The Pragmatic Engineer linked some of Meta’s outages to careless AI-generated code, and said top-ranked users often produced throwaway work. Output nobody checks isn’t productivity. It’s rework with a delay.
Vendors report what they bill. AI platforms measure tokens, seats and sessions because that’s what they charge for. Their usage dashboards are accurate. They just answer the vendor’s question, not yours.
What happens when usage becomes the goal
Uber is the clearest public case so far. Fortune reported in May 2026 that Uber used its entire 2026 budget for AI coding tools in about four months, after an internal leaderboard ranked teams by how much they used them. Adoption worked. The spend arrived well ahead of plan.
What hadn’t arrived was the connection to results. Asked whether the rising use of AI coding tools was turning into features customers use, Uber’s president and COO, Andrew Macdonald, said: “That link is not there yet.” He added that the spend gets harder to justify if that connection can’t be shown.
That’s a company with a research and development budget of nearly US$1 billion a quarter, according to the same report. A mid-market business can’t absorb a year’s AI budget disappearing by April.
Why this matters to a mid-market business
Most mid-market businesses won’t build a token leaderboard. But the same thinking turns up in quieter forms:
- an “AI adoption” KPI measured as licences issued or weekly active users
- a mandate that every team “uses AI every day”
- a pilot judged a success because people liked it and usage grew
- an AI budget that rises each quarter with no line back to the P&L
Each of these measures activity. None of them tells the board whether the business is better off.
The test I use is simple: if this metric doubled, would the business be better off? Double the tokens and you double the bill. Double the invoices processed per person and you have a result.
Fewer tokens, better results: how to build with AI efficiently
The real skill is the opposite of tokenmaxxing. Frontier models are the most capable and the most expensive per token, so good teams spend those tokens where they earn their keep and strip out everything else. Less noise in the context usually means better answers too, because the model isn’t wading through material that has nothing to do with the task.
These are the habits I use when building with these tools, and they’re the ones the AI providers recommend in their own documentation.
1. Keep the context small, and clear it between tasks
Every message to an AI model resends the whole conversation so far. A chat that has run all morning bills you for the whole morning each time you ask a one-line question. Anthropic’s cost guide for Claude Code puts it plainly: start fresh with /clear when you switch to unrelated work, because stale context costs tokens on every message that follows. OpenAI’s Codex has /new for the same reason. In ChatGPT or the Claude apps, the equivalent is starting a new chat for a new task.
2. Compact long sessions instead of dragging them on
When a task really does need a long session, compaction summarises the older history so the model keeps the thread without carrying every word. Claude Code compacts automatically as a session nears its limit, and /compact lets you say what to keep, for example /compact Focus on code samples and API usage. Codex has a /compact command for the same job.
Compaction is lossy, so tell it what matters. And it isn’t free: summarising a large conversation is itself a large request. When you want a fresh start rather than continuity, clearing costs nothing.
3. Move standing instructions into skills
Most teams give their AI a long instruction file: house style, review rules, deployment steps. In Claude Code that’s CLAUDE.md, in Codex it’s AGENTS.md, and in ChatGPT it’s custom instructions or a project. All of it is loaded into every conversation, whether it’s relevant or not.
Skills fix this. A skill is a packaged set of instructions for one job, and both Claude and ChatGPT and Codex load only each skill’s name and short description up front. The full instructions load only when the task needs them. Anthropic recommends moving workflow-specific instructions out of CLAUDE.md into skills and keeping that file under about 200 lines.
4. Put the fixed content first so it’s cached
If every request starts with the same instructions, documents or examples, providers can cache that part and charge far less to reread it. The discounts are large:
| Provider | How caching works | Cached input price |
|---|---|---|
| Anthropic (Claude) | You mark what to cache | A tenth of the normal input price, less on some newer models |
| OpenAI (ChatGPT API, Codex) | On by default for supported models | Discounted by up to 95% |
| Google (Gemini) | Implicit caching, on by default | A 90% discount on cached tokens |
The rule that makes it work is the same everywhere: stable content at the start of the prompt, the part that changes (the question, the new document) at the end. Change the start and the cache is lost.
5. Match the model and the effort to the task
Not every task needs the most powerful model or its deepest reasoning. Anthropic’s guidance is to use Sonnet for most coding work, keep Opus for complex architecture and multi-step reasoning, and give simple helper tasks to Haiku. Claude Code’s /effort and Codex’s /model and /reasoning commands set how hard the model thinks, and reasoning tokens are billed like any other output. Formatting a table or renaming files doesn’t need maximum effort.
6. Give the AI less to read
The biggest savings often come from not sending the tokens at all.
- Load tools only when they’re needed. Connecting an AI to many systems used to load every tool’s description into every request. In one example from Anthropic’s engineering team, letting the agent find and load tools only as it needed them cut a workflow (moving a meeting transcript from Google Drive into a Salesforce lead) from 150,000 tokens to about 2,000, a 98.7% reduction.
- Filter before the model reads. Rather than having the model read a 10,000-line log to find the errors, a small script can pass it only the error lines. Anthropic’s guide gives that example: tens of thousands of tokens become hundreds.
- Send noisy work to a subagent. Running tests or reading documentation produces pages of output. A subagent can do that work in its own context and return only a summary to the main conversation.
- Be specific. “Improve this codebase” makes the model read everything. “Add input validation to the login function” lets it read one file.
7. Batch what isn’t urgent
Work that doesn’t need an answer in seconds, such as classifying a month of support tickets or summarising a document archive overnight, can go through a batch service. Both Anthropic and OpenAI charge half price for batch requests.
None of these techniques is exotic. Together they routinely cut the tokens a piece of work needs by large margins, and the work often gets better, because the model sees what matters and little else. That’s the leaderboard worth winning: the same result for less.
What to measure instead
Keep usage data, but pair every activity metric with the outcome it’s supposed to drive. The outcome is what you report. The activity is how you diagnose it.
| Activity metric | What it actually tells you | The outcome to measure instead |
|---|---|---|
| Tokens used | How much AI was consumed, and roughly what it cost | Cost per result: total AI cost divided by invoices processed, tickets closed or documents produced |
| Licences issued or active users | Who has access and who logged in | Hours released, or more work handled by the same team, in the processes AI was meant to change |
| Prompts or sessions per person | How often people reach for the tool | Cycle time: how long the process takes end to end, before and after |
| AI-written code or content | How much was produced | How much reached production or customers, and how much needed rework |
| Agents or workflows deployed | How much has been built | Which ones beat their baseline within 90 days of going live, and which should be stopped |
| Pilots launched | How much experimenting is happening | How many reached production with an owner and a measure |
The business result is the one that shows up somewhere a CFO already looks: cost, revenue, margin, working capital, risk or customer experience. Cost per result is where the two halves of this article meet. Optimisation lowers the cost, the work raises the result, and the ratio tells you whether AI is paying.
My own example is translation at scale. At a global consumer brand I moved translation and localisation onto an AI-first platform across 14 languages, with people reviewing rather than translating from scratch. The result was a lower translation bill: around US$1M a year. How many tokens the platform used was part of the running cost, not the result.
Where usage data does help
Usage data isn’t useless. It’s a diagnostic, not a scoreboard.
- Zero is a signal. If a team you’ve equipped never touches the tool, the training, the use case or the tool is wrong. Find out which.
- Spikes catch problems. Shopify, according to The Pragmatic Engineer, renamed its leaderboard a “usage dashboard” and added limits that cut off access when someone’s spend jumps. Those limits caught runaway agents and some bugs.
- Big users are worth a conversation. Ask what the heaviest users are doing. Sometimes it’s valuable work worth spreading across the business. Sometimes it’s an agent in a loop, or a session that was never cleared.
- Cost belongs in the business case. Token spend is part of what an AI workflow costs to run. Put it in the cost per result, next to licences and the time people spend overseeing it.
Questions to ask before your next AI report reaches the board
- What business result is each AI use supposed to change, and what was it before we started?
- What does it cost to run in total, including tokens, licences, integration and oversight?
- What’s the cost per result, and is it falling?
- Who owns each one, and who decides when to stop it?
- Which uses haven’t beaten their baseline, and what are we doing about them?
If the answers are mostly usage figures, the business has an adoption program, not an AI program. The four questions I ask of any AI initiative before it’s funded are in AI in the mid-market. For the measures on a single workflow, see agentic AI workflows for mid-market businesses.
The bottom line
Tokenmaxxing is what happens when the easiest number to count becomes the goal. Tokens are a cost line. Treat them like any other: worth watching, worth reducing, and never the point.
The point is the result: a process that’s faster, cheaper or better, measured against where it started, delivered with as few tokens as the work needs. If your AI reporting can’t show that, it’s the reporting that needs fixing first. That’s the work I do as a fractional Chief AI Officer: choosing the uses that pay, setting the baseline and the measure, building them efficiently and stopping the ones that don’t.
If you’d like a second view on what your AI spend is producing, book a 30-minute call.
Common questions
What does tokenmaxxing mean?
Tokenmaxxing is using as many AI tokens as possible to look like a heavy AI user, usually to climb an internal usage leaderboard or meet a spending target. A token is the unit AI models are billed in, roughly three quarters of a word. Using more of them costs more, but it doesn't mean more work got done.
Is token usage a good measure of AI adoption?
It's a reasonable signal at the very start. If nobody is using the tools, adoption has failed. Beyond that, token counts mostly measure spend and how verbose people's prompts are. Once usage is a target, people inflate it, and it stops telling you anything.
How do you reduce AI token costs without losing quality?
Keep the context small and relevant. Clear or compact long conversations, move standing instructions into skills that load only when needed, put fixed content first so it's cached, match the model and reasoning effort to the task, and batch work that isn't urgent. Claude, ChatGPT, Codex and Gemini all support some or all of these.
How should a mid-market business measure the return on AI?
Measure the process, not the tool. Take a baseline before you start, such as hours per task, cost per transaction, cycle time or error rate, then compare the same measure 90 days after going live. Divide the total AI cost, including tokens, licences and the people overseeing it, by the outcome to get a cost per result.
Should we set targets for how much staff use AI?
Set targets for results, not usage. A target like "every team uses AI daily" invites busywork and runs up bills. A target like "cut invoice processing time by half by March" gives people a reason to use AI where it helps and to skip it where it doesn't.
What should an AI update to the board include?
For each AI use in production, the business result against its baseline, the full running cost, the cost per result, who owns it and any incidents or risks. Usage figures belong in an appendix, if at all. A board report that leads with tokens, seats or active users is reporting activity.
