Spend Less Per Token — A Field Guide to Cutting Claude Costs
By Admin
Every word Claude reads and writes is metered. This is a practical field guide to shrinking that meter — using the levers Anthropic already built in, plus the handful of open-source tools the community has actually starred into the tens of thousands.
There are two ways to lower a Claude bill. You can pay less per token, or you can move fewer tokens. Most people reach for the first lever — a smaller model — and stop there. The bigger wins are almost always in the second: not sending tokens you didn't need to send, and not asking for tokens you didn't need back.
Before any of that, a mental model. You are billed on input (everything Claude reads: your prompt, system instructions, files, conversation history, tool definitions) and output (everything Claude writes). Output is the expensive side — across the current model line it runs 5× the input rate. So a verbose answer costs far more than a verbose question, and "make Claude talk less" turns out to be one of the highest-leverage knobs you have.
Anatomy of a request — where the tokens are
A typical request, before any optimization, breaks down into roughly four pieces:
| Segment | What it is | The lever |
|---|---|---|
| System + tools | System prompt, skills, MCP tool definitions | Trim it / cache it / fewer MCP servers |
| Files / RAG | Documents and code loaded into context | Semantic retrieval; read functions, not files |
| History | Accumulated conversation turns | /compact, /clear, summarize old turns |
| Output (5× rate) | Everything Claude writes back | Concise instructions; right-size the model |
The pattern holds across workloads: input is mostly stuff you resend every turn (and is therefore cacheable), while output is where each token costs the most. Optimize both, separately.
Step Zero — Measure before you optimize
You cannot improve what you cannot see, and "it feels expensive" is not a baseline. The single most common mistake is installing four optimization tools at once and never knowing which one helped — or whether any of them did. Spend the first session just looking.
Inside Claude Code, two built-in commands cost nothing and answer most questions. /context breaks down exactly how many tokens you're carrying right now — system prompt, loaded skills, MCP tool definitions, files, conversation. A "fresh" session already starts with thousands of tokens of overhead, and if you've loaded several MCP servers or skills you can be tens of thousands deep before you type a single word. /clear resets the conversation to drop accumulated history. If /context shows files or skills you won't use this session, clearing and reloading clean is free savings.
On the API side, the equivalent move is to read the usage object that comes back on every response. It reports input_tokens, output_tokens, and — crucially — cache_read_input_tokens and cache_creation_input_tokens. That last pair tells you whether prompt caching is actually working, which is the difference between thinking you're saving money and proving it.
Rule of thumb: Run with measurement on for a week before changing anything. A controlled baseline turns "I added complexity and hoped" into "this lever saved 38%."
Part One — The built-in levers (highest ROI)
These are features Anthropic ships and documents. They require no third-party code, carry no supply-chain risk, and deliver the largest, most reliable savings. Start here, always.
1 · Prompt caching — the single biggest API win
If your requests share a stable prefix — a long system prompt, a knowledge base, a set of tool definitions, a document you're asking many questions about — you are, by default, paying full price to reprocess identical tokens on every call. Prompt caching tells the API to store that processed prefix once and read it back cheaply.
The economics are stark. A cache read costs just 10% of the standard input rate — a 90% discount on every cached token. The catch is small: the first write costs a 25% premium (for the 5-minute cache) or 2× (for the 1-hour cache), and a block must be at least 1,024 tokens to be cacheable. Any read within the time window resets the clock, so a busy app warms up once and then pays the discounted rate effectively forever.
How it flows:
- Request 1 (cold): the 50K-token prefix is processed at full price, plus a 1.25× write premium.
- Requests 2…N (warm): the same prefix is read back at only 0.10× — a 90% cut on input.
Do: put the stable stuff first. Caching is prefix-based, so anything before the changing part (the user's question) can be reused.
Don't: interleave volatile content into the cached block — one changed byte near the front invalidates everything after it.
For any app with a system prompt over ~2K tokens and more than a few hundred daily calls, caching is the change with the best return on effort. Real-world RAG apps routinely report 70–90% cache-read rates on their static context.
2 · The Batch API — 50% off for anything that isn't real-time
If a job doesn't need an answer this second — nightly reports, bulk classification, document extraction, offline evals — send it through the Batch API. It processes asynchronously within a 24-hour window at a flat 50% discount on both input and output, with no quality difference. Same model, same inference; Anthropic just schedules it during quieter capacity.
The two discounts stack. A cached prefix read inside a batch request multiplies out to 0.5 × 0.1 = 0.05 — five cents on the dollar for those input tokens.
Stacking discounts (input cost per million tokens):
| Configuration | Effective input cost |
|---|---|
| Standard | 100% |
| + Batch | 50% |
| + Cache read | 10% |
| + Both | 5% → up to 95% off |
Worked example: 100K docs through Haiku 4.5 with cached instructions, batched → a ~$5,000/mo workload drops to roughly $300/mo.
Caching is the lever for input-heavy jobs (big reused context). Batch is the lever for anything asynchronous. They compound.
3 · Right-size the model
The instinct to "just use the cheapest model" is wrong; the right instinct is to match model to task. The current line spans a 5× price range. Most coding and routine work sits comfortably on Sonnet; reach for Opus only when the reasoning genuinely demands it, and push high-volume mechanical work (file reads, test runs, classification, exploration) down to Haiku.
| Model | Price (in / out per MTok) | Best for |
|---|---|---|
| Haiku 4.5 | $1 / $5 | File reads, test runs, classification, subagent exploration |
| Sonnet 4.6 ★ default | $3 / $15 | ~80% of everyday coding, drafting, refactors, agent work |
| Opus 4.8 | $5 / $25 | Hard reasoning, long-horizon agents, the genuinely thorny 10% |
In Claude Code you can set the subagent model to Haiku via CLAUDE_CODE_SUBAGENT_MODEL=haiku so exploration runs cheap while your main thread stays sharp. Teams that route automatically commonly report 40–60% savings on mixed workloads.
Watch out: Opus 4.7 and later use a new tokenizer that can produce up to 35% more tokens for the same text than Opus 4.6. Per-token prices didn't change, but the same prompt can cost more. And requests above 200K input tokens trigger long-context premium pricing — another reason to keep context lean.
Part Two — Behavioral techniques (free, just discipline)
No tools required for any of these. They're habits that move fewer tokens.
Make the output terse
Because output is the 5×-rate side, telling Claude to drop preamble, hedging, and restated context is pure profit. A short instruction — "answer concisely, no preamble, code over prose" — pays for itself many times over on output-heavy work. Interestingly, a 2026 paper on brevity constraints found that forcing large models to be brief sometimes improved accuracy, so this isn't always a quality trade.
Trim the always-on context
In Claude Code, a bloated CLAUDE.md is a fixed tax: an 11,000-token instructions file you wrote three months ago gets re-read on every single message. Keep it short and current. The same goes for MCP servers — each one injects its tool definitions into your window, so keeping enabled servers under ~10 per project meaningfully lowers your starting overhead.
Use subagents for exploration
When you need to understand a codebase, don't read twenty files into your main context. Dispatch a subagent (the Task tool) to read them and return a summary. The subagent burns the tokens; your main thread stays clean and stays cheap on every turn afterward.
Cap the thinking budget for easy tasks
Extended thinking reserves a large block of output tokens for internal reasoning you never see. For trivial tasks that's waste — lowering MAX_THINKING_TOKENS (or disabling it) cuts hidden cost. Reserve deep thinking for problems that actually need it.
Compact and clear deliberately
Long sessions accrete history that rides along on every request. Trigger /compact at logical breakpoints (between tasks) rather than letting auto-compaction fire mid-task, and /clear when you start something unrelated. On the API, summarize old conversation turns instead of resending them verbatim.
Read functions, not files
When Claude needs one function out of a 1,500-line file, loading the whole file is the expensive default. Semantic retrieval — indexing the codebase and pulling only the relevant slices — can cut review and navigation tokens by an order of magnitude. (Part Three has a popular tool for exactly this.)
Part Three — The open-source toolkit
The community has built a deep bench of token-saving tools. Rather than list everything, here are the top five by GitHub stars — pulled live from the GitHub API on June 28, 2026 — each representing a different category of saving. Star counts move daily; treat these as a snapshot of where adoption has actually concentrated.
Top token-saving repos · stars (June 28, 2026)
| Rank | Repo | Stars | What it does |
|---|---|---|---|
| 01 | caveman | 77,458 | Compress output |
| 02 | claude-code-router | 35,380 | Route to cheaper models |
| 03 | ccusage | 16,643 | Measure spend |
| 04 | claude-context | 11,983 | Retrieve less |
| 05 | usage-monitor | 8,280 | Watch the budget |
High star counts correlate with battle-testing across many installs — but always check a repo's recent commits and read what it does before wiring it into your workflow.
Rank 01 · 77,458 ★ — caveman
github.com/JuliusBrussee/caveman — cuts output tokens
A Claude Code skill (and plugin for 30+ other agents) that makes the model answer in compressed, terse "caveman" prose — fragments instead of paragraphs, no filler or hedging, technical substance fully intact. Published benchmarks show an average ~65% reduction in output tokens across real prompts. Code blocks and error messages are always quoted exactly, and a sub-skill can compress your CLAUDE.md so the savings persist into every future session. Because output is the costliest side, this is the fastest single fix if verbose responses are what's draining your limit.
Rank 02 · 35,380 ★ — claude-code-router
github.com/musistudio/claude-code-router — routes to cheaper models
A routing layer that sits in front of Claude Code and dispatches each request to the most cost-appropriate model or provider based on rules you set — flagship for hard reasoning, mid-tier for the bulk, lightweight for mechanical tasks. It automates the "right-size the model" discipline so you don't have to switch by hand. One caution: if you point it at external providers it handles API keys, so keep those in a secrets manager, never in plain text in the repo. Pairs cleanly with MCP servers; the router handles model selection, MCP handles integrations.
Rank 03 · 16,643 ★ — ccusage
github.com/ccusage/ccusage — measures your spend
The de facto community standard for understanding where your tokens go. It runs fully offline with pre-cached pricing, ships a tiny bundle, and offers MCP integration so you can have Claude analyze its own usage. It doesn't reduce tokens directly — it's the prerequisite that makes every other optimization measurable. Run this first, establish a baseline, then add reducers one at a time so you can attribute each saving. Without a measurement layer, every optimization is done blind.
Rank 04 · 11,983 ★ — claude-context
github.com/zilliztech/claude-context — retrieves less context
An MCP server from Zilliz that gives Claude semantic, indexed search over your codebase. Instead of loading whole files to find one thing, Claude queries the index and pulls only the relevant slices into context. This directly attacks the "files/RAG" segment of your input bill — the larger and more sprawling the repository, the bigger the win. It's the cleanest answer to "read functions, not files" without you having to hand-pick what to load.
Rank 05 · 8,280 ★ — Claude Code Usage Monitor
github.com/Maciek-roboblog/Claude-Code-Usage-Monitor — watches the budget live
Where ccusage is the end-of-day analytical view, this is the live heads-up display. It runs in a side terminal pane with progress bars, burn-rate analysis, and predictions of when you'll hit your session limit — auto-detecting your plan and warning before you blow through it. For anyone running parallel agents on a Max plan, the early warning is the difference between finishing a refactor and getting cut off mid-task. Install via uv tool install claude-monitor. Complementary to ccusage, not redundant: one for history, one for real-time defense.
Supply-chain hygiene: A high star count signals adoption, not safety. Before installing anything: read what it actually does, check that it's recently maintained, and be especially careful with tools that handle API keys or route traffic to third-party providers — those touch your credentials and your compliance posture.
The Playbook — A sane order of operations
Don't do all of this at once. Layer it, measuring after each step, and stop when the savings stop justifying the added complexity.
- Measure. Install ccusage (or run
/context) and establish a one-week baseline. No baseline, no proof. - Cache. If you have any reused prefix over ~1K tokens, add caching. This is usually the biggest single win on the API.
- Batch. Move every non-real-time job to the Batch API for an automatic 50% off. Stacks with caching.
- Route. Right-size the model per task — by hand at first, then with claude-code-router once the rules are clear.
- Trim. Shrink
CLAUDE.md, prune MCP servers, cap thinking budget, and compact history at logical breaks. - Compress + retrieve. Add caveman for terse output and claude-context for lean retrieval if your output and codebase reads are the bottleneck.
- Re-measure. Confirm each layer actually helped. Remove anything that didn't.
The honest ceiling: Stacked well, these techniques commonly land in the 30–90% range depending on workload — repetitive, input-heavy jobs save the most; novel reasoning saves the least. But savings aren't the goal, they're the means: a leaner context window means longer sessions, harder problems solved in one shot, and fewer interruptions. If your
CLAUDE.mdis already under 1K tokens and your cache-hit rate is north of 95%, you're already winning — don't add tools for the sake of it.
Sources & verification
Star counts queried from the GitHub API on June 28, 2026 (caveman 77,458 · claude-code-router 35,380 · ccusage 16,643 · claude-context 11,983 · Claude Code Usage Monitor 8,280). Pricing, prompt-caching, and Batch API figures from Anthropic's published pricing and prompt-caching documentation. Star counts and prices change — re-verify before you rely on them.
Built as a field guide, not financial or security advice. Vet third-party tools before installing.