Why does my first Claude Code message after a break use so much?

Claude Code keeps the cache for one hour or five minutes of inactivity, depending on how you sign in and which kind of request it is (Claude Code docs: prompt caching). Every request that hits the cache resets the timer, so the cache stays warm while you keep working. The lifetime counts from the start of the request that wrote or read the entry, so a response that streams for four minutes leaves about one minute on a five-minute cache (API docs: prompt caching).

You can choose the lifetime for each bucket, 5m or 1h, on Claude Code v2.1.242 or later (Claude Code docs: choose the TTL yourself):

• Main conversation: the promptCacheTtl setting, or the CLAUDE_CODE_PROMPT_CACHE_TTL environment variable.
• Subagents and other requests: the subagentPromptCacheTtl setting, or the CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL environment variable.
• FORCE_PROMPT_CACHING_5M=1 overrides both and forces five minutes, which helps when you compare the two.

{
  "promptCacheTtl": "1h"
}

To see which lifetime your main conversation's cache writes used, run claude -p "hello" --output-format json and read usage.cache_creation: one-hour writes are counted under ephemeral_1h_input_tokens and five-minute writes under ephemeral_5m_input_tokens (Claude Code docs).

The longer lifetime costs more to write. On the API a one-hour cache write is priced at 2 times the base input price and a five-minute write at 1.25 times (API docs: pricing). One hour pays off when you leave a session idle and come back, and costs more on short bursts that never idle past five minutes (Claude Code docs: cache lifetime). If your requests go through an LLM gateway set with ANTHROPIC_BASE_URL, the docs say the gateway must forward the anthropic-beta header unchanged for the one-hour lifetime to apply (Claude Code docs).

Take a 300k-token conversation on Claude Opus 5.5 at list prices (Anthropic pricing). Reading it from the cache costs about $0.06. Writing it again after a miss costs about $1.50 on a five-minute cache and $2.40 on a one-hour cache, 25 to 40 times the read for the same message. Anthropic does not publish how a plan's meter weighs cached against uncached tokens, so on a subscription the number of tokens reprocessed is the measure to watch.

The cache matches the start of each request exactly, so any change early in the request reprocesses everything after it. Anthropic's docs list these actions as invalidating part or all of the cache (Claude Code docs: actions that invalidate the cache):

• Switching models with /model. Each model has its own cache. A plan-mode toggle under opusplan, a skill whose frontmatter names another model, and an automatic model fallback are model switches too.
• Changing the effort level, on most models. On Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 with an API key or a Claude subscription, the cache stays intact.
• Turning on fast mode, once per conversation. Turning it off and on again later keeps the cache.
• Connecting or removing an MCP server, or enabling or disabling a plugin that provides one, when tools are loaded upfront. With tool search, the default on supported models, the tool list stays fixed and the cache survives.
• Denying an entire tool when tool search is off.
• Compacting the conversation, which replaces the history with a summary.
• Accumulating many images, once Claude Code removes the oldest batch to stay under the request limits.
• Upgrading Claude Code. The first conversation after an upgrade builds its cache from the top.

Some actions keep the cache: editing files in the repository, changing permission mode or output style, invoking skills and commands, /recap, /rewind and spawning a subagent. Editing CLAUDE.md mid-session also keeps it, because the edit does not reach the running session until /clear, /compact or a restart (Claude Code docs: actions that keep the cache). The cache is also scoped to one machine and directory, so sessions in different directories do not read each other's cache (Claude Code docs: cache scope).

After the main conversation's first response, /usage shows a Prompt cache (main) line in its Session block, on Claude Code v2.1.251 or later (Claude Code docs: prompt cache statistics). It reads:

• Requests: how many requests the main conversation sent.
• Share from cache: the share of input tokens served from the cache.
• Misses: requests that reprocessed content the cache already held, with when the last one happened and how many tokens were written back. From v2.1.260 it names a likely cause when Claude Code can tell, such as tool definitions changing.
• Expected rebuilds: misses Claude Code caused on purpose by compacting or clearing old tool results. This part appears only after one has happened.
• Warm or cold: whether the cache is still within its lifetime, with the lifetime in effect, and how long the session has been idle when it is cold.

The line covers the main conversation only, not subagents, and /clear resets it. A status line script can read the same numbers from the prompt_cache object, and cache_creation_input_tokens against cache_read_input_tokens per turn shows the same thing live: if creation stays high turn after turn, something early in the request keeps changing (Claude Code docs: check cache performance). On a Pro, Max, Team or Enterprise plan, /usage also recommends a change for behaviours behind 10% or more of your recent usage, such as long context or cache misses (Claude Code docs). The other causes are in why Claude Code usage runs out so fast.

After a break longer than the lifetime the cache is gone, so pick the cheapest way back for what you need next:

1. If you do not need the history, run /clear. Anthropic's docs say /clear costs nothing (Claude Code docs). Run /rename first so you can return with /resume (Claude Code docs: manage context).
2. If you want a summary, know that /compact on a cold cache reprocesses the whole history as uncached input, which is why it costs the most when you resume an old session (Claude Code docs: compacting). Next time, run it before you step away, while the cache is warm. What the summary keeps and drops is in what Claude Code forgets when it compacts.
3. If you went down a path you want to drop, use /rewind to an earlier turn. The next request carries the shorter history. Mid-session that prefix is still warm, because later turns read through it. After a break it has expired too, so only the shorter length saves anything (Claude Code docs: rewinding).
4. Each model has its own cache, so a switch rebuilds it (Claude Code docs: switching models). If you mean to switch, do it on the first turn back, while the cache is cold anyway, so it is rebuilt once.

Resuming with claude --resume sends the whole conversation again and reads from the cache whatever part is unchanged and still within its lifetime (Claude Code docs: resuming a session). If you leave a long conversation idle in a terminal on the one-hour lifetime, Claude Code can compact it shortly before the cache expires. Setting idleCompaction to false turns that off, on v2.1.290 or later (Claude Code docs: compacting).

One report is open as of 23 October 2026. Issue #101685, opened on 13 October, says interactive sessions on Team and Max seats requested the one-hour cache but wrote five-minute entries, while claude -p on the same account wrote one-hour entries. Reports in the thread cover versions 2.1.296 to 2.1.304. It has no reply from Anthropic yet. The workaround in the thread is to set promptCacheTtl to 1h explicitly, which several commenters say gave them one-hour writes. An earlier report from April, issue #46829, was closed as not planned after the Claude Code team replied that the client picks the lifetime per request. Replies in that thread attribute some unexpected five-minute fallbacks to client bugs fixed in v2.1.90 and v2.1.106.