Prompt Caching vs Token Compression: Which Cuts More?

Part of: Reduce AI Coding Agent Token Usage. The how-to for caching itself lives in Prompt Caching: How to Cut Your Input Bill; this page is the comparison.

Prompt caching vs token compression in one sentence

Caching makes each token cheaper to re-read; compression makes there be fewer tokens to read — so they are not rivals, and you want both. The only real conflict between them is a badly placed compressor that rewrites content already in the cache, which turns a discount into a surcharge.

Provider prices and cache rules below were read on Anthropic's and OpenAI's documentation on 2026-10-15. The only Tokenade figure on this page comes from the THOL benchmark, method on the methodology page.

How I compared them

I looked at what each lever does to one line of a real agent bill, not at headline percentages. An agent session has four input lines: cache writes, cache reads, uncached input, and output.

I build a token optimizer, so I have a side. The caching numbers here are the providers' published rates, attributed and dated. The arithmetic examples are illustrative, with the inputs shown so you can redo them with your own logs.

What does prompt caching actually reduce?

It reduces the unit price of tokens the provider has already seen, and nothing else. The provider stores a tokenized prefix of your request; the next request that starts with the same bytes reads that prefix at a discount.

According to Anthropic's prompt caching docs (read 2026-10-15), the rates on Claude Opus 5.5 are:

• Base input: $4 per million tokens (MTok).
• 5-minute cache write: $5/MTok, which is 1.25x input.
• 1-hour cache write: $8/MTok, which is 2x input.
• Cache hit: $0.20/MTok, which is 0.05x input. Anthropic lists 0.1x as the standard multiplier for most other models.

OpenAI's prompt caching guide (read 2026-10-15) now splits by generation. From GPT-5.6 onwards, it bills cache writes at 1.25x the uncached input rate and reads at 0.1x on most models. GPT-5.5 has no write surcharge. Lifetime is at least 30 minutes on GPT-5.6+, against a 5-minute default on Claude, refreshed on each hit.

What caching does not touch matters just as much:

• New tokens. A tool result entering the conversation for the first time is billed in full, as a cache write.
• Output. Generation is always billed at the output rate.
• The context window. A cached token still occupies a slot in the window. 150,000 cached tokens are 150,000 tokens of context.
• Cold starts. When the TTL expires, the whole prefix is written again at the write rate.

What does token compression reduce?

It reduces the number of tokens that enter the conversation in the first place. On an AI coding agent, that inbound volume is dominated by three sources the model never needed in full.

• Command output. A test run, a build, a git log: thousands of lines, of which the model needs the failures. That is output filtering.
• File reads. The agent opens a 2,000-line file to change four lines. Structure-first reads and semantic search return the part it asked about.
• MCP manifests. Every connected server's tool definitions ride along on every turn, used or not.

Compression works on a different axis from caching. It does not care whether a token is cached; it decides whether that token exists. Every token it removes is a token that is never written to cache, never re-read, and never takes room in the window.

Why caching alone leaves the real cost in place

Because the cache discounts the re-reads but still multiplies them: every token you let in is paid once at the write rate, then once per turn until the session ends or compacts. Here is one test log, followed through a session on Opus 5.5.

Illustrative inputs: a 12,000-token test log arrives at turn 10 of a 50-turn session, the cache stays warm, prices as above.

Caching does the heavy lifting on the first step; nobody should skip it. But on the second step the bill for that log is still ten times what it needs to be, and the 12,000 tokens still sit in the context window on every one of those 40 turns.

That window cost is the part caching cannot reach. A fuller window means compaction comes sooner, and compaction rebuilds the conversation layer of the cache from scratch. A fat prefix also makes every cold start dearer: after an idle break, 150,000 tokens rewritten at $5/MTok is $0.75 before the agent has done anything.

So the order of operations is: cache whatever is stable, then stop letting in what never needed to be there. How the context window drives your token bill goes through the window side in more detail.

On the THOL benchmark, Tokenade cuts session cost by 39% on long sessions, against running no optimizer at all.

The trap: compression that breaks the cache prefix

Any compressor that rewrites content already sent to the model invalidates the cache from that point on, and you pay the write again on everything after it. The cache is a prefix match. One changed byte near the top and every token below it is a miss.

Anthropic's docs are explicit about the hierarchy: the cache is built in the order tools, then system, then messages, and a change at one level invalidates that level and every level after it. Modifying tool definitions — names, descriptions, parameters — invalidates the entire cache.

The compression moves that fall into this trap:

• Summarizing or pruning old tool results in place. It looks like a saving. It rewrites the middle of the history.
• Swapping MCP tool definitions mid-session. Adding, removing or compressing a tool description after the first request changes the top of the prefix.
• Re-compressing memory files or system instructions between turns. Same thing, one layer up.
• Injecting dynamic text near the top: timestamps, token counters, "savings so far" banners.

Put a number on the first one. Say you prune 20,000 tokens out of a 100,000-token cached history on Opus 5.5. The remaining 80,000 tokens must be written again: $0.40. Your saving is 20,000 fewer cached reads per turn: $0.004 per turn. It takes about 95 more turns to break even. Most sessions end, or compact, well before that.

Claude Code itself is built around this constraint. Its prompt caching documentation (read 2026-10-15) says it keeps the tool list from the conversation's first request for the whole conversation, and an MCP server that connects later supplies its tools as deferred definitions loaded on demand. The harness avoids touching the prefix; your optimizer should too.

The rule I hold Tokenade to is simple: compress on the way in, never rewrite on the way back. It compacts a tool result at the tool boundary, before that result becomes part of the conversation. Once a token is in the cached prefix, the cheapest thing to do with it is to leave it alone.

When is caching the lever, and when is compression?

Caching wins when the same large block is re-read many times; compression wins when large blocks keep arriving. Most agent sessions have both shapes, which is why the answer is usually both.

Caching does most of the work when:

• The prefix is big and stable: a long system prompt, fixed tool schemas, pinned docs.
• Calls come in quick bursts, inside the TTL.
• You control the request layout — see the how-to for that.

Compression does most of the work when:

• The agent runs commands with noisy output: tests, builds, installs, logs.
• It reads whole files to change a few lines.
• You have several MCP servers connected and use a few of their tools.
• Sessions are long enough that window pressure, not price per token, is what hurts.

Which one should you choose?

• API builder with a fixed system prompt and short calls: caching first; compression matters less.
• Claude Code, Codex or Cursor user on long sessions: both — caching is already on in the harness, so compression is the lever left to pull.
• Heavy MCP user: compression for the manifests, and check that nothing reloads tool definitions mid-session.
• Comparing optimizers: ask each one whether it ever rewrites content already sent. Best Claude Code token optimizers ranks the field on measured session cost.

FAQ

Does token compression break prompt caching?

Only if it rewrites content the model has already seen. Compressing a tool result before it enters the conversation is cache-safe: the compressed version is what gets cached. Summarizing old turns, editing tool definitions or re-compressing the system prompt mid-session changes the prefix and forces a new cache write on everything after the change.

If cache reads cost 0.05x to 0.1x, is compression still worth it?

Yes, for three reasons. Every new token is first billed as a cache write, at 1.25x input on Claude and on GPT-5.6+. Cached tokens are re-read on every later turn, so the discount is multiplied by the session length. And cached tokens still fill the context window, which brings compaction forward.

Does Claude Code already use prompt caching?

Yes, automatically. Its documentation says subscription users get a one-hour TTL on the main conversation within plan usage, and API-key users get five minutes. Since caching is already on, the remaining lever for most Claude Code users is the volume of what enters the context.

Does prompt caching reduce output tokens?

No. Caching only applies to input. Output is billed at the full output rate whatever the state of the cache, which is why neither caching nor input compression replaces keeping the model's answers short where that is acceptable.

See also

• Prompt Caching: How to Cut Your Input Bill — the how-to: layout, breakpoints, TTL.
• How the Context Window Drives Your Token Bill — why a cached window is still an expensive window.
• Claude Code /compact: What It Costs and What Survives — what compaction does to the cache.
• Output Filtering: Trim Command Logs for Agents — the biggest compression win on most sessions.
• Best Claude Code Token Optimizers — the ranked field.