The End of Token Maxing

Last week, Meta's CTO Andrew Bosworth sent a memo to roughly 6,000 engineers. The company's employees had consumed 73.7 trillion tokens in approximately 30 days. The internal leaderboard tracking this was called "Claudeonomics."

The name is worth sitting with.

Claudeonomics

Someone built a leaderboard for token consumption. Someone named it after the AI system employees were burning through. For a period, the assumption held: high token usage signaled deep AI adoption, which signaled a more AI-native engineering org. It was a measure of something. Just not the right something.

Bosworth's memo corrected this directly: "Nobody should be using AI tools just for the sake of using them. All motion is not progress and token usage alone is not a measure of impact of any kind."

He's right. He's also describing a failure mode that was predictable from the incentive structure his company built.

The Pattern Is Wider

Meta is not alone. Amazon recently deprecated its own internal AI usage leaderboard, called KiroRank. A senior engineering VP sent staff an almost identical message: "Please don't use AI just for the sake of using AI." Uber burned through its entire 2026 AI budget in four months after rolling Claude Code to 5,000 engineers (I covered the mechanics of that case in Automated Productivity Theater) and has since capped individual tool spend at $1,500 per month.

Different companies, different tools, different cultures. The same organizational mistake.

The common thread: token consumption was used as a proxy for AI value. This was reasonable when the tools were new and exploration was the goal. It breaks when costs compound and nobody has thought carefully about whether the usage was producing proportional outcomes.

The Cost Structure Does Not Warn You

Most engineering costs scale with deliberate decisions. You hire engineers. You provision servers. You sign SaaS contracts. The spend is observable before it happens.

Token costs scale with behavior. When you hand 5,000 engineers an agentic coding tool and tell them the company is covering it, each individual session feels inconsequential. Seventy-three trillion tokens across thirty days is not.

The bill arrives after the behavior has already compounded. By the time anyone asks what the tokens were producing, the annual budget is gone. And the leaderboard, which was tracking usage intensity the whole time, has no answer for that question.

Token Minimizing as a Craft

The response from Meta, Uber, and Amazon is not "use AI less." It is something more precise: use the right model for the right task.

This is the discipline that leaderboards don't capture. A frontier model call for a docstring check costs the same shape as one for a hard architectural decision but delivers very different ROI. Production systems that route queries intelligently — caching stable, repetitive prompts and reserving frontier API calls for genuinely complex reasoning — typically cut blended costs by 80 percent or more without degrading output quality.

Meta's structural response makes this visible. The company is deploying a centralized AI Gateway for routing and budget controls, steering engineers toward MetaCode (its own coding assistant) partly to reduce dependence on expensive external APIs. The goal is infrastructure that matches model capability to task requirements, instead of defaulting everything to the most expensive option available.

That is what token minimizing looks like at scale. Not rationing: routing.

Token Counts Are Noise

The problem with token counts isn't just that they're gameable. Even used honestly, token consumption is a noisy proxy for value. A model call that generates a 300-line refactor isn't three times more valuable than one that generates a 100-line fix. A call that produces the right 10-line change to remove a race condition is worth more than fifty calls that produce plausible code nobody needed. Token count measures intensity of use. Intensity and impact are different things.

The correlation held early. When engineers first adopted AI tools, the highest-consuming users were genuinely the most engaged, and engagement tended to map to productivity. The leaderboard wasn't entirely wrong — it was measuring a leading indicator that stopped leading. As adoption spread from early explorers to the broader org, those engineers started optimizing for the leaderboard instead of for the work.

This is the standard trajectory for any metric that becomes a goal. Goodhart's law doesn't care whether the original metric was reasonable. It only requires that people notice it and start acting on it.

What Signal Looks Like

The obvious substitutes have the same structural problem. PRs merged, commits per sprint, tickets closed — these are output metrics, not outcome metrics. They measure how much was produced, not whether any of it moved anything downstream. Swapping token counts for PR counts doesn't fix the measurement problem. It relocates it.

The signals that actually matter for AI tooling are downstream and slower. Did cycle time — the gap between feature conception and production — improve after rolling out these tools? Is the bug escape rate changing? Are engineers spending less time on mechanical work and more on decisions that require judgment? Are the features being shipped actually moving retention or revenue?

These signals take weeks or quarters to read clearly. Token counts update in real time. That's a large part of why organizations default to them: they're legible, fast, and feel controllable. The answer isn't to make the slower signals faster. It's to be honest that real value from AI tooling shows up on a lag, and to resist filling that lag with noise.

The organizations managing this well establish a small number of outcome targets before rolling out new tools, measure baseline, then return to the data at 60 or 90 days and ask directly: did the needle move? If it did, you have evidence. If it didn't, you have an expensive answer to a question you should have asked sooner. Either way, you have something Claudeonomics never gave you: information.

What the Reckoning Gets Right

It would be easy to read Bosworth's memo as a retreat. It isn't. The companies running into these cost walls are the ones that adopted AI earliest and most aggressively. The reckoning is a symptom of scale.

What is ending is the "more is always better" heuristic that worked when usage was exploratory and costs were rounding errors. What is beginning is the harder work: defining what value looks like, measuring whether the AI spend is producing it, and building systems that route the right task to the right model at the right cost.

The companies that will get this right aren't the ones that used AI the most. They're the ones that figured out what it was actually for.

Token counts don't answer that question. Shipping does.