← Claude Code Hub
✦ Tip #179 Aug 28, 2026

When to compact in Claude Code: before you step away, not when you get back

/compact doesn't cost the same at 12:55 as it does at 2:30. Same command, same conversation, and the price between them is ten times apart. What changed isn't the summary: it's whether your cache is still alive.

Two cost bars compared: /compact before the break reads the history from cache at a tenth of the price; /compact on the way back reprocesses the whole history at full price

TL;DR To summarize your conversation, Claude Code sends a separate request that carries all of it. With a warm cache it reads that at roughly 10% of the input price; an hour after you walk away there is no cache and it reprocesses at 100%. Compact before the break rather than after, and what goes cold over lunch is a two-thousand-token summary instead of a hundred thousand.

You get back from lunch, type "pick up where we left off", and the cursor just sits there. Ten seconds, fifteen. The answer does arrive and it is correct, but that single turn burned more than the entire hour of work before the break. Claude did not get slower. Your cache died while you were eating, and that first message paid to rebuild the whole conversation.

There is a fix, and it is not a setting or an environment variable. It is a decision about when to compact, and it is eight characters typed thirty seconds before you stand up.

Why /compact doesn't always cost the same

Compacting looks like a local operation, as if Claude Code trimmed the text on its own. It isn't. To write the summary it sends a separate request carrying your system prompt, your tools and your entire conversation, with a summarization instruction stapled to the end. You pay for the summary by reading everything you want summarized.

That is where the cache comes in. Claude Code caches the prefix of every request, and a cached read bills at roughly 10% of the input price. With the session still warm, that summarization request reads your history from cache and the only thing you pay in full is generating the summary. After a long break the cache has expired: there is nothing left to read, and the same request reprocesses the full history as fresh input.

Same command, same conversation, same summary. What changed is the clock.

Here is the difference in the two counters the API returns on every response:

# /compact typed before you go to lunch (warm cache)
cache_read_input_tokens:      94,220   ← your history, at ~10% of input
cache_creation_input_tokens:     380   ← only the new summary

# /compact typed on your way back, ninety minutes later (expired cache)
cache_read_input_tokens:           0   ← zero hits
cache_creation_input_tokens:  94,600   ← the same history, at full price

And there is a second half that rarely gets said out loud. Compacting before you leave does not spare you the rebuild when you return: the first message after a long break always rebuilds the cache. What changes is what it rebuilds. Walk away with the whole conversation on your back and you come back rebuilding a hundred thousand tokens. Walk away compacted and you come back rebuilding a summary. That is the actual payoff, and it is two things at once: the summary costs you a tenth, and the turn you return to stops dragging.

The three moments

1. Before you stand up: compact with instructions

Don't leave it at a bare /compact. Say what matters to you, because the summary is written by a model that has no idea which of the forty things in this session is the one you are coming back to:

/compact focus on the auth/ migration and the two tests still failing

Even so, not everything survives the trip: what makes it through a /compact and what disappears without warning is the fine print on this move.

And if what you're doing next is a different task altogether, this isn't for you. The compact vs clear question settles itself: /clear when you're abandoning the thread, /compact when you want to stay in it. Knowing when to compact only matters if you're coming back to the same conversation.

2. Check how much room you actually have

The hour is not universal. It is the best case, and one throwaway call tells you which one you're on:

claude -p "hi" --output-format json

Look for the usage.cache_creation block in the response:

"cache_creation": {
  "ephemeral_1h_input_tokens": 17743,
  "ephemeral_5m_input_tokens": 0
}

If the weight sits in ephemeral_1h_input_tokens, your main conversation survives an hour of silence. If it sits in ephemeral_5m_input_tokens, it survives five minutes, and your "break" is walking to the kitchen for water.

3. On the way back, you get your bearings

The summary hands the context back to Claude. It doesn't hand your head back to you. /recap tells you where you were without touching the cache, because it appends the summary as command output instead of replacing your history.

Who compacts if you don't

Somebody is compacting that conversation either way. Once the context fills up, auto-compact fires and picks the moment by how full the window is. It's a good system and it deserves to be left alone, but it measures fullness, not clocks: it doesn't know you're going to lunch and has no way to find out.

Compacting before the break is the one version of this you choose, and it's the version you can steer with instructions on top.

Reference: how long your cache lives

Every cache hit resets the timer, so the cache holds as long as you keep working. The TTL only starts counting when you stop.

Requests Claude subscription, within plan usage Usage credits, API key or cloud provider
Main conversation One hour Five minutes
Everything else: subagents, workflows, forks and compaction itself Five minutes Five minutes

Two details that catch nearly everyone out. First: the moment you go past your plan's included usage and start drawing on usage credits, your main conversation drops itself to five minutes, because from there on you're billed for it. Second: the request that generates the summary lives in the bottom row, so it inherits five minutes even when you have an hour.

You can pin either row yourself. promptCacheTtl (or the CLAUDE_CODE_PROMPT_CACHE_TTL variable) governs the main conversation, and subagentPromptCacheTtl (or CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL) governs everything else. Both take 5m or 1h and nothing else:

{
  "promptCacheTtl": "1h"
}

This is a habit about timing, not a setting, which puts it right next to the others: 10 habits to save tokens works on the size of your context, and this one works on when you pay for it.

Official docs: How Claude Code uses prompt caching

Requirements: promptCacheTtl, subagentPromptCacheTtl and their two environment variables need Claude Code v2.1.242 or later. The one-hour TTL is not available through the Claude apps gateway, and on Amazon Bedrock it depends on the model and region.

Workshop for teams

Multiply your team's output without sacrificing quality: a 6 to 8 hour AI First workshop, online, on the Claude platform.

See the workshop
Free guide

The 51 essentials, as a PDF.

One page per tip. Five chapters. What I actually use daily in production — no theory, no fluff.

  • I. Getting started 10 tips
  • II. Awareness 3 tips
  • III. Mastery 22 tips
  • IV. Autonomy 10 tips
  • V. Comparison 6 tips
Are you a professional Web developer?

You'll receive the guide by email · You join the Gravitas newsletter · Unsubscribe anytime

of 51
#

Wmedia · 51 Tips
Free guide · 51 tips · 5 chapters

The 51 essentials, as a PDF.

Are you a professional Web developer? · Unsubscribe anytime