A 200K-Token Claude Session Left Idle Re-Buys Its Cache: $0.04 Becomes $1.00

• Book: Observability for LLM Applications
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

Ten minutes at the coffee machine can add $0.96 to the next message in a 200,000-token Claude Code session. The session has been open since the morning and has read half the repo. You step away, come back, and type one line: "thanks, now also rename the test file."

If you sign in with an API key and run Opus 5.5, the turn before your break read those 200K tokens from the prompt cache for about $0.04. Your one-line follow-up pays about $1.00 to write the same 200K tokens back into the cache, because the cache expired while you were gone.

Claude Code 2.1.314, out October 30, brought idle compaction to VS Code and the Desktop Code tab to dodge exactly this bill.

Three prices for the same token

Every Claude Code turn is a fresh API request that re-sends the whole conversation; as the prompt caching docs put it, "The model doesn't remember anything between requests." The API skips reprocessing the unchanged start of the request, the prefix, when it matches what it recently cached. So a token in your history is billed at one of three rates, depending on the cache's state when the request arrives. Anthropic's prompt caching page gives the multipliers:

• A cache write with the 5-minute TTL costs 1.25x the base input price.
• A cache write with the 1-hour TTL costs 2x.
• A cache read is 0.1x, with exceptions.

The exceptions matter for current models. The pricing page prices cache hits on Opus 5.5 and Sonnet 5.5 at 0.05x, and on Fable 5.1 at 0.025x. On those models the gap between a warm read and a cold write is wider still.

Each hit resets the timer, and the lifetime is "measured from the start of the request that writes or reads the cache entry." Work steadily and the cache stays warm all day. Step away past the TTL and the next request finds nothing, so it writes the whole prefix again at the write rate.

The math for one line at 200K tokens

These are list prices per million tokens from Anthropic's pricing page, multiplied by a 200,000-token prefix. Input side only: your new message and Claude's reply cost the same either way.

On Opus 5.5 the cold turn costs 25 times the warm one on the 5-minute TTL, and 40 times on the 1-hour TTL. On Fable 5.1 it is 50 and 80 times. There is no long-context surcharge hiding on top: the pricing page says Claude 4.6 and later models, except Haiku 5.5, bill the full 1M window "at standard pricing."

Which column applies to you depends on how you pay. Claude Code's docs say it requests the one-hour TTL for the main conversation only on a Claude subscription within your plan's included usage. With an API key, usage credits or a cloud provider, the default is five minutes. That means the coffee break above is enough.

On a subscription you don't see dollars. You see plan usage, and a cold 200K rewrite draws on it the same way. Since a fix in 2.1.311, /usage lists large prompt-cache misses under "What's contributing to your limits usage?".

If you run on an API key and take breaks, the one-hour TTL can be the cheaper choice. A session that grew to 200K tokens by appending turns wrote roughly 200K tokens to the cache over its life, one exchange at a time. Under that assumption, paying the 1-hour rate instead of the 5-minute rate on those writes costs about 200K × ($8 − $5) per million, or $0.60 on Opus 5.5. One break of between five minutes and an hour then costs a $0.04 read instead of a $1.00 rewrite, which covers that premium. A break longer than an hour is cold on either TTL, and on the hour TTL the rewrite costs $1.60. Claude Code exposes the choice as the promptCacheTtl setting in settings.json (v2.1.242 or later):

{
  "promptCacheTtl": "1h"
}

The cache runs on a timer. When the sand runs out, the next message buys the whole history again.

See it in your own numbers

You don't have to trust my table. The API reports all three rates on every response. From the caching docs:

• cache_creation_input_tokens: tokens written to the cache by this request.
• cache_read_input_tokens: tokens read from the cache.
• input_tokens: tokens after the last cache breakpoint, neither read nor written.

Total input is the sum of the three. A cache_creation object splits the writes into ephemeral_5m_input_tokens and ephemeral_1h_input_tokens. This script uses the Python SDK to send a large system block marked for caching, the way the caching docs show, and prints the counts. Point it at any text file over a few thousand tokens:

import anthropic

client = anthropic.Anthropic()
history = open("session.md").read()

resp = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=256,
    system=[{
        "type": "text",
        "text": history,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "thanks, now also..."}],
)
u = resp.usage
print("written:", u.cache_creation_input_tokens)
print("read:   ", u.cache_read_input_tokens)
print("fresh:  ", u.input_tokens)

The block has to be long enough to cache at all: 512 tokens on Opus 5.5, per the same docs, and shorter prompts are silently not cached. Run it twice inside five minutes and the second run should report the block under read. Wait six minutes and run it again: the block moves back to written. Multiply each count by its rate and you have the bill for that request.

Claude Code reports the same counts. To check which TTL your main conversation's writes used, the docs suggest running claude -p "hello" --output-format json and reading usage.cache_creation in the result. During a session, /usage (v2.1.251 or later) adds a Prompt cache (main) line. The costs docs show it like this (one line in the terminal, wrapped here):

Prompt cache (main):   14 requests · 91% of input tokens from
cache · 2 misses (last 6m 10s ago, 310.2k tokens re-cached) ·
1 expected rebuild (compaction or tool-result clearing) ·
warm (1h TTL, last activity 40s ago)

The misses part says how many tokens cold turns wrote back, and a cold cache shows how long the session has been idle. If you want to go back further than /usage, each session's full transcript is kept at ~/.claude/projects/<project>/<session>.jsonl (docs).

What idle compaction in 2.1.314 trades away

Claude Code's answer to the coffee break is idle compaction. 2.1.299 added it to the terminal on October 14 (Classmethod has a write-up). On October 30, 2.1.314 added it "to VS Code and Claude Desktop's Code tab: a 200K+ token conversation left idle is summarized, and the summary is used on your next message if the prompt cache has expired."

The idleCompaction entry lists when it runs. All of these must hold:

• You're in an interactive terminal session, the VS Code chat panel, or the Desktop Code tab running locally or over SSH.
• Auto-compaction is on.
• The conversation is on the one-hour TTL.
• Claude Code can fetch feature flags from Anthropic.
• The context has reached the threshold, 200,000 tokens by default.
• About an hour has passed since the last request, and your computer stayed awake.

Check the size condition against your model. The same entry says that "at the default, a conversation on a 200K context window auto-compacts before it reaches 200,000 tokens." So out of the box, only sessions on a larger context window ever qualify. On a 200K window you have to lower the threshold first (see below).

Compaction sends a separate summarization request that repeats your history, and the docs say that while the cache is warm, it "reads your prefix from the cache." So reading 200K tokens happens at the cheap rate, before the cache expires. When you come back, your next message writes the summary and the files Claude Code re-reads, not 200K tokens.

The summary isn't free. The summarization request reads the 200K prefix, about $0.04 on Opus 5.5. The summary itself is generated output, billed at the output rate ($20 per million on Opus 5.5). The request also inherits your extended thinking setting, and the costs docs say you can't turn thinking off on Opus 5.5 and that thinking tokens bill as output. If a summary came out at 10,000 tokens, that would be about $0.04 to read, $0.20 of output plus whatever thinking it spends, and $0.08 to write it to a 1-hour cache, with the re-read files on top. Treat that $0.32 as a floor, against $1.60 for the cold rewrite. Your summary size will differ. On a subscription, all of it is plan usage rather than dollars.

What compaction really costs is detail. Per the context window docs, project-root CLAUDE.md, auto memory and your plan are re-injected from disk, and Claude Code re-reads up to five recently modified files (a file over 5,000 tokens comes back as a path only). Path-scoped rules and nested CLAUDE.md files lived in the message history, so compaction "summarizes them away with everything else"; they come back only when Claude next touches a file that triggers them. Exact error messages and the dead ends you already ruled out go the same way, unless the summary happened to keep them.

You'll know it happened. VS Code shows "Compacted using a summary written while you were away", and the terminal shows a line starting "Compacted while idle, before the prompt cache expired." To turn it off, set "idleCompaction": false. To change the threshold, set CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS in the env block of settings.json, with 100,000 as the floor.

If you'd rather pick what survives, compact yourself before you step away. /compact focus on the failing auth test keeps what you name. /clear costs nothing when the next task is unrelated. And /rewind goes back to a prefix that is already cached instead of building a new one.

Spotting the big sessions before you walk away

I build Hermes IDE, so weigh this section with that in mind. Hermes runs Claude Code, Codex and other agents side by side, each in a real terminal. With several sessions open, the question before you walk away is which of them are big.

Hermes 2.3.4, released October 15, added a context meter to each session that shows how full the conversation is and offers Compact when it gets close to full. The sidebar shows a context gauge for each session, and the status strip shows the session's token total and its cost. That figure is either what the agent itself reports or an estimate from its transcript, labelled as an estimate.

A Claude Code session after pressing the Context chip: Claude Code's /context breakdown (44.4k of 1M tokens, 4%), the per-session context gauges in the sidebar, and the status strip with the token total and estimated cost.

That gives you a habit for the break: scan the gauges, and for any session near 200K that sits between tasks, compact it with a focus before you leave. The Commands list above each session includes Compact, and a command only runs when the agent is waiting, so it never lands in the middle of a turn. When you come back, watch how far the session's spend figure jumps after your first message; that jump is roughly what the return cost.

What Hermes doesn't do: it doesn't know whether a session's prompt cache is warm or cold, or which TTL it is on. For that, run /usage inside Claude Code and read the Prompt cache (main) line. Hermes also doesn't compact anything on its own. You click Compact, or Claude Code's own idle compaction does it.

The action bar above a Claude Code session (Prompts, Context 4%, Model, Plan, Review, / Commands) with the Commands list open: pinned Context, Model, Plan and Review, then built-in commands such as Compact, Usage and Diff.

Hermes is free to download, source-available under BSL 1.1, and runs on macOS, Windows and Linux. The code is on GitHub. It isn't affiliated with Anthropic, Nous Research or any agent vendor.

Do you let idle compaction summarize your long sessions, or did you turn it off the first time it dropped something you needed?

If this was useful

A cold cache is a cost regression you only see if you trace tokens per request and split reads from writes. Observability for LLM Applications is my book on doing that for LLM features in production: traces, evals, cost and quality, and the dashboards that catch a $0.04 turn quietly becoming a $1.00 one.