← Field Notes
Strategy11 August 2026·7 min read·Chris Ma

THE
WRONG
SCOREBOARD.

Token counts measure activity. They say nothing about whether the activity was worth anything.

AI ProductivityTokenmaxxingValuemaxxingClaude Code

In April 2026, The Information reported that a Meta employee had built an internal leaderboard, nicknamed “Claudeonomics,” ranking colleagues by tokens processed and generated. Top performers earned digital badges with titles like “Cache Wizard” and “Model Connoisseur.” The highest-ranked individual averaged 281 billion tokens. The leaderboard was taken down two days after the report.

That’s the whole story. Everything else is commentary on why it was always going to end that way, and what the people who built similar dashboards at Amazon, Atlassian, and a dozen other companies should have tracked instead.

Key Takeaways
  • Meta’s internal “Claudeonomics” leaderboard peaked at 281 billion tokens for the highest-ranked individual and was pulled two days after The Information reported on it.
  • Tokenmaxxing measures consumption, not output. An internal audit of roughly 100,000 prompt logs found approximately 65% of queries were simple tasks that did not need expensive frontier-tier tokens.
  • Once a metric appears on a leaderboard, behaviour warps around it: padding prompts, redundant parallel agents, and routing every task through frontier models regardless of complexity.
  • The corrective metric is tasks completed per dollar. It catches when the same outcome could have been reached with a cheaper model or a shorter, more precise prompt.
01

WHY THE METRIC FAILED

#

The origin of tokenmaxxing is rational. Organisations wanted a visible signal that teams were actually adopting AI tools — a genuine, reasonable goal. Token counts happened to be one of the only AI inputs every provider meters cleanly, so it was the easiest number to put on a dashboard. Easy to measure is not the same thing as a good proxy for the thing you actually care about, and that gap is the entire problem.

The core issue: tokenmaxxing measures consumption, not output. Token-heavy workflows — agentic coding, multi-step reasoning — genuinely do consume large volumes of tokens when they deliver real value. But identical token volumes can come from an agent running in circles producing nothing useful. The number alone cannot distinguish the two cases.

Once the metric became visible on a leaderboard, behaviour predictably warped around it: engineers padding prompts, running redundant parallel agents, routing everything through frontier-tier models regardless of task complexity. One internal audit of roughly 100,000 prompt logs found that approximately 65% of queries were simple definitional questions or minor refactors — work that didn’t need expensive tokens, but got them anyway because the default was always the most powerful endpoint available.

CLAUDEONOMICS — WEEKLY TOKEN LEADERBOARDtaken down 48 hrs later#USERTOKENSBADGEEST. COST01jkrueger281BCache Wizard$4,200/mo02priya_s194BModel Connoisseur$2,900/mo03dan.t147BContext Champion$2,200/mo04emilyq98BPrompt Architect$1,470/mo05r.okonkwo61BToken Enthusiast$915/moTOKEN VOLUME DOES NOT DISTINGUISH WORK FROM NOISE

Claudeonomics: the leaderboard that lasted 48 hours

The Goodhart problem

When a measure becomes a target, it ceases to be a good measure. Goodhart’s Law has been applied to everything from school test scores to hospital wait times. AI token leaderboards were always going to produce the same outcome: behaviour optimised for the number, not for the work the number was supposed to represent.

02

THE CORRECTIVE: VALUEMAXXING

#

The counter-practice gaining traction is valuemaxxing: optimising for outcomes per dollar spent, rather than volume for its own sake. The signal distinction is straightforward. Genuine skill shows up as tokens per good outcome going down, not up. A tighter, better-scoped context package consistently outperforms four parallel agents running against a vague prompt, using a fraction of the tokens to reach an acceptable result.

What to actually track:

VANITY METRICSVALUE METRICSTotal tokens usedTasks completed & shippedDaily active sessionsIterations to acceptable outputModel tier selectedCost per shipped taskPrompts sentSkill delta month-over-monthBackground tasks runSpend matched to task complexityactivityoutcomeMEASURE WHAT MOVES THE WORK FORWARD, NOT WHAT MOVES THE METER

Left column: what's on the dashboard. Right column: what should be.

Total tokens used

Activity level only — tells you something happened, nothing about whether it was worth anything.

Tasks completed & shipped

The closest single-number proxy to actual productivity. Not granular, but directionally honest.

Iterations to acceptable output

A measure of prompt and context quality. Falling iteration count is the real skill signal.

Cost per completed task

Total spend across all calls until the work is done and accepted. The number that should inform budgeting.

Model tier used vs. task complexity

Whether spend is matched to actual need. 65% of queries don't require frontier-tier models.

03

PRACTICAL CALIBRATION

#

Most of this comes down to one discipline: match the tool to the task before you spend, not after. That sounds obvious, but the default in most AI-enabled environments is to route everything to the most capable endpoint available. The cost of that default adds up.

QUERYarrivesCLASSIFIERsub-40ms routingcomplexity scoreSIMPLEHaiku / fast model65%definitional Q&A, small refactors, formattingSTANDARDSonnet-tier30%multi-step reasoning, code generationFRONTIEROpus / heavy model5%architecture decisions, novel problems65% OF QUERIES ARE SIMPLE — DEFAULT-EVERYTHING-TO-FRONTIER IS THE WASTE

Efficient allocation vs. defaulting everything to frontier tier

SCOPE BEFORE YOU SPEND.

Write the actual goal and “done” condition before starting a session. A vague prompt invites a vague, token-heavy back-and-forth to converge on what you actually meant. For Claude Code specifically: extended thinking is billed as output tokens at a real premium. Cap it or drop the effort tier for tasks that don’t require deep reasoning — routine scripting and minor refactors don’t need the same reasoning budget as a genuine multi-file architecture decision.

MATCH MODEL TO TASK, NOT HABIT.

Default to lighter, faster models for simple, well-defined work — definitional questions, small refactors, formatting. Reserve heavier models for tasks with real ambiguity or multi-step reasoning. The 65% figure above — simple queries hitting frontier endpoints by default — is the exact waste this avoids.

CHECKPOINT INSTEAD OF SPRAWL.

Long, meandering sessions accumulate context that isn’t all pulling weight. Checkpoint progress to a doc and start a fresh, compressed session rather than letting one conversation run indefinitely. The same principle applies to your own working sessions, not just autonomous agents: a clean context is a cheaper context.

MEASURE YOUR OWN SIGNAL.

Pick one recurring task type and track iterations and spend this month versus last. Falling iteration count at stable or falling cost is the actual win condition. Rising raw token usage is not.

04

THE TREND LINE THAT ACTUALLY MATTERS

#

There’s a legitimate version of high token consumption: the learning phase. When you’re learning how to engineer a new workflow type — figuring out the right context packaging, the right model tier, the right loop structure — iteration is expensive, and that cost is worth paying. It’s training spend. Expected, worth budgeting for, worth timeboxing.

What isn’t acceptable is treating training-mode burn rates as steady-state. If you’re still consuming the same volume six weeks into a repeatable task, that’s a signal the workflow hasn’t been engineered yet — it’s still being improvised.

TRAINING SPENDOUTCOME MODEtoken burn rateoutcomes per dollarSKILL SHOWS UP AS TOKENS-PER-GOOD-OUTCOME GOING DOWN, NOT UP

Training spend followed by outcome mode. The payoff should be visible.

The real skill signal

The transition from training spend to steady-state should be visible on a graph. If cost per task is still climbing six weeks into a repeatable workflow, the workflow hasn’t been engineered yet. Track cost per completed task week over week. That downward slope is what mastery looks like, not a leaderboard position.

Quick reference

SignalWhat it actually tells you
Total tokens used

Activity level only — no outcome information

Tasks completed per session

Closer to real productivity

Iterations to acceptable output

Skill and prompt / context quality

Cost per completed task

The number that should actually inform budgeting

Model tier vs. task complexity

Whether spend is matched to actual need

Recommended Reading

Cal Newport · Grand Central Publishing

The intellectual case for protecting distraction-free concentration — the argument that depth, not volume, is the unit of knowledge work productivity.

Daniel Kahneman · Farrar, Straus and Giroux

System 1 and System 2 thinking — the cognitive science foundation for understanding when to offload to AI versus when human judgment is non-negotiable.

ArticleMeasuring Developer Productivity

McKinsey & Company · mckinsey.com

A rigorous look at what productivity metrics actually capture versus what they miss — useful calibration for anyone tempted to measure AI leverage by tokens per hour.

Continue the conversation

If this changed how you think about it — or you think I'm wrong — I want to know.

Corrections, disagreements, and applications all welcome. Replies go directly to Chris.

Get in touch →
Field Notes · PodcastHost + Expert · Gemini TTS

THE WRONG SCOREBOARD

~6-8 min

1× · Two speakers · tap to play