↔️ Two different axes
Cache optimizes the price per token of the context. Compact optimizes how many tokens you carry. These are two axes that don’t compete in the same place — and that’s why you want both.
Compact = summarize the history into a shorter version; in Claude Code, the command is /compact. It doesn't change the price per token; it changes the size of what you resend.
Legend: the cache only goes down (price); compaction only moves left (quantity). One doesn't do the other's job.
Changes the price per token
Changes the number of tokens
Summarize the history in Claude Code
Orthogonal axes, not rivals
💰 A large cached context is still expensive
The cache discount is misleading. The cache makes per token, but 400k tokens read at 0,1× still equal ~40k of full input per turn — and that every turn, while the context remains this large.
The calculation that scares you
400,000 tokens × 0.1× = 40,000 full-input-equivalent tokens, paid for every message. A high hit rate (99%) doesn’t change that: the volume is large.
× every turn of the conversation = a sum that keeps growing
Legend: one tenth of a lot is still a lot. Caching lowers the cost; it doesn't shrink the context.
Read the total, not the field
If input_tokens shows little, but the bill is high; most of it is in cache_read_input_tokens at 0.1×. It’s cheap per token, but the total prompt cost is the sum of the three fields.
The cache read factor
400k read every turn
The cost repeats; it doesn’t disappear
Cheap ≠ small
🧱 The context limit (1M)
Here the cache doesn’t help. It leaves 900k tokens cheap, but they still take up 900k of 1M. Eventually, you can't continue the conversation without compact or /clear. The limit is about quantity — and only compacting/clearing frees up space.
Legend: cheap ≠ small. The 1M limit counts occupied slots, not the price—only compact creates room.
The common mistake
Rely on the cache to “handle” a context that only keeps growing. It holds down the cost, not the size. Near the limit, the conversation gets stuck—and then it’s /compact or /clear, no more caching.
Maximum slots in the window
Caching doesn’t create space
Reduces occupancy
Resets when you don’t need the history
📉 Compaction numbers
Compacting replaces a single cold write with much lighter turns. Without compacting, you pay for the large context every message. By compacting, you pay for just one write, and all subsequent turns are cheap. See the side-by-side breakdown.
| Scenario | Initial cost (one time) | Cost per turn | Payback |
|---|---|---|---|
| Without compacting 400k in context |
— | 400k @ 0,1× ≈ 40k-equiv · forever | never improves |
| Compacting for 20k |
1 cold write 20k @ 1.25× ≈ 25k | 20k @ 0,1× ≈ 2k-equiv · per turn | ~1 turn |
Legend: the only cyan spike (turn 0) is the cold write from compaction; after that, each turn is ~20× lighter than the purple bar.
Practical tip
Think in terms of turns ahead: if many messages are still coming, the 25k cold write gets diluted to nothing compared with saving 38k per turn. If the conversation is ending now, the cold write isn't worth it.
20k @ 1.25× ≈ 25k, once
After compacting
Payback
Lighter per turn
🧠 Quality and latency
Compaction isn’t just about cost. Bloated context scatters attention of the model (the "context rot") — it makes more mistakes and rambles more. And even when read from the cache, 400k take longer than 20k for the first token (higher TTFT). Compacting improves accuracy e speed.
Legend: fewer tokens = concentrated attention + faster first token. Compression is a quality improvement, not just a cost saving.
✓ Compact context
- ✓Focused attention on what matters
- ✓Less "context rot," fewer errors
- ✓Faster first token (lower TTFT)
✗ Bloated context
- ✗Diluted attention, rambling responses
- ✗Errors from losing sight of what matters
- ✗Slower even when read from cache
Excessively scattered attention
Time to first token
Read, but still large
Precision + speed
🎯 When to compact / when NOT to
The guideline is simple. Short conversation → DO NOT compact: you only lose the warm cache without any benefit (that intuition is right). Large context, near the limit, or quality declining → compact: you trade one cold write for much lighter turns.
Legend: the branch green preserves the cache; the branch purple accepts 1 cold write to save on every subsequent turn.
✓ Compact when
- ✓The context is large, and many turns are still ahead
- ✓You’re close to the 1M limit
- ✓Quality has dropped / the model is stalling
✗ Don’t compact when
- ✗The conversation is short and the cache is already warm
- ✗Will end soon (there aren’t enough turns left to pay for the cold write)
- ✗By habit, without checking size or quality
Rule of thumb
Compact with the state (size, limit, quality), not by a clock. And remember: caching and compaction work together — after compaction, the new smaller context is also cached and becomes warm again.
Preserves the warm cache
Much lighter turns
Not out of habit
Compact is cached too
Module summary
/clear frees up space.Next module
3.2 — Cache-friendly architecture and auditing: design the prefix so it never invalidates by accident.