Why Yield Beats Tokenmaxxing

There's a trap that catches almost everyone who starts tracking their AI usage. You see the token counter climb — 500K, 1M, 2M — and it feels like productivity. More tokens means more work, right? Wrong. More tokens means more spending. Whether that spending produced anything depends entirely on the architecture of your cascade, not the volume.

The practice of maximizing raw token count as a proxy for productivity has a name: tokenmaxxing. And the metric that exposes it is yield (Υ). This post explains why tokenmaxxing misleads, why yield beats it, and how to stop doing it.

What is tokenmaxxing

Tokenmaxxing is the AI-era equivalent of measuring a developer by lines of code. It treats token count as a productivity signal: the more tokens you consume, the more “work” you must be doing. The logic is intuitive and wrong, for the same reason LOC was wrong — it measures the wrong unit.

An operator who sends a million tokens with no cache reuse and little output is not productive. They're burning. They're re-explaining context the model already has, pasting files it already read, and starting every session from scratch. The token counter says “1M” and looks impressive. The cascade says nothing is compounding.

Why yield beats token count

Yield (Υ) measures the architecture of your cascade, not the volume. The formula — (cache_read × output) / input² — rewards exactly the three behaviors that define a skilled operator:

• Cache reuse — cache_read is multiplied. Operators who build on prior turns score higher.
• Output production — output is multiplied. Operators who extract real work score higher.
• Input economy — input is squared in the denominator. Operators who keep fresh input lean score higher; operators who flood the model are penalized hard.

Token count rewards none of these. It only goes up. An operator who tokenmaxxes — high input, low cache reuse, low output — sees their token count climb and their yield crater. The two metrics diverge exactly where it matters: token count can't tell burning from building; yield can.

The signal yield captures that token count can't

Yield captures something token count structurally cannot: whether your signal is compounding. A compounding cascade is one where each turn builds on the last — cached context accumulates, input stays lean, and output flows. A burning cascade is one where each turn starts over — fresh input floods in, cache never builds, and output is thin.

Two operators can have identical token counts and opposite cascades. Yield tells them apart because it measures the shape of the flow, not the size. That's why it's the headline metric on the leaderboard and the number you get at /score.

How to stop tokenmaxxing

The fix is structural, not motivational. You don't stop tokenmaxxing by “trying to be more efficient” — you stop it by changing the architecture of your cascade. Three concrete moves:

The operators at the top of the leaderboard didn't get there by burning more tokens. They got there by burning fewer — and compounding the rest. Yield is the number that proves it.