Tokenmaxxing

What is tokenmaxxing?

Tokenmaxxing is treating the number of AI tokens somebody burns through as a measure of how productive they are. High token count, good employee. Low token count, somebody who has not got on board yet.

The word borrows the "-maxxing" suffix from online slang, where it means pushing one variable as far as it will go and letting the rest sort itself out. Applied to AI it carries two meanings that get used interchangeably, and that is most of the confusion around it. One is a boast: I used more of the tool than you did. The other is closer to engineering: get the most work out of every token you pay for. Same word, opposite behaviour.

Nobody can point to who said it first. It circulated in developer and AI communities through the early months of 2026, half joke and half status claim, and it was in the technology press by April of that year. If you see it credited to a particular founder or investor, treat that as a guess. What is documented is how fast it turned from a joke into a management practice.

The Meta leaderboard, and the argument it started

In April 2026 an employee at Meta built an internal dashboard called Claudeonomics that ranked colleagues by token consumption and handed out labels such as Token Legend and Cache Wizard to the top 250. Fortune reported staff had run through more than 60 trillion tokens across thirty days, and that neither Mark Zuckerberg nor Andrew Bosworth appeared in that top 250. Business Insider reported the dashboard came down two days after the numbers leaked outside the company. Meta said the employee took it down at their own discretion.

The argument that followed is more useful than the dashboard was. Sonya Huang, a partner at Sequoia Capital, told the Wall Street Journal that we all should be tokenmaxxing. Cristina Cordova, chief operating officer at Linear, put the other side in one line: ranking engineers by token spend is like ranking a marketing team by who spent the most money, and a high burn rate is not a high success rate. Jon Chu of Khosla Ventures said people had been building bots that run in a loop burning tokens as fast as they can, because of the policy.

Gergely Orosz, who writes The Pragmatic Engineer, made the comparison that lands for anyone who has been in software a while. This is lines of code with a new unit. Counting lines was abandoned as a productivity measure because it rewarded volume, and volume is not the thing anyone was buying.

Why a manager reaches for the token count

Start with the honest reason, because it is not stupidity. The token count is the one number the usage dashboard hands you for free. It needs no definition workshop, no instrumentation project and no argument with the team about what counts. It arrives daily, it is per person, and it goes up when people use the tool. Adoption is usually what the manager was asked to deliver, so a number that tracks adoption feels like a number that tracks the goal.

Read what the dashboards actually promise and the picture gets narrower. Anthropic's Claude Code analytics for Teams and Enterprise includes a leaderboard of top contributors ranked by usage, next to lines of code accepted, suggestion accept rate, daily active users and sessions. The vendor ships the leaderboard. Anthropic is also straight about what one of those numbers leaves out: lines of code accepted excludes rejected suggestions and does not track subsequent deletions. A line accepted at eleven and deleted at half past eleven still counts.

Microsoft's Copilot Chat usage report in the Microsoft 365 admin centre is built the same way. An active user there is a user who submitted at least one prompt during the period. The per-user table gives you prompts submitted, active days and last activity date. Each of those is a precise definition of exactly what it says, and none of them is about work getting done.

Your usage dashboard tells you people opened the tool. It does not tell you anything came of it.

What a high token count is actually made of

A token bill is not a record of thinking. It is a record of text that moved. Four things move most of it, and none of them is skill.

• Context resent on every step. An agent working through a task sends the whole conversation again on each turn. A 100,000 token context is billed at step 2 and billed again at step 40. The length of the run drives the bill more than the difficulty of the problem does.

• Retries. A failing test that the agent tries thirty times bills thirty times. Nothing errors out, so nothing stops it.

• Bad scoping. Somebody pastes an entire repository into a prompt so the model has everything. That one decision multiplies every step after it.

• A loop nobody caught. The agent cannot find a document, so it searches, reads, rephrases and reads again. Every call is a fraction of a cent and the run is the accident.

Then there is the detail that breaks the leaderboard outright. Prompt caching lets you pay a tenth of the base input price for content the model has already seen, and Anthropic prices a cache hit at 0.1x the base input rate on most of its models. Cached tokens are still tokens: Anthropic's usage reporting counts uncached input, cached input, cache creation and output as separate figures, and they all add up to your consumption. So switching caching on takes about ninety percent off the bill and moves your rank not at all. On identical work, the colleague who never configured caching sits above the colleague who did.

So the person at the top of a token leaderboard is as likely to be the one with the worst workflow as the best one, and the number cannot tell you which of the two you are looking at.

Two colleagues, ten times the tokens

A Flemish software company of fourteen people gives everybody an AI coding assistant on Claude Sonnet 5, listed in September 2026 at 2 dollars per million input tokens and 10 per million output. Two developers, one month, twenty working days.

Bram sits at the top of the usage list. He runs about 2,000 agent steps in the month. He opens each session by pasting the repository in so the model has the full picture, which puts roughly 190,000 tokens of context on every step. That is 380 million input tokens, about 760 dollars. His output tokens come to roughly 1.2 million, about 12 dollars. He merged 11 changes. Three came back as customer-reported bugs inside four weeks, and reviewers spent around 40 minutes per change, because the diffs were large and touched files that did not need touching.

Lies sits near the bottom of the list. She also runs about 2,000 steps. She writes three lines of spec first, points the agent at the three files that matter, and stops it when it wanders. Her context runs around 19,000 tokens a step, so 38 million input tokens, about 76 dollars, plus the same 12 dollars of output. She merged 13 changes. One came back. Reviews took about 15 minutes each.

On the dashboard Bram is the power user and Lies looks disengaged. In the month, Bram cost 772 dollars in tokens and about 7 hours of somebody else's review time, and shipped 11 changes with 3 defects. Lies cost 88 dollars and about 3 hours of review, and shipped 13 changes with 1 defect. The token count ranked the two of them correctly on exactly one thing, which is how much text they sent.

Notice where the money went as well. Almost none of it is what the model wrote: 12 dollars of Bram's 772, and 12 of Lies's 88. Everything else is context going in. A dashboard that reports tokens is mostly reporting how much history got resent, and resending history is a property of the workflow, not of how hard somebody worked.

What happens when the count becomes a target

Once people know they are ranked on it, the count stops describing anything. The automation rate entry sets out why any measure collapses once people are judged on it, so take that as read. The shape it takes with AI usage is specific enough to be worth naming on its own.

People generate. Asked to show usage, the cheapest way to comply is to send the model more work than the job needs: longer prompts, wider context, a second and third draft nobody asked for, a summary of the summary. The bots in a loop that Jon Chu described are the automated version of the same instinct, and they are quicker to build than they are to explain away.

What comes out is the low-value, plausible-looking output that the AI slop and workslop entry describes, and the cost of it does not land on the person who generated it. It lands on whoever has to read it. A colleague who spends forty minutes reviewing a change that took two minutes to produce has been handed work by a metric, and that transfer is invisible on every dashboard involved.

A second cost shows up later. Gergely Orosz has warned that AI usage figures could end up feeding decisions about who stays, and once that idea is in the building people optimise for the figure whatever they privately think of it. At that point you are paying for the tokens and getting defensive behaviour on top, which is the ground the AI fatigue and cognitive debt entry describes.

The rule holds in the other direction too. A team told to bring token spend down will start doing the work by hand and not logging it, which cuts the number and none of the cost.

What to put next to it

Measure the work, not the consumption. Cases closed per person per week, cycle time from arrival to done, rework or reversal rate, and cost per case with the loaded staff time in it. Those are the numbers you had before AI arrived, they compare against last quarter, and they move only when something real happens. Put the token spend on the same page as a single line: cost. It belongs inside the cost per case, next to the software licences and the hours.

Tokens consumed versus work completed

Put the two side by side on one dimension: what each number tells a manager about the person.

Tokens consumed tells you how much text that person sent to a model. It rises with retries, with long context resent on every step, with a prompt that carried a whole repository, and with never having configured caching. It falls when somebody scopes a task well. It has no unit anyone outside the team recognises, and it cannot be compared with a colleague doing different work.

Work completed tells you what the business got. Tickets closed, changes shipped, invoices matched, days saved. It is denominated in something a customer would recognise, it is the same measure for the person who leans on AI all day and the person who barely touches it, and it does not reward volume.

The uncomfortable part is that the first is available this afternoon and the second takes a month of definition work. That is the only real advantage tokens have.

Where the token count does earn a look

Not per person. Per run. Token consumption is a good anomaly detector and a poor performance measure, and the difference is whether you watch the level or the change.

A nightly reconciliation job that cost 4 dollars every night for a month and cost 41 dollars last night is telling you something specific: a loop, a retry storm, a document it cannot find, or an input ten times the usual size. That is worth an alert and twenty minutes of somebody's morning. The same goes for a single session that runs three times longer than any session before it. Log per run the identifier, the user, the model, the token totals and the final cost, so the alert can say which job did it. Where that lands you is a spending control rather than a scoreboard, and the agent spend cap entry covers how to set one.

If your AI usage report is the only evidence you have that the investment is working, you do not have evidence yet. Go and ask the person who reviews the output whether their week got easier.