Tokenmaxxing: AI Tokens Are Becoming the New Productivity Metric (And Why That's Half-Right)

A small pixel-art display on a desk. USB-powered. Hooked into the developer's AI usage API. You watch tokens accumulate in real time, and you watch a tiny crab get more agitated as the number climbs.

That is the whole product. No leaderboard. No team dashboard. No manager view. It is for you.

So why did 800 people star it in a week? Because for the first time, "I used AI to write this" is something developers want to show off, not hide.

Five years ago that same sentence was a confession. Today it is a flex. That shift is the actual story, and the gadget is just the artifact.

Devs are calling it "tokenmaxxing." The more AI you are delegating to, the more deeply you have integrated it into your workflow, the higher your number goes.

This makes sense if you have actually built with AI for production. You do not burn through tokens by asking a chatbot to fix a typo. You burn through them by:

• Running long-context agents over real codebases
• Automating workflows that used to take days
• Letting AI iterate on hard problems in the background while you work on something else
• Building systems that call models on every user request

A high token number is not "I chatted a lot." A high token number is "I figured out how to make the tool do real work."

That is why the metric resonates. It is a proxy for AI fluency. And in 2026, AI fluency is the most valuable skill on the market.

For decades we measured knowledge work with proxies. All of them were flawed, all of them were gamed, all of them eventually became meaningless.

Era	Proxy	What It Actually Measured
1990s	Lines of code	Verbosity
2000s	Tickets closed	Ticket farming
2010s	Hours logged	Endurance
2010s	Pull requests	PR splitting
2020s	Emails sent	Email production
2026	Tokens burned	...?

Tokens are the new candidate, and they have one genuine advantage the others did not: they are hard to fake.

You can copy-paste a thousand lines of code from somewhere. You can pad ticket counts. You cannot fake 50M tokens of agent work, because the tokens get spent in real inference. There is a credit card behind every one of them. The unit of measurement is, literally, money.

When a metric costs money to game, it is a slightly better metric.

The second a manager starts tracking it, it becomes a vanity metric.

The whole point of using AI well is to produce more value per token, not more tokens per developer. The best AI engineers I know are obsessive about token efficiency. They cache aggressively. They use the smallest model that can do the job. They reach for Haiku where they can and only escalate to Opus when the task actually needs it.

If you reward "tokens burned," you will get exactly what you measured. People will run sloppy prompts. People will let agents loop. People will route everything to the most expensive model because the metric goes up.

This is Goodhart's Law in pixel art form. When a measure becomes a target, it ceases to be a good measure.

The Clawdmeter is fine as a personal toy. It becomes dangerous the day someone screenshots their team's leaderboard and pastes it in #engineering-stats.

I have already seen one VP of Engineering, in a public Slack I will not name, ask his team to "share their weekly token totals so we can see who is leveraging AI." That meeting is going to age badly.

If tokens are the wrong metric, what is the right one?

I do not think there is one number. But there are three signals worth watching.

The output side. What shipped that would not have shipped without AI? What got built in a day that used to take a week? Value-per-token is the only thing that ultimately matters. Everything else is a proxy for it.

The skill side. Can the person prompt clearly? Do they know which model to reach for? Do they catch when the AI is wrong? Do they have judgment about when to delegate and when to write it themselves? An engineer who knows when not to use AI is more valuable than one who reaches for it on every keystroke.

The systems side. Have they built tooling around the AI? Custom agents, MCP servers, skills, slash commands, evals? The people getting the most out of AI are not the ones with the highest token counts. They are the ones who have built scaffolding so the tokens they do spend get spent well. (For what that scaffolding looks like in practice, see my post on Claude skills.)

None of these fit on a pixel-art crab. That is part of the problem.

If you run an engineering org, the question I would push back on is "how do we track AI usage?"

The better question is: "What does good AI usage actually look like in our org, and how would we even know?"

This is harder. It requires you to:

1. Pick three to five concrete outcomes you actually care about (features shipped, bugs caught, cycle time, code quality on AI-assisted PRs)
2. Look at the engineers who are already getting those outcomes
3. Ask what they are doing differently
4. Make that visible to the team without turning it into a leaderboard

You cannot skip step 3. The temptation is going to be to install something that surfaces token counts and call it done. Resist that. Token counts are inputs. You want to be measuring outputs.

If you are not willing to do the work to figure out what good looks like, do not measure it at all. A bad metric is worse than no metric, because a bad metric drives behavior in the wrong direction with the full force of management attention behind it.

The metric is coming whether you choose it or not. Choose well.