How to Save Claude Tokens With Prompt Caching

TL;DR

Cached tokens cost only 10% of normal input, so maintaining cache hits can greatly reduce token usage during long Claude sessions. Keep sessions active within the relevant time-to-live window, avoid switching models unnecessarily, and start a clean session with a detailed handoff when changing tasks or returning after a long pause.

Transcript

So look at this. On this day, I saved 91 million tokens because of cash read. And in the past week, I've saved over 300 million tokens because of it. Now, don't freak out. This isn't anything that you have to go change. This is happening automatically if you are using Claude Code or Claude. And I know that the concept of prompt caching might seem a... Read More

Key Insights

• Cached tokens cost 10% of normal input, allowing previously processed instructions, files, and conversation history to be reused much more cheaply. The cited dashboard example recorded 91 million cache-read tokens in one day, which cost roughly the equivalent of processing 9 million normal input tokens.
• A cache creation is the first-time writing of information into the cache, and it carries a one-time cost. A cache read occurs when Claude reuses that stored material on a later turn, making continued conversation substantially cheaper while the cached prefix remains available.
• Claude Code builds its cache across several layers, including global system instructions and tool definitions, project-specific context such as CLAUDE.md, memory and rules, and the growing conversation. On each timely follow-up turn, Claude can reuse the established prefix and process only the newly added reply and message.
• Claude Code subscription sessions have a one-hour cache window according to the transcript. If a session remains untouched for an hour and then receives another message, its context is no longer cached, so the next request must process the accumulated session again at the normal input cost.
• API usage and subagents have a five-minute default time-to-live according to the transcript. The API cache duration can be increased to one hour for an additional cost, but managing several sessions under the five-minute default can produce repeated full reads when pauses exceed that short window.
• Model switching breaks cache reuse because each model maintains its own cache. Even when the conversation context remains identical, the next request after a model change reads the full history without cache hits because the cached prefix associated with the previous model cannot be reused.
• The Opus Plan setting can reset the cache when it uses Opus for planning and Sonnet for execution. Each transition between plan mode and execution becomes a model switch, so repeatedly toggling between them can require fresh cache creation despite preserving the same conversation history.
• A session handoff can preserve continuity while allowing a clean restart. The demonstrated workflow summarizes completed work, important files, open decisions, and the next steps, then copies that summary, clears the old session, and pastes it into a new one as compact starting context.

Questions & Answers

Q: How does Claude prompt caching reduce token costs?

Claude prompt caching reduces costs by reusing context that has already been processed. Cached tokens cost only 10% of normal input according to the transcript. When system instructions, project context, files, messages, and replies remain cached, Claude reads that stored prefix cheaply and processes only the newly added conversation content at the normal rate.

Q: How long does the Claude Code cache remain active?

Claude Code used through a subscription has a one-hour cache window according to the transcript. Sending another message within that window allows the existing context to remain available for cache reads. If the session sits untouched for an hour or longer, the next message causes the accumulated context to be fully read again rather than reused from the previous cache.

Q: What is the cache time-to-live for Claude API usage?

Claude API usage has a five-minute default cache time-to-live according to the transcript. The duration can be increased to one hour, but doing so is described as more expensive. The short default matters when managing several sessions because allowing more than five minutes to pass can force the next request to process the entire context again.

Q: What is the difference between cache creation and cache reading?

Cache creation means writing information into Claude's cache for the first time, which produces a one-time cost and can benefit the following turn. Cache reading means reusing those stored tokens, such as system instructions, CLAUDE.md content, files, or conversation history. Cache reads are described as 10 times cheaper than processing the same material as fresh input.

Q: What actions break Claude's prompt cache?

Waiting beyond the applicable cache window, changing the system prompt, and switching models can break cache reuse according to the transcript. These changes prevent the next request from matching the same cached prefix. In a long conversation, that means Claude may need to read the complete accumulated history again instead of cheaply reusing the earlier cached context.

Q: Why does switching Claude models increase token usage?

Each Claude model has its own cache, so switching models prevents the new model from using the previous model's cached conversation. The next request then reads the full history without cache hits, even if the visible context is unchanged. The Opus Plan setting can cause this behavior by using Opus during planning and Sonnet during execution.

Q: How can a session handoff preserve context while saving tokens?

A session handoff creates a compact summary of completed work, important files, unresolved decisions, and the exact place where work should resume. The demonstrated process copies that summary, clears the existing session, and pastes it into a new session. This preserves the information needed to continue while avoiding the full token weight of an oversized conversation history.

Q: What habits help prevent Claude sessions from wasting tokens?

Keep an active session within its cache time-to-live, keep each session focused on one task, and start fresh when switching tasks. After a pause longer than the cache window, transfer the essential context into a new session rather than continuing a very large uncached history. Avoid unnecessary model changes because each model uses a separate cache.

Summary & Key Takeaways

• Prompt caching lets Claude reuse previously processed context instead of fully processing it again on every turn. Cache reads cost 10% of normal input, while cache creation is a one-time write cost. As a conversation grows, earlier system instructions, project context, messages, and replies can remain cached while only new material requires full processing.

• Cache lifetime depends on how Claude is being used. Claude Code through a subscription has a one-hour cache window, while API usage and subagents default to five minutes. The API window can be increased to one hour at a higher cost. After expiration, the conversation context must be fully read again on the next request.

• Practical token-saving habits include keeping active sessions within the cache window, starting fresh when changing tasks, and transferring essential context through a session handoff. Switching models also resets reuse because each model has its own cache. Large documents in Claude Chat may be better organized within projects, although the exact web caching behavior is undocumented here.