Why a smaller prompt can cost you more

The context meter reads 78% and the number starts to feel like money. So you go looking for the setting that makes it smaller. A tool-output trimmer, a compression layer, an auto-compact threshold pulled down, an instruction to the agent to stop reading whole files. Tokens per turn drop, visibly, on the dashboard you were watching. The bill does not follow, and sometimes it goes the other way.

The reason is that the same input token has three different prices depending on how it reaches the model, and the cheapest of the three is the one you get for leaving your context alone. This guide is for someone paying real money for a coding agent, on an API key or drawing on usage credits, and looking at a compression feature. If you use Claude in a browser tab a few times a day, none of this applies to you; your cost is a subscription and your context is short.

Your agent re-sends the whole conversation on every turn

The model remembers nothing between requests. Each time you send a message, Claude Code re-sends the system prompt, your project context, every prior message and tool result, and your new message [1]. New content goes on the end, so most of each request is identical to the one before it. The API matches the start of each request, called the prefix, against content it recently processed and bills the matched part at a much lower rate. The match is exact, and there is no per-file or per-segment caching, so a change anywhere in the prefix recomputes everything after it [1].

Claude Code orders each request to take advantage of that. Core instructions, tool definitions and output style come first, then project context from CLAUDE.md and memory, then the conversation itself [1]. Sending a new message touches only the last layer. Changing the system prompt invalidates all three, because everything behind it now sits behind a different prefix [1].

That shape explains where a long session’s money goes. Anthropic puts average enterprise Claude Code spend at around $13 per developer per active day and $150 to $250 per developer per month, with 90% of users staying under $30 per active day [2]. A one-line question at 5pm in a session you opened at 9am still draws usage for the entire conversation, because the entire conversation is in the request [2].

A cache read costs a tenth of a fresh read, and a rebuild costs more than either

Three rates apply to that same input token. Processing it fresh is the base input price. Reading it back from cache is 0.1x that price. Writing it into a five-minute cache is 1.25x, and into a one-hour cache 2x [3].

On Claude Sonnet 5 those numbers are $2 per million tokens of fresh input, $0.20 per million read from cache, $2.50 per million written to a five-minute cache and $4 per million written to the one-hour cache. On Claude Opus 5 the same four figures are $5, $0.50, $6.25 and $10 [4].

Put a 200,000-token context through them. Re-reading it from a warm cache costs 4 cents on Sonnet 5. Processing it fresh costs 40 cents. Writing it into a five-minute cache costs 50 cents. The event that happens on nearly every turn of a healthy session is twelve times cheaper than the event that happens when the prefix breaks [3][4]. Token count sets the size of each event. Cache behaviour decides which event you are buying.

Anthropic’s own team treats that ratio as infrastructure rather than an optimisation. It runs alerts on prompt cache hit rate and declares SEVs when the rate drops too low, and it designed plan mode, deferred tool loading and compaction around keeping the prefix intact [6].

Trimming context is a trade, and the trade has a break-even

Anthropic’s API offers context editing, which clears the oldest tool results out of the conversation in chronological order once the prompt passes a threshold and replaces each one with placeholder text telling Claude it was removed. By default it activates at 100,000 input tokens and keeps the three most recent tool uses [5]. It is exactly the kind of feature that makes a token chart look better.

The documentation is blunt about the catch. Tool result clearing “invalidates cached prompt prefixes when content is cleared”, and “you’ll incur cache write costs each time content is cleared” [5]. The advice that follows is a break-even instruction: “clear enough tokens to make the cache invalidation worthwhile”, using the clear_at_least parameter to set a floor on how much each activation removes [5].

Run that arithmetic yourself. Say a 200,000-token prefix gets cut by 40%. You pay a cache write on the 120,000 tokens that remain, which is 30 cents on Sonnet 5, in order to save 1.6 cents per turn on the 80,000 tokens you no longer re-read. You need roughly nineteen further turns on that shorter prefix before the trim has paid for itself, and any of the actions in the next section resets the count to zero.

Field measurement finds the same shape. Weinberger and Hozez evaluated three token-reduction approaches against an unmodified Claude Code baseline on controlled coding tasks, measuring provider-billed cost rather than estimated token counts, and reported that the largest compression setup cut delivered tool-output tokens by 38.4% while increasing billed cost by 6.8% [7]. Across tasks, token reduction was weakly correlated with cost reduction, at a Pearson r of 0.15 [7]. Their explanation matches the price list: “prompt-cache creation and reads dominate the measured input-side cost, leaving only a limited fraction of total spend directly addressable by tool-output compression” [7]. Compression also altered agent trajectories through additional retrieval, diagnosis, testing and turns, and on a SWE-bench Go subset the aggressive setting reduced successful patch application [7].

The actions that rebuild your cache without telling you

Claude Code documents the list, and most of it is things you do casually. Switching model with /model gives the next request no cache hits at all, because each model has its own cache and identical content behind a different key is not a match [1]. Changing effort level with /effort does the same, for the same reason [1]. Turning on fast mode adds a request header that forms part of the cache key, so the first turn after you enable it re-reads the whole conversation at fast-mode rates, which is why switching it on deep into a long session costs more than switching it on at the start [1].

Connecting or disconnecting an MCP server invalidates the cache when its tools sit in the prefix rather than being deferred, and that can happen without any action on your part, when a stdio server’s process exits or an HTTP session expires [1]. Adding a bare tool name such as Bash or WebFetch as a deny rule removes that tool from the system prompt and rebuilds from the top [1]. Upgrading Claude Code usually changes the system prompt or tool definitions, so the first request after a restart is uncached, and resuming a long conversation after an upgrade can be the most expensive request you send [1].

Compaction is on the list by design. It replaces your history with a summary, so the next request has a shorter history that shares no prefix with the old one [1]. What it costs depends on timing. While the cache is still warm, the summarisation request reads your prefix from cache and spends most of its money generating the summary. After a break longer than the cache lifetime there is nothing left to read, so it reprocesses the full history as uncached input, which is why /compact is at its most expensive on a session you resumed [1].

Cache lifetime is what turns a break into a rebuild, so it is worth knowing which one you have. On a Claude subscription, within your plan’s included usage, the main conversation gets a one-hour TTL. On usage credits, an API key or a cloud provider it drops to five minutes [1]. You can set it yourself with the promptCacheTtl setting or the CLAUDE_CODE_PROMPT_CACHE_TTL environment variable, both of which accept 5m or 1h [1].

What actually lowers the bill

The moves that work either keep content out of the prefix in the first place or start a new prefix at a moment you chose. /clear between unrelated tasks does the second and costs nothing, where /compact has to read the conversation it summarises [2]. Running /compact at a natural break rather than letting auto-compaction fire mid-task at least puts the rebuild where you can afford it [1].

Keeping content out is cheaper than removing it later. Anthropic suggests holding CLAUDE.md under 200 lines and moving workflow-specific instructions into skills, which load on demand and inject as user messages instead of riding in the cached prefix through every unrelated turn [1][2]. MCP tool definitions are deferred by default, so only names and server instructions enter context until a tool is actually used, and CLI tools such as gh or aws add no per-tool listing at all [2]. A PreToolUse hook that greps a log for ERROR before Claude ever sees it turns tens of thousands of tokens into hundreds [2]. Subagents keep verbose output in their own context and return only a summary, though a subagent builds its own prefix, warms its own cache, and falls outside the main conversation’s TTL bucket [1][2].

Model and effort level are the largest single levers, and they are the same lever twice. Sonnet handles most coding tasks and costs less than Opus [2]. Extended thinking is billed as output tokens and its default budget can run to tens of thousands per request, so lowering effort on simple work is a direct cut [2]. Both belong at the top of a session, because changing either mid-task is a rebuild [1]. Agent teams run the other way: they use roughly seven times the tokens of a standard session when teammates run in plan mode, because each teammate carries its own context window [2].

Measure billed cost per finished task, not tokens

Every API response reports the two numbers that settle this for your own workload. cache_creation_input_tokens is what you wrote to the cache this turn, billed at the write rate. cache_read_input_tokens is what you read back, billed at roughly 10% of the standard input rate [1]. A high read-to-creation ratio means caching is doing its job. Creation staying high turn after turn means something in your prefix keeps changing [1].

Claude Code surfaces the same thing in /usage as a prompt cache line covering the request count, the share of input tokens served from cache, the miss count, and whether the cache is warm right now with the TTL in effect [2]. It counts a request as a miss when it reprocessed more than 5% and at least 2,000 tokens of what it could have read from cache [2]. On a paid plan, the usage breakdown flags any behaviour that accounts for 10% or more of recent usage, cache misses included [2]. To confirm which TTL your writes actually used, run claude -p "hello" --output-format json and read usage.cache_creation, where one-hour writes appear under ephemeral_1h_input_tokens [1].

None of those numbers is the answer on its own. The number to compare before and after is billed cost divided by tasks that actually finished, which is what Weinberger and Hozez recommend when they argue for evaluating optimisation at the level of “cost per successful task, including cache behavior, trajectory changes, and correctness rather than token counts alone” [7]. A setting that saves 20% and quietly turns one task in six into a retry has not saved you anything; it has moved the cost somewhere your dashboard does not show it.

The rule is not specific to one vendor. Google’s guidance for Gemini implicit caching is the same prefix logic from the other side: put large and common content at the beginning of your prompt, and send requests with a similar prefix in a short amount of time [8]. The thresholds differ, at 4,096 tokens on Gemini 3.8 Flash and 2,048 on Gemini 2.5 Flash and Pro [8], but the advice is identical because the mechanism is.

What still goes wrong

The prices above are list prices, and Claude Code’s own cost figure is an estimate it computes locally from token counts at list price, unless an administrator has set a modelPricing table to your contracted rates [2]. On a Teams or Enterprise plan, usage inside the seat allowance is not metered in dollars at all, so the arithmetic here tells you about your plan limits rather than an invoice [2]. Treat the calculator as a way to rank two options, not as a forecast.

Caching also behaves differently once your requests stop going straight to the provider. Through an LLM gateway or a custom base URL, what stays cached depends on how the gateway handles the cache markers Claude Code sends; a gateway that removes them while still returning success means your entire conversation bills as uncached input on every single turn, with nothing on screen to say so [1]. On Amazon Bedrock, caching support, minimum cacheable prefix length and one-hour TTL availability all vary by model, and cache token counts stuck at zero are the symptom [1].

Finally, none of this makes a large context free. A cache read is cheap, not costless, and a 200,000-token prefix read on every turn of a long session is still real money even at a tenth of the input rate. The honest version of the advice is that context you genuinely no longer need should go, ideally by never entering the prefix, and context you might need should stay put. The break-even arithmetic also assumes a trim does not change what the agent does, and the study above found that it did [7], which is the part no calculator will catch for you.