Reduce Claude Token Usage: 6 Fixes That Cut Real Costs

Nobody budgets for tokens. Then a heavy month lands, the invoice doubles, and suddenly everyone on the team is an expert on context windows. We’ve audited enough Claude Code setups to know the pattern: the bill is rarely driven by the work you asked for. It’s driven by everything that rides along with it.

This guide is the playbook we actually use. The fixes are ordered by impact, which means the boring structural ones come first and the fun one (model routing) comes last, because that’s where the money is. Prices below are API rates as of mid-2026: roughly $3 per million input tokens on Sonnet, $5 on Opus, $1 on Haiku, with output tokens costing about five times more. If you’re on a Pro or Max subscription you pay in rate limits instead of dollars, but every fix here buys you the same thing: more work per session before you hit the wall.

Where the tokens actually go

Every request Claude Code sends to the API carries your entire session so far, plus a fixed preamble: the system prompt, your CLAUDE.md, the description of every installed skill, and the full schema of every tool from every connected MCP server. That preamble is billed on every single turn, whether the turn uses any of it or not.

In a mature setup this adds up fast. The four burners we see most, in order:

The first is context re-reads. An agent that read your 2,000-line config file yesterday reads it again today, because sessions don’t remember anything. Multiply by every file it “checks just to be sure” and re-discovery becomes a line item.

The second is MCP tool schemas. Every server you’ve connected injects its tool definitions into every request. Not when the tool is used. Always. Five servers can mean 15,000 to 25,000 tokens of schemas sitting in front of your actual question, all day, every day.

The third is a bloated CLAUDE.md. A 3,000-line memory file is roughly 30,000 tokens taxed on every request in every session, forever. Most of those lines apply to maybe one session in ten.

The fourth is re-explaining. “Use conventional commits. Don’t touch the legacy folder. We prefer pnpm.” If you type your preferences into chat every morning, you’re paying to teach the same lesson daily, and the lesson then rides in the session history for every subsequent turn.

Prompt caching softens all of this. Repeated stable context is billed at about a tenth of the normal input price. But cache writes cost a premium, cached content still occupies your context window, and one changed byte near the top of the prompt invalidates everything after it. Caching is a discount, not a fix.

Measure before you optimize

Guessing at token waste is its own kind of waste. Ten minutes of measurement tells you which of the six fixes below actually matters for your setup.

Inside Claude Code, /cost shows what the current session has spent, and /context shows what’s occupying the window right now, broken down by system prompt, tools, memory files, and messages. That second one is the honest mirror: if tool schemas and CLAUDE.md take 40,000 tokens before you’ve typed anything, you’ve found your problem.

For history, the community tool ccusage reads the transcript files Claude Code already keeps on disk and gives you per-day, per-model breakdowns. API users can see the same in the Anthropic Console usage page, split by key. And if you want to know what a specific file costs, the API’s count_tokens endpoint gives an exact number; running your CLAUDE.md through it is a sobering thirty seconds.

Get a baseline week before changing anything. Every claim we make about our own numbers below came from doing exactly this, and the Token Budget Auditor skill exists to automate the whole exercise (more on it in fix 6).

Fix 1: replace repeated prompts with skills

This is the highest-leverage change for most people, and it works because of one design decision: progressive disclosure. A skill’s full instructions load only when the skill triggers. The only cost you pay every request is its trigger description, usually 30 to 60 tokens. If you’re new to the format, our explainer on Claude skills covers the mechanics.

Do the math on a prompt you paste daily. Say it’s 2,000 words, about 2,600 tokens: your code style rules, your review checklist, whatever you keep in a note and paste each morning. Once pasted, it sits in session history and gets re-sent on every turn. At 30 turns a session, that one block generates roughly 78,000 input tokens per session. Over 22 working days, about 1.7 million tokens a month. On Sonnet that’s around $5 uncached, call it $1 to $2 with decent cache hits.

As a skill, the same content costs its 50-token description per turn, about 33,000 tokens a month, plus the full 2,600-token body only in sessions where it actually fires. Call it a 95 to 98 percent reduction for that block.

Five dollars a month sounds like nothing until you remember two things. Nobody has one pasted prompt; the setups we audit have five to ten. And the dollar cost isn’t even the main damage: those tokens occupy context, which pushes long sessions into compaction earlier, which triggers re-reads, which cost more than the prompt did. Converting pasted prompts into skills is the single change with the best effort-to-savings ratio we know of.

Fix 2: put CLAUDE.md on a diet

CLAUDE.md is always-on context. That’s its entire value and its entire cost. The test for every line is simple: does this apply to most sessions in this project?

Belongs in CLAUDE.md: build and test commands, repository layout, the three non-obvious constraints that break things when violated, hard rules like “never commit directly to main.” This is typically 30 to 60 lines.

Does not belong: workflow instructions for tasks you do weekly (that’s a skill), style guides for occasional work like writing docs or migrations (skill), long explanations of architecture Claude can read from the code, and anything you copied in “so it’s there if needed.” If a section applies to fewer than half your sessions, it’s paying always-on rent for part-time work. Move it to a skill and it costs nothing until the day it’s relevant.

We keep seeing 2,000-plus-line CLAUDE.md files, and the owners are usually surprised twice: first by the token count (run it through count_tokens), then by the discovery that trimming it made Claude more obedient, not less. Instructions compete for attention. Forty sharp lines beat two thousand mushy ones.

Fix 3: prune MCP servers you don’t use

MCP servers are the quietest burner because the cost is invisible in daily use. Connecting a server means its tool schemas are serialized into every request. A typical server exposes 10 to 30 tools at a few hundred tokens of schema each; the big official servers are worse. When we measured our own setup, one popular server was adding around 20,000 tokens per request on its own, and we had used it twice that month.

Run claude mcp list and be ruthless. For each server, ask when you last actually used it. Our rule after doing this exercise on our own machines: two servers per project is plenty, and they should be scoped to the projects that need them rather than configured globally. A database server has no business taxing your blog-writing sessions.

Also reconsider whether each remaining server should be a server at all. A lot of MCP connections exist to wrap a CLI that Claude could just run through bash for zero standing cost. We wrote up the full decision framework in skills vs MCP, but the short version: MCP earns its schema tax when you need live authenticated access to an external system. For instructions, workflows, and anything file-based, a skill does the job without the per-request rent.

Pruning is also the rare fix that’s instant. No refactoring, no migration. Remove three idle servers and your very next request is 30,000 tokens lighter.

Fix 4: session habits that keep context small

Structure fixes the fixed costs. Habits fix the variable ones.

Start fresh sessions per task. One immortal session that wanders from a bug fix to a refactor to “also update the README” drags the entire bug-fix context into every README turn. History is re-sent on each request, so a long session’s turns get progressively more expensive. When the topic changes, /clear or a new session is almost always cheaper than continuing, and the output quality usually improves too, because stale context misleads more than it helps.

Use /compact at natural boundaries, not at the deadline. Claude Code auto-compacts when the window fills, but by then you’ve been paying full freight on a bloated history for an hour. Compacting right after a milestone (“tests pass, now the next feature”) shrinks history while you control what’s worth keeping. Compaction costs one summarization pass; carrying dead weight costs every turn.

Scope your asks. “Find where we validate emails and fix the regex” sends Claude on a grep expedition through a dozen files, each one read into context and billed for the rest of the session. If you know it’s in src/lib/validators.ts, say so. Ten seconds of specificity routinely saves 50,000 tokens of exploration. Same logic applies to reads: pointing Claude at a line range beats letting it ingest a 2,000-line file to use 40 lines of it.

None of this requires discipline beyond noticing. Watch /context for a day and the wasteful patterns identify themselves. And if you’d rather have Claude enforce these habits on itself, we distilled them into a free skill and benchmarked it on five controlled task pairs — about −20% on real multi-step work.

Fix 5: route cheap subtasks to cheaper models

Yes, model routing saves money. We list it fifth because in every audit we’ve done, teams reached for it while a bloated CLAUDE.md and six idle MCP servers burned three times more. Structure first, then routing.

That said, the arithmetic is real: Haiku costs a fifth of Sonnet and a fifth again of Opus. The clean way to exploit it in Claude Code is subagents. Exploration, summarizing a long file, generating boilerplate tests, first-pass commit messages: delegate these to a Haiku subagent while the main loop stays on your primary model. Claude Code’s own architecture does this internally for some search tasks, which tells you Anthropic thinks the pattern is sound.

What we don’t recommend is flipping the main session’s model back and forth mid-task. Prompt caches are per-model, so every switch throws away your cached prefix and repays full price to rebuild it. Pick a model per session; route at the subagent boundary. And keep the hard reasoning on the strong model. A cheap model that produces a wrong plan costs more than an expensive one that’s right the first time. We’ve measured that too, unfortunately.

Fix 6: the token-efficiency skills we’re testing

We track a dedicated Token Efficiency category, and we hold it to a stricter standard than any other: a verdict there has to come with a measured before/after bill, not vibes. That makes verdicts slower. Here’s the honest current state.

Token Budget Auditor reads your transcripts and setup and names your top token offenders: bloated system context, redundant file reads, chatty tool loops. It’s the “measure first” step packaged as a skill. Verdict pending; we’re running a before/after billing comparison on our own accounts before we score it.

Context Compression packages the summarize-and-continue discipline from fix 4 so long sessions compact into structured summaries instead of dragging raw history. In the test queue; we’re measuring token savings against information loss across a week of real sessions, because compression that forgets your constraints is worse than no compression.

Prompt Cache Optimizer restructures context for cache friendliness: stable content first, volatile content last. The most common waste it targets is a timestamp interpolated near the top of a prompt, silently invalidating the cache on every request. One-line fix, double-digit savings when it applies. We’re measuring live cache-hit rates before issuing a verdict.

The one adjacent skill that has cleared testing is Memory Management, which scored 9.2/10 in our week-long trial. It lives in our productivity category, but it’s a token play at heart: persistent memory converts repeated re-discovery (fix 4’s most expensive failure mode) into one write and cheap recalls. Claude remembering your project’s decisions is Claude not re-reading twelve files to reconstruct them.

The full list, with test notes and whatever verdicts exist, is at best efficiency skills. We’d rather show you a queue with measurements running than a page of confident scores we can’t back.

The Optimizer Pack, if you want the shortcut

One honest paragraph on our own product. The Optimizer Pack is the efficiency setup we’d install on our own machines: the three efficiency skills above plus Memory Management, pre-configured, with a trimmed CLAUDE.md template and an MCP audit checklist, installed with one command. It’s $10, mostly because packaging and maintaining the configs takes real time. Everything in it is also available free from the individual skill pages; the pack saves you an evening of setup, nothing more. If you enjoy the tinkering, skip it.

A realistic before and after

Here’s a sketch based on a composite of heavy users we’ve audited: a developer running Claude Code four-plus hours a day on Sonnet via API, with a 2,500-line CLAUDE.md, five MCP servers, and marathon sessions.

Before: roughly 140 million input tokens and 4 million output tokens a month. With mediocre cache performance (the CLAUDE.md had a dynamic header, so caching barely worked), that’s in the neighborhood of $480 a month.

After applying fixes 1 through 5: pruning three MCP servers and trimming CLAUDE.md to 60 lines cut the per-request preamble by about 45,000 tokens. Converting seven pasted prompts to skills removed another chunk of every-turn history. Fresh sessions and earlier compaction shortened average history length by a third. Fixing the cache invalidator meant the remaining stable context finally billed at the cached rate. Routing exploration subagents to Haiku shaved the rest. New bill: around $210 a month.

That’s a 55 percent reduction with zero change in what got built. Your numbers will differ, and we’d treat anyone promising an exact percentage with suspicion, including us. But roughly halving a heavy user’s bill through structure alone matches what we’ve seen more than once. The pattern holds on subscriptions too: the same person stopped hitting Max plan limits mid-afternoon.

FAQ

Does any of this matter if I’m on a Pro or Max subscription instead of the API? Yes, just in a different currency. Subscriptions meter you through usage limits, and those limits are consumed by the same tokens an API user pays for. A leaner setup means more real work before you hit the cap. Users who “constantly hit limits” are usually carrying 40,000 tokens of preamble per request without knowing it.

Do installed skills cost tokens when they’re not being used? Only the trigger description, typically 30 to 60 tokens per skill per request. The body loads when the skill fires. Twenty installed skills cost about 1,000 tokens of standing overhead, which is why a big skill library is cheap while a big CLAUDE.md is not. The one failure mode is skills with bloated descriptions; we flag those in our reviews.

How much context does an MCP server actually consume? It varies wildly, which is why you should measure yours: run /context with the server connected, then disconnected. Small focused servers add 1,000 to 3,000 tokens of schemas. Large official ones can add 15,000 to 25,000. The cost applies to every request whether or not you call any tool.

Is /compact better than starting a fresh session? Different jobs. /compact is for continuing related work: it summarizes history so context carries forward smaller. A fresh session is for changing topics, and it’s the cheaper and better option then, because unrelated history isn’t just expensive, it actively degrades output. If you’re compacting to continue something unrelated, you wanted /clear.

Doesn’t prompt caching solve this automatically? It helps a lot and it’s on by default in Claude Code, but it discounts waste rather than removing it. Cached tokens still bill at about 10 percent, still fill your context window, and still push you toward early compaction. And caching breaks silently: any change to the stable prefix, like a timestamp in your setup, and you’re back to full price without a warning. Structure your context well and caching multiplies the savings; structure it badly and caching hides the problem until the invoice.