This is the version to keep within reach. Open it while you're working with Claude when you want to check quickly how the cache works and whether your current usage is burning through the session limit. Caching happens automatically — there's nothing to turn on; this cheat sheet just collects the rules that decide how fast you approach the limit.
The gist in one sentence: cached context costs 10% of the price of fresh input, lives for an hour on a subscription plan, and gets reset by a long break, a change to the system instructions, or switching models mid-session.
Two concepts to start with
| Concept | What it is |
|---|---|
| Token | A chunk of text the model works with — roughly a piece of a word. Counted for input (what you send) and output (what the model returns). |
| Cache | The mechanism that keeps Claude from reprocessing the same text from scratch — instructions, files, earlier conversation. A fragment remembered once is simply read back on the next question. |
Price and cache lifetime
- Cached tokens cost 10% of the price of regular input. Reading remembered context is ten times cheaper than fresh input.
- Example from the source material: if 91 million tokens pass through the model in a day and most of them are read from cache, the cost works out as if you'd processed roughly 9 million.
- The cache doesn't last forever — it has a lifetime (Anthropic's docs call it TTL, time to live).
| Mode | Cache lifetime (TTL) | Notes |
|---|---|---|
| Claude subscription (e.g. Claude Code in the terminal or as an extension) | 1 hour | No message for an hour → the whole session falls out of cache and gets reprocessed from scratch. |
| Working through the API | 5 minutes | The window can't be shortened; it can be extended to an hour for an extra fee. |
| Sub-agents | 5 minutes | Regardless of plan. |
| Web app (Claude.ai) | not clearly documented | Anthropic's docs don't specify; it's reasonable to assume it behaves like the subscription, but there's no full confirmation. |
Where the old confusion came from: the subscription wasn't quietly shortened from an hour to 5 minutes — it's still an hour. The mix-up came from API rules and Claude Code rules sometimes being described together, even though they're two different things.
Three cache layers
The context Claude remembers splits into three layers:
| Layer | What it covers | How it's cached |
|---|---|---|
| System | The base instructions, tool definitions (reading and writing files, running commands, search), response style | Globally |
| Project | Files like CLAUDE.md, memory and rules for that project | Separately per project |
| Conversation | Your messages and the model's replies | Grows with every turn, appended as you go — that's by design |
Write and read
- Cache write (cache create) — the one-time cost of remembering something for the first time; it pays for itself as early as the next turn.
- Cache read (cache read) — reusing what's already remembered; this is the part that's ten times cheaper than fresh input.
In the first turn nothing is remembered yet — the model processes everything from scratch and writes it to cache. In later turns (within the hour window) the base is already there, so only the fresh part gets added, and the rest is read back cheaply.
What resets the cache
Three things flush the remembered context and force it to be reprocessed from scratch:
| Event | Detail |
|---|---|
| A break longer than the TTL | Over an hour on a subscription; over 5 minutes on the API and for sub-agents |
| A change to the system instructions | Changes what the whole session is built on |
| Switching models mid-session | Each model has its own cache; after a switch, the next request reads the entire conversation with no cache hit, even if the content is identical |
What does not reset the cache:
- Editing the
CLAUDE.mdfile during a session — the change only takes effect once the session restarts, so the current cache stays intact.
The catch with switching models: the "Opus for planning" setup (Opus in plan mode, then Sonnet for execution) gets recommended as a way to save the limit. But every such switch is a model change — so it resets the cache and triggers fresh processing. Over the long run the setup can still save the limit overall, but the switching itself isn't free.
Three habits
| Habit | What to do | How |
|---|---|---|
| Keep the session live | Don't leave a long gap | If a session has sat idle for over an hour, don't go back to it — hand the work off to a new one. Returning to it means the whole thing gets reprocessed anyway. |
| Focused session → fresh start | Start clean when you change topic | /clear clears the session; /compact summarizes it and resets the cache along the way. Alternative: a "handoff" — a short summary (what's done, which files came out of it, where to pick up) that you copy into a new, clean session. |
| Large documents in a project | In the Claude web chat, put large materials in a project | If you're using the web app, instead of pasting large materials straight into the conversation, set up a project. Files in a project are cached in a way that's better suited to handling multiple documents. (Not spelled out explicitly in the docs — a reasonable tip, not a hard rule.) |
Commands and files — quick reference
| Item | What it does |
|---|---|
/clear | Clears the session |
/compact | Summarizes the session — and resets the cache along the way |
CLAUDE.md | The project-layer file; editing it during a session doesn't reset the cache (takes effect after a session restart) |
Where to start
The three habits cover what the large majority of users need. If you're only going to implement one thing, start here:
- Keep the session live. Don't leave it for more than an hour (on a subscription) — hand the work off to a new session if needed.
- Make a fresh start when you switch tasks.
/clear, or hand the session off into a new, clean conversation. - Put large documents in a project, not straight into the conversation.
Read up on the rest of the caching nuances once you actually need them.