Optimize Claude Code token usage: every lever this site has measured, ranked

Most "optimize Claude Code token usage" lists rank ten tips by gut feeling, with no real before-and-after behind any of them. This site has already measured or estimated nine of the real levers on its own session data - pruning MCP servers, filtering hooks, /clear vs /compact, subagent pinning, model stability, effort, tool search, CLAUDE.md size, and cache TTL - and the honest ranking looks nothing like the generic lists: five move real money, one is a real but lossy tradeoff, and three barely move your bill at all.

Why generic "save tokens" checklists can't tell you which tip is worth your time

Search "optimize Claude Code token usage" today and page one is Anthropic's own cost-management docs (official, but generic - no numbers, no ranking), a Reddit thread of anecdotes, and four or five "10 tips" listicles on Medium, dev.to, and gitconnected that repeat the same advice - clear context often, watch your CLAUDE.md, use subagents - without ever running the before-and-after. None of them can tell you whether trimming your CLAUDE.md is worth ten minutes or whether it's a rounding error next to five other things you haven't looked at, because none of them measured either one.

Guide by guide, over the last month, this site pulled real session transcripts for MCP servers and hooks, ran the /compact vs /clear math on 38 real sessions, modeled model switching on 904, audited subagent pinning across 766 subagent transcripts, and broke down output and thinking tokens across 1,037 sessions. Nine separate investigations, nine separate pages, each with its own measured-vs-estimated label. What none of them did until now is sit next to each other so you can see which one is worth your first hour.

Every lever this site has measured, ranked by real savings

The three tags mean exactly what they say, not a vibe: BIG levers changed a real percentage of spend or a six-figure token count on real sessions. SITUATIONAL means the number is real but comes with a tradeoff serious enough that it isn't a default "yes." BARELY MOVES means the effect is real but small enough that chasing it wastes more time than it saves.

| Lever | What it changes | Size | | --- | --- | --- | | Prune a dead MCP server | 176 tokens/turn per idle server, gone | Small alone, compounds with more servers | | Filter hook output | ~4,470 → ~275 tokens per 10 runs of one hook | Scales with matcher breadth | | /clear over cold /compact | Up to 226,867 tokens not reprocessed | Largest single number on this list | | Pin mechanical subagents | 2.4-2.7% of spend (safe), 9-11% (aggressive) | Compounding, not one-time | | Stop flipping models | Avoids a modeled ~-122% loss | Prevents a self-inflicted cost, doesn't cut one |

The numbers aren't in the same units on purpose - a per-turn token count, a percent of total spend, a worst-case session total - because forcing them onto one chart to make a prettier bar graph would be the same dishonesty as the "50% savings" headlines this site's own build notes explicitly warn against. Read each one in the unit its own guide measured it in.

The levers that sound big but barely move your bill

All three of these get real attention in forum threads and "optimization" listicles, and all three turn out to be smaller than the anxiety around them once someone actually measures. That doesn't mean ignore them entirely - a CLAUDE.md over 200 lines still hurts instruction-following even though it doesn't hurt your wallet, per Anthropic's own memory docs - it means don't spend your first hour here. The CLAUDE.md size breakdown, what actually changed with cache TTL, and whether disabling tool search helps each go deeper if one of these is genuinely your bottleneck.

The levers that move real money, and why

Five levers land in the BIG tag above, and they share a pattern worth naming: every one of them is either a standing cost you can just turn off, or a mistake you can just stop making - not a tradeoff you have to accept lower quality to get.

MCP pruning and hook filtering are both standing-cost problems. An idle MCP server adds its name and instructions to every turn whether it's called or not - 176 measured tokens per turn on this project's own setup, for a server doing nothing. A hook that dumps raw command output into additionalContext instead of filtering it first pays the same tax on every matched call - ten runs of an unfiltered hook cost roughly 4,470 tokens against about 275 for the same hook filtered down to just the failure. Neither one costs you anything to fix; both just sat unnoticed until someone measured them.

/clear vs /compact is a timing mistake, not a tradeoff. /clear is always $0 - it doesn't summarize anything, so nothing gets sent. /compact is a real request that reads your history at the cache-read rate while the cache is warm, but reprocesses the entire thing as fresh, full-price input the moment your cache has gone cold - on the largest of 38 real sessions this site measured, that's 226,867 tokens reprocessed for a summary a fresh /clear plus one sentence of recap would have replaced for a rounding error.

Subagent pinning and staying off a per-turn model flip are the two levers that actually compound instead of paying off once. Reclassifying mechanical subagents - research, docs, code review - off Opus and onto Sonnet or Haiku recovers 2.4-2.7% of total spend on the safe cases alone, more on a broader reclassification. And the tempting move in the opposite direction - flipping your main thread between Opus and Sonnet turn by turn to chase Sonnet's 0.4x rate - is modeled at roughly -122% once the cache-miss penalty is counted: Claude Code's prompt cache is model-specific, so a switch forces a full-price cache rebuild that eats more than the per-token gap ever saved.

Effort reduction sits in its own SITUATIONAL tag rather than BIG on purpose. Output tokens are only 0.7% of this project's total billed tokens but 15.9% of its dollar cost - a small share of tokens carrying an outsized share of the bill - and lowering effort on routine turns tracks to roughly 20-40% of output tokens, self-reported. It's real. It's also lossy: you're trading reasoning depth for the cut, which is exactly the kind of lever this site's own build notes say never to make default-aggressive on coding work.

What the official docs cover, and where they stop

Claude Code's own cost-management docs are the one page-one result worth reading - they correctly name context management, subagent delegation, and MCP server hygiene as the real levers, and they're the authoritative source for how caching and compaction work under the hood. What they don't do, and can't do from a generic docs page, is put a number on any of it. They'll tell you a hook can filter output before it reaches the model; they won't tell you that's the difference between 4,470 and 275 tokens. They'll tell you subagents can run cheaper models; they won't tell you 2.4-2.7% is the honest, defended range once you separate mechanical work from creative work. That gap between "here's the lever" and "here's what pulling it actually does" is what nine separate measurement passes on this site exist to close.

Finding which of these levers apply to your own setup

Five BIG levers is a to-do list, not a diagnosis - not every setup has a dead MCP server, a chatty hook, or an unpinned subagent doing mechanical work. Before spending an hour on any of them, five checks tell you which ones are yours:

Running all five by hand across claude mcp list, a hooks.json, and a week of /usage is exactly the setup audit the free UsageCut scan automates - point it at your local transcripts and config once, and it tells you which of these nine levers are actually costing you something, instead of you guessing from a generic list a second time.

When token optimization isn't the fix

Nothing here applies the same way on a flat-rate Pro or Max plan, where usage draws from a shared seat allowance rather than a per-token bill - the token count still shapes how fast you hit that plan's usage window, but the dollar math above doesn't touch what you pay directly. And if your sessions are short and your setup is already lean - a handful of MCP servers you actually use, no custom hooks, no custom subagents - there may genuinely be nothing here worth automating; running the checklist above and finding a clean setup is itself a useful answer, not a failure to optimize harder.

FAQ

• What's the single biggest Claude Code token-saving lever? On this site's own measurements, avoiding a cold /compact and pinning mechanical subagents off Opus are the two with the largest real numbers behind them - up to 226,867 tokens on one measured session, and 2.4-11% of total spend, respectively. Which one matters more depends on your own session length and subagent usage.
• Does trimming CLAUDE.md actually save meaningful tokens? Not in dollars - even a bloated 12,000-token file costs $0.05-0.27 across a full session at Sonnet 5 rates. The real reason to trim it is instruction adherence, which Anthropic's own docs confirm degrades on longer files, not the bill.
• Is disabling ENABLE_TOOL_SEARCH a real optimization? No - it removes the default deferral and loads every tool's full schema into every turn instead. It's the one setting on this list where the "optimization" is doing nothing at all.
• Should I switch between Opus and Sonnet mid-session to save money? Not on a per-turn basis. Claude Code's prompt cache is model-specific, so a switch forces a full-price cache rebuild that this site's own modeling puts at roughly -122% once counted - more expensive than staying on one model the whole session.
• How much do MCP servers and hooks actually cost if I never touch them? An idle MCP server adds about 176 tokens to every turn just by being configured, measured on this project's own transcripts. A hook costs nothing until its own output writes into a handful of specific fields - the number scales with how often it fires, not how it's written.
• Is there a tool that checks all of this for my own setup automatically? The free UsageCut scan parses your local transcripts and configured setup directly and reports which of these levers are actually present, rather than a generic list you'd otherwise check by hand one at a time.

None of the nine numbers above are guesses - they're what this site measured or estimated, guide by guide, and labeled honestly either way. The free scan is the fastest way to see which of them are sitting in your own setup right now, before you spend an hour chasing the ones that were never going to move your bill.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.