From Tokenmaxxing to Tokenminimizing

A year ago the smart move was to consume as much as your subscription would give you. Today the smart move is to consume less of it on things that were never helping you. That is the whole shift in one sentence, and it is bigger than a pricing change. It is a change in how developers relate to tokens.

I made the case in the problem with tokenmaxxing that the eye-watering multiples people were screenshotting, mine included, were never a hack. They were a subsidy, recorded from the losing side of the provider’s ledger, and the subsidy was being switched off. That post was about the cliff arriving. This one is about the ground on the other side of it, and what you do once you are standing there.

The mood already changed

Go back and read the tokenmaxxing threads from early 2026. The energy is playful. People are comparing implied bills like high scores, inventing tiers, daring each other to push harder. The unspoken assumption under all of it is that the number is free money, so more of it is more winning.

That mood is mostly gone now. The credit caps that landed in June, the metering that GitHub Copilot switched on, the frontier models quietly leaving flat plans two weeks after launch, they all did the same thing to the same people at roughly the same time. They put a ceiling in the room. When you can hit a wall partway through a cycle and watch autonomous runs stall, the multiple stops reading as a brag. It starts reading as a burn rate.

So the question people ask has flipped. It used to be “how hard can I push this plan before it pushes back?” Now it is quieter and more anxious: “I have a fixed amount of this, and something is eating it faster than I expected, so where is it actually going?” That is not a question tokenmaxxing was ever built to answer. Tokenmaxxing measured how much you consumed. It had nothing to say about whether the consumption was worth anything.

What tokenminimizing actually is

Tokenminimizing is the discipline of getting more out of the same plan by seeing where your quota goes and cutting the waste. It also means understanding how your harness approached the task. Nobody is telling you to use agents less or to babysit a token counter while you work.

• See where it goes. Before you can cut anything you need the composition of a session: how much of your window was fresh reasoning versus re-sent context, tool output, retries, and files your harness re-read on every turn.
• Cut the waste. Not all tokens are equal. Some bought you a working feature. Others re-sent the same 40KB of context forty times to accomplish nothing. Tokenminimizing is about finding the second kind and removing it, which almost never changes what you ship.
• Understand what the harness did. Agents, subagents, retries, and re-reads all burn your window in ways the transcript doesn’t show you. Knowing how your harness tried to solve the problem is how you stop it from solving the next one the same wasteful way.

The reason this matters more than a pricing tactic is that the waste was always there. The subsidy just paid for it, so nobody looked.

The enemy is the black box

Here is the piece of evidence I keep coming back to. A developer, frustrated that a Max plan was draining faster than the work seemed to justify, hand-parsed 30 days of their own Claude Code JSONL logs. They found that re-reads of a single CLAUDE.md file accounted for 99.93% of their quota. Not a bug in a corner. Almost the entire bill, spent re-ingesting the same instructions turn after turn, for a whole month, invisibly.

That gap between legible and visible is the entire problem. Your harness knows exactly what it re-read, how many subagents it spawned, which retries it burned. It simply doesn’t tell you, and under a subsidy you had no reason to ask. I dug into why so much of an agent bill is structurally this kind of dead weight in where your agent bill actually goes and in the broader shape of agent token economics. The short version: the majority of a typical bill is re-sent context doing no useful work. You cannot minimize what you cannot see, and the harness is built not to show you.

Why the answer is local and transparent

There is an obvious temptation here, and the market is already crowding into it: a black-box auto-optimizer that sits in your loop, silently rewrites your context, prunes your history, swaps your models, and promises to “save” you tokens. I understand the appeal. I also think it is exactly the wrong shape for this moment, and the backlash against these tools tells me a lot of developers agree.

The reason is trust. You just watched one black box (the harness) quietly burn your quota on re-reads you never authorized. Handing your context to a second black box, one that quietly rewrites it and hopes you don’t notice when it drops the file you actually needed, repeats the mistake at a deeper layer. When a tool acts inside your loop and gets it wrong, you inherit a broken session and no idea why. That is the opposite of what living inside a fixed window requires, which is visibility you can act on.

So the tool that fits tokenminimizing has a specific posture. It runs locally, on the logs you already have. It is read-only: it diagnoses, and you decide what to change. It reports in quota against your actual plan tier, not in dollars you were never going to be billed. And it is honest about what it can and can’t do yet.

That is the posture we built TokenJam with. It reads your real Claude Code usage on your machine and gives you two views. Session Story reconstructs how your harness actually tried to solve a task, turn by turn, including per-subagent attribution, so the effort your agents spent doesn’t vanish when they do. The context-composition view, tj context, ships today and answers the CLAUDE.md-re-read question directly: it breaks a window down into where the tokens went (re-sent context, tool output, retries, re-read files) so the 99.93% case shows up in seconds instead of a weekend of manual parsing. Both ship now and are free to try: install with pipx install tokenjam, then run tj context (also npx tokenjam or uvx --from tokenjam tj). Both stay on your machine, and neither one touches your session. The point is never that a tool acts for you. The point is that you finally get to see, and then you act.

The number was a brag. Now it is a budget.

Tokenmaxxing and tokenminimizing measure the same raw thing (your token consumption) and mean opposite things by it. One treated the number as a trophy because someone else was paying. The other treats it as a budget because now you are. The developers who adjust fastest are the ones who stop asking how big their multiple is and start asking how much of it was ever buying them anything. Most of the time, the honest answer is: less than you’d hope, and more of it is fixable than you’d think.

Common questions

Is tokenminimizing just a fancy way of saying use agents less?

No. It is about cutting the share of your quota that was never buying useful work (mostly re-sent context and re-read files) without changing what you actually build. In most sessions you can remove a large chunk of consumption and ship the exact same result, because that chunk was dead weight the whole time.

Why is my Claude Code plan draining so fast when I feel like I barely used it?

Usually because your harness is re-reading the same context on every turn. One developer parsed 30 days of logs and found re-reads of a single CLAUDE.md file were 99.93% of their quota. The work you did was a rounding error next to the context being silently re-ingested. It is invisible unless you look at the composition of the session directly.

How is this different from an auto-optimizer that trims my context for me?

An auto-optimizer acts inside your loop and rewrites your context without asking, so when it drops something you needed, you inherit a broken session with no explanation. TokenJam is read-only. It runs on your machine, shows you where the tokens went and how your harness approached the task, and leaves the decision to you. It diagnoses. You act.

Can I see where my tokens actually went, not just how many I used?

Session Story is shipped today and reconstructs how your harness tried to solve a task turn by turn, including per-subagent attribution. The context-composition view (tj context) ships today too and breaks a single window down into re-sent context, tool output, retries, and re-read files, so the 99.93% re-read case shows up in seconds instead of a weekend of manual parsing. Install with pipx install tokenjam, then run tj context (also npx tokenjam or uvx --from tokenjam tj). It is read-only and runs on your machine: it diagnoses, you act.

Do I have to send my code or logs anywhere to use this?

No. TokenJam reads the usage data already sitting in your local Claude Code logs and runs entirely on your machine. It is read-only and does not touch your session or upload your history. You can try it free with pipx install tokenjam or npx tokenjam.

Does tokenminimizing only matter now that the subsidy is ending?

The waste existed the whole time. The subsidy just paid for it, so nobody had a reason to look. What changed is that you now live inside a fixed window, so the same re-sent context that used to be free is now eating a budget you own. Cutting it was always possible. Now it is worth doing.