Does Claude Code's context management actually save money

Short answer: yes, a little, and probably not where you think. Auto-compaction reduces the number of tokens you resend on every future turn, so it does lower spend on long sessions. But the dominant cost variable in a Claude Code session is not how many tokens are in your context. It is what fraction of those tokens are being billed at the cached-read rate. Anthropic bills a prompt cache read at roughly a tenth of the base input price, and a cache write at about 1.25x base input for the five-minute TTL. That spread is where the real money lives.

Compaction rewrites the conversation prefix. A rewritten prefix cannot match the cached one, so the next turn pays a full write at 1.25x on the new summary plus whatever the agent reloads, and every cached token you had accumulated is discarded. So a single compaction is a token reduction and a cache reset at the same time. On a session that would have kept running with a warm cache, compaction can be roughly cost-neutral or slightly negative in the short run, and only pays off over the turns that follow. On a session that was about to hit the context ceiling and die, it is unambiguously worth it, because the alternative is you starting over by hand.

What Claude Code is actually doing

It helps to separate the mechanisms, because they have different cost profiles and people lump them together under one label.

• Auto-compact: as the session approaches the context window limit, the transcript gets summarized and the session continues from that summary. The summarization itself is a model call you pay for.
• Manual /compact: the same thing on demand, optionally with an instruction about what to preserve. Cheaper than auto-compact only in that you choose the moment, so you can compact right after finishing a chunk of work rather than in the middle of one.
• /clear: drops the conversation entirely. Zero summarization cost, zero carried context, and a cold cache on the next turn.
• Tool-result trimming: recent versions prune the bodies of older tool outputs while keeping the surrounding turn structure. This is the most cost-favourable of the group, because it removes the bulkiest tokens with the least disruption.
• Scoping instructions: CLAUDE.md, narrow file reads, and subagents that return a short answer instead of dumping a whole search result into the main thread.

Of those, the last two are the ones I would spend effort on. They reduce the amount of context you accumulate in the first place, which means fewer compactions, which means fewer cache resets.

The arithmetic, roughly

Take a session sitting at 120k tokens of context. With a warm cache, each subsequent turn bills most of that at 0.1x base input, so you are effectively paying for about 12k tokens of input plus your new turn. Without a cache, you pay 120k at 1.0x, and if the prefix changed you pay some of it at 1.25x as a write. The gap between the warm and cold case on that single turn is roughly an order of magnitude.

Now compact that session down to a 15k summary. Your per-turn uncached cost drops by 8x, which sounds great. But you paid a summarization call over the full 120k, you pay a 1.25x write on the new prefix, and you gave up the discount you already had. If you only run three more turns after compacting, you likely lost money. If you run forty, you won.

This is why I am sceptical of anyone quoting a flat percentage saving for compaction. The number depends entirely on turns-after-compaction, and nobody publishing a benchmark tells you what theirs was.

The subscription wrinkle

If you are on a Claude subscription rather than API billing, none of this shows up as dollars. It shows up as how fast you hit your usage limit. The mechanics are the same, the currency is different, and the feedback is much worse: you find out you were wasteful when the session cuts off, not when the invoice arrives. Developers on subscriptions routinely have no idea whether their context habits are costing them a third of their weekly allowance or a twentieth.

That gap matters for a second reason. If you are on a plan tier above what you actually consume, you are paying a fixed monthly amount for headroom you never touch, and no amount of context tuning changes that. Worth checking before you optimize anything.

What actually cuts a Claude Code bill

In rough order of how much they moved my own numbers:

• Keeping the prompt cache warm. Anything that mutates the front of your conversation between turns costs you the 0.1x read rate on everything after it. Editing a file that Claude Code has in its system prompt region, switching models mid-session, or compacting all do this.
• Not reading whole files when you need forty lines. A 4k-token file read that becomes permanent context is a 4k-token tax on every remaining turn until compaction.
• Running cheap models for the work that does not need an expensive one. Commit message drafting, log summarization, and one-line lookups do not need the top tier.
• Caching identical calls. Agents genuinely repeat themselves, especially when a loop retries or when two subagents ask the same question.
• Using a local model for the trivial fraction. If you already have something running in Ollama or LM Studio, a chunk of your traffic can be served for the electricity.
• Compaction. Real, but fourth or fifth on this list, not first.

Why I built the measuring part

I got tired of guessing at all of the above. I built Probe0 as a local proxy that sits between every coding agent CLI on my machine and whatever provider they call, so Claude Code, Codex, and Cursor all route through one place with one certificate and no per-tool config. There is no Probe0 server. The ledger lives on my disk.

The Recording module logs every request with model, token counts, real cost, latency, and which process made the call. That is what let me stop arguing about compaction and just look at whether the cached-read fraction went up or down after each change. The other modules are switchable and each reports what it saved: Local Routing hands work to a model already running locally and retries weak answers on the cloud, Model Tiering tries the cheap model first, Exact Cache is a local disk cache that never touches the network, Semantic Cache uses a local vector index with a strict similarity floor and refuses to match anything carrying tool calls because a wrong hit corrupts a run, Request Coalescing collapses simultaneous identical calls into one upstream, and Spend Guard warns and then pauses at a hard cap per run or per day. Because it sees actual usage, it can also tell you when your plan tier is above what you use.

I will be plain about the limits. It is macOS only and in private beta. It is a single-developer tool, not a team gateway with multi-user auth or shared deployment. Provider coverage is what coding agents actually call, not a hundred-plus catalogue. If you need a hosted gateway your whole team points at, LiteLLM or a commercial gateway is the better answer and I would say so.

One thing that surprised me while building it: prompt compression, the technique of shrinking the context with a model before sending it, is often net negative on this workload for exactly the reason above. Compressing mutates the prefix, forcing 1.25x writes that never get read back at 0.1x. It is why Probe0 only compresses the tail of a request, and why compression ships off by default until the measurement harness proves it out on your traffic.

Compaction is a session-survival feature that happens to have a cost side effect. Treat it as the cost strategy and you will optimize the wrong number.

If you take one thing away: before you tune your compaction habits, go find out what fraction of your input tokens are being billed as cache reads. If it is high, leave things alone. If it is low, fix that first, and compaction becomes a rounding error either way.