# Prompt caching and what a long session costs Claude Code is fast and affordable in long sessions because the unchanged start of each request is cached. A few ordinary actions break that cache, and knowing them is most of cost control. ## The prefix is what gets cached Every turn, the whole conversation is sent again. That would be ruinous if the model had to process all of it from scratch each time. It does not, because the API caches by **exact prefix match**: if the start of the request is identical to the last one, that part is read from the cache instead of recomputed. The order of a request matters for exactly this reason: ```flow System prompt and tool definitions Project context: CLAUDE.md, memory, unscoped rules The conversation, growing ``` A change high in this stack recomputes everything below it. A change at the bottom costs almost nothing. The whole craft of cheap long sessions is to keep the top still and let only the bottom move. ## How long the cache lives The cache has a lifetime. The main conversation gets one hour only on a Claude subscription, within plan usage. With an API key, cloud providers or usage credits it gets five minutes. Subagents, workflows, compaction and titles get five minutes by default. If you step away longer than the lifetime, the next turn rebuilds the prefix. A session that grew past about 200K tokens while on the one-hour cache is even compacted shortly before the cache would expire. That is called idle compaction, and `idleCompaction: false` turns it off. **Question:** Why does a change to something near the start of the request cost more than one near the end? - The start is billed at a higher rate - Caching matches an exact prefix, so everything after the change is recomputed - The end is never cached - The model reads the start twice **Answer:** Caching matches an exact prefix, so everything after the change is recomputed. A prefix cache can only reuse the part that is identical from the beginning. Change something early and all that follows no longer matches. ## What breaks the cache Most of these are things you do for good reasons. - **Switching models.** Each model has its own cache, so a switch invalidates all of it. The CLI asks for confirmation only while the cache is still warm. - **`opusplan`.** It uses one model to plan and another to execute, so every plan-mode toggle is a model switch. - **Changing effort,** on most models. On Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 it keeps the cache. - **Turning on fast mode.** It has a separate cache. The first time, the whole conversation is read uncached, at fast rates. - **Editing a tool list** when tool search is unavailable. With tool search on, which is the default, MCP servers connecting or disconnecting do not disturb it. And what does not: plugin skills, commands, agents and hooks append after the conversation, so they never invalidate it. > **Choose once, at the start** The guide's advice is short. Pick the model and effort at the start of a session and do not switch mid-task. If you want fast mode, turn it on at the start too. And prefer `/rewind` to abandoning a path, because it returns to a prefix that is already cached, unlike compaction. ## Where caching quietly fails Two cases are worth knowing because they leave no error. A gateway that strips the `cache_control` markers but returns success makes your whole history bill as uncached on every turn. And the cache is effectively tied to one machine and directory, since the system prompt embeds memory paths and the opening message embeds the working directory. Two sessions in the same directory can share a cache. ```terminal $ /usage * Shows a "Prompt cache (main)" line: hit ratio, misses, warm or cold # Newer versions name a likely cause for a miss. ``` ## What a long session really costs The documented figures are an average, not a promise. Across enterprise users the average is about 13 USD per developer per active day, 150 to 250 USD per month, and 90 percent of users stay under 30 USD a day. Agent teams use roughly seven times the tokens of a standard session when teammates run in plan mode. Two costs people forget. Thinking tokens bill as output. And some spending happens while you are not typing: session recaps, idle compaction, prompt suggestions (mostly cache reads), scheduled loops and goal check-ins. **Question:** You are halfway through a task and want to try fast mode. What is the documented cost? - Nothing, the cache is shared - Fast mode has a separate cache, so the first enable reads the whole conversation uncached - The session restarts from scratch - Only the next prompt is affected **Answer:** Fast mode has a separate cache, so the first enable reads the whole conversation uncached. Fast mode is not a different model, but it has its own cache. Turning it on mid-session pays for the whole conversation once at fast rates. > **Read your own cache** Run `/usage` after a long stretch of work and find the prompt cache line. Then switch models once on purpose, and run it again. The difference is the lesson.