# Cache hits die mid-conversation: the lookback window
## Symptom
Early turns in a conversation show cache reads; later turns revert to full writes even though the prefix is unchanged and `cache_control` is still on the final block.
## Confirm the cause
Count blocks. The system checks at most 20 positions backward from each breakpoint, counting the breakpoint itself as the first. If your breakpoint has moved 20 or more blocks past where the last entry was written, checking stops and you get no hit. Runs of consecutive `tool_use` blocks and runs of consecutive `tool_result` blocks each count as one position, so a busy tool turn alone does not push you out.
## Fix
1. Add a second explicit breakpoint at or near the position of the earlier write. Each breakpoint starts its own 20-position lookback window.
2. You get up to 4 breakpoints; spending two on a long conversation is what they are for.
3. For new conversations, prefer automatic caching (one top-level `cache_control`), which moves the breakpoint forward each turn and keeps the window fresh.
## Verify
After adding the earlier breakpoint, the next request shows `cache_read_input_tokens` nonzero again. Watch it across several turns: hits should persist instead of decaying.