Claude Code Token Savings in Practice: 63% Less Tokens for the Same Fix

Same Bug, Nearly 3x the Token Cost — Why?

Here's a counterintuitive finding: fix the same bug, use the same code, get the same result — one configuration consumed 91,000 tokens, while another used only 34,000. That's more than a 2.6x difference. This isn't random — it's Claude Code's token billing mechanics at work.

The Rocket Launcher team ran rigorous tests using a fixed practice project: resetting the environment before each run, taking the median of three runs per test, based on Claude Code version 2.1.293. They also give an honest caveat upfront: the costs shown are official API list prices and may not reflect how your subscription plan actually weights token usage. But the token counts themselves are real and reproducible.

The key to understanding where tokens go: every time you send a message, Claude Code resends the entire conversation — including the list of available tools, system instructions, your CLAUDE.md file, skills, and the full conversation history. Even if you reply with just "OK," roughly 16,500 tokens get sent from the script runtime.

Keep the Cache Warm: Same Request, Nearly 8x Cheaper

To control costs, Claude caches the beginning of a conversation so that already-read text can be re-read at a much lower price. Test one confirmed this: sending the same 16,500-token request twice — the first time requires writing to cache at 2.6 cents; the second time reads from cache for just one-third of a cent. Same tokens, nearly 8x cheaper.

The critical gotcha: change even one line at the very start of a request, and Claude rebuilds the entire cache — essentially a cold start. In this test environment, a warm cache lasts about one hour. The practical advice: stick to a consistent configuration during a work session, and don't modify it mid-session.

Claude's Prompt Caching is an optimization mechanism Anthropic provides at the API level. When a block of text remains unchanged across multiple requests and sits at the beginning of a conversation, the server retains the KV cache (Key-Value Cache — the intermediate computation results from the Transformer attention layers) for that content in memory. Subsequent requests that read cached content are billed at "cache read token" rates, roughly one-tenth the price of regular input tokens. Writing to the cache costs slightly more than regular input tokens, but only once.

The conditions for a cache hit are strict: the prefix must be exactly identical, and it must exceed a minimum length threshold (typically 1,024 tokens). This explains why changing the first line of a request invalidates the entire cache — cache matching proceeds byte-by-byte from the head, and any prefix change causes a complete cache miss. Claude Code's system prompt, tool list, CLAUDE.md, and similar content naturally sit at the front of the conversation, so keeping them stable is the core strategy for maintaining high cache hit rates.

Only Load What You Actually Use

Test two compared two project configurations. The Lean version had a short CLAUDE.md and sent 16,500 tokens; the Fat version had a 356-line CLAUDE.md, 20 skills, and 3 MCP servers, sending 21,500 tokens per message — 5,000 more.

To see exactly where tokens are going, use the /context command. It lists how much each component takes up: system prompt, tools, memory files, skills, and conversation history.

For a more aggressive approach, you can manually choose which tools to load. The author kept only five core tools — Read, Edit, Search, Find, and run command — and disabled all skills. The result: a single message dropped to 7,200 tokens — less than half the Lean version and less than a third of Fat.

On a real bug-fixing task (nine runs, two fix approaches), Fat used 91,000 tokens, Lean used 70,000, and the minimal-tools configuration used only 34,000 — 52% less than Lean and 63% less than Fat. The trade-off is real: in five-tool mode, Claude can't browse the web or call other tools. It's suited for focused tasks, not everything.

To find skills you've never used, open /plugin and go to the stats tab — it shows each skill's size, run count, and last used time. The author's project had 120 skills with zero uses.

Pick the Right Model: Small Tasks, Small Model

Test three ran the same failing test through different models: Sonnet cost 2.6 cents to fix, Opus cost 4 cents, and Haiku cost roughly one-sixth of a cent. Haiku fixed it successfully all three runs — 17x cheaper than Sonnet and done in 6 seconds (vs. 10 for Sonnet).

But the author's conclusion is measured: this was a one-line bug in a small project. It shows simple tasks can use smaller models — not that hard tasks can too. The recommendation: use /model to try Haiku first on well-defined tasks, and pay for a larger model only when you hit something genuinely difficult.

Let It Search — Don't Dump Files on It

Test four focused on large files. The project had a 4,800-line guestbook file. The question: "How many entries are from Japan with more than 30 likes?" (correct answer: 15).

Three approaches yielded dramatically different results: asking the question directly let Claude choose to search the file via command, consuming 50,000 tokens — always correct; asking Claude to read the entire file consumed 134,000 tokens (2.6x more) at 12x the cost; attaching the file with @ fell in between at 79,000 tokens.

The conclusion is clear: ask the question, let Claude search on its own — don't proactively hand it the file.

Delegate Heavy Reading to a Cheaper Sub-Agent

Test five introduced the sub-agent concept: a second Claude works in its own window and passes only the answer back. Keeping Sonnet in the lead role while delegating the reading to a Haiku sub-agent for the same large file — same answer of 15, correct all three times. Sonnet reading the full file itself cost 14 cents; delegating to Haiku cost 2 cents — 7x cheaper. Total token count was actually higher, but they were all cheap Haiku tokens.

But this isn't always worth it. On a small task (retrieving a list from 20 small files), cost actually rose from 1.5 cents to 2.4 cents, because sub-agents carry their own startup overhead. The principle: delegate when reading volume is large, handle it yourself when the volume is small. The /usage interface also flags which simple sub-agents could be swapped for a cheaper model.

In Claude Code, a sub-agent is an independent Claude process dynamically launched by the main session. It has its own context window and returns only the result text to the main agent once the task is complete. The economic logic: tokens consumed by a sub-agent are billed entirely at the sub-agent's own model rate, without polluting the main session's context. When a task consists mainly of reading large volumes of text (e.g., scanning thousands of lines of logs or a large file), delegating it to Haiku means the main session (Sonnet or Opus) only receives a short concluding response — shifting bulk input tokens from expensive models to cheaper ones.

Sub-agents carry a fixed startup cost — they need to initialize their own system prompt and tool list — which can offset the price advantage when the task is small. So the sub-agent strategy works best for scenarios where "reading volume far exceeds reasoning volume," not for simple queries that only require reading a small amount of text.

The Most Popular Tip Can Nearly 7x Your Costs

Test six examined that widely shared advice: run /compact when a session gets long to save tokens. The author built up a session with 42,000 tokens of history, then added a question in three ways.

The results were surprising: staying in the original session cost 0.9 cents; opening a new session cost 1.8 cents (Claude had to re-read the code); running compact first, then asking, cost 6 cents — nearly 7x more than doing nothing. The reason: Claude first writes a summary, then rebuilds the cache around that summary.

Compact does make subsequent messages smaller (about 24,000 fewer tokens), but it takes roughly 11 more messages to break even. So only use it when a session is genuinely long and you plan to keep working — don't compact before every question.

Another useful setting is effort level: the same code review produced 470 tokens on low effort and 1,200 on high — low effort is 65% cheaper and 5 seconds faster, and all six runs caught the same primary bug. Setting effort on sub-agents, however, showed no benefit and doubled costs — not recommended as a token-saving measure.

The /compact command works by having Claude read the entire session history, generate a compressed summary, and replace the original conversation record with that summary — shortening the context length for subsequent requests. The cost spike happens for two reasons: first, generating the summary requires reading the full history all at once, an immediately large expense; second, the summary as a new "prefix" is completely different from the existing cache, forcing a full cache cold start. All that previously cached content is invalidated, and the next several messages are billed at non-cached rates until the new cache gradually warms up.

So /compact's benefit is deferred — it makes each subsequent message smaller, but the upfront one-time cost is high. The investment only pays off if you're certain you'll continue sending many messages in the same session. For sessions nearing their end or one-off queries, compact creates pure cost waste.

Build a Live Token Meter

The author's most shareable contribution is a real-time token monitoring tool. Claude Code has a status line feature — at the bottom, you can run any script and receive session data in JSON format. With 25 lines of Python, they built a live meter that: accumulates every request in the session in real time, and displays the model, context size, token count and cache hit rate for the current prompt, session totals, cost, and whether the cache is warm.

In practice: ask a small question and see that 86% hit the cache; ask another, and the session has accumulated 107,000 tokens — almost entirely cache hits — for less than half a cent. You can watch consumption in real time instead of discovering you've burned through your budget after the fact. Just add one line in settings to enable it.

Ranked Findings From the Tests

Ranked by measured impact, six effective recommendations are: 1) Keep the cache warm; 2) Only load what you actually use; 3) Match the model to the task; 4) Ask questions instead of attaching files; 5) Delegate heavy reading to Haiku; 6) Save at the right time. Two things to skip: compacting too early, and setting effort on sub-agents.

The author honestly states the limitations: based on one small project with three runs per test — your numbers will vary with your codebase and version updates; costs are official list prices and actual plan billing may differ; interactive sessions also start larger (about 27,000 tokens). But the relative ordering of these changes held true in every test, and all tests are reproducible. The recommendation: use /context to map out your own token usage, and use usage reports for before-and-after comparisons.