Many developers struggle with token quotas disappearing fast in Claude Code, especially during long sessions. But tech influencer Nate Herk recently shared on X that the real cost driver is not code volume, but whether prompt caching is leveraged properly. He saved 300 million tokens in a single week, with a daily cache hit of 91 million. Since cached tokens cost only 10% of regular input, that effectively translates to a daily cost of just 9 million tokens, making long programming conversations almost feel free.
Cached Tokens Cost 10%: 91M Means Only 9M Billed
Every cached token is charged at 10% of the normal input rate. When the dashboard shows 91 million tokens hitting cache on a day, the actual billing is equivalent to only 9 million tokens. This is why Claude Code sessions feel like they extend for free when caching works well. Two key dashboard metrics matter: Cache create (one-time cost of writing to cache) and Cache read (tokens reused from cache, such as CLAUDE.md, tool definitions, previous messages). A high Cache read number indicates effective caching; a low one means you're paying repeatedly for the same context. Anthropic's Thariq noted: "We actually monitor prompt cache hit rate. If it drops too low, we trigger alerts and even declare SEV incidents."
Three-Layer Cache Architecture: System, Project, Conversation
Caching relies on prefix matching. As long as content before a given position matches what's already cached, Claude can reuse those tokens. A typical fresh conversation unfolds like this: first turn has no cache — system prompt, project context (CLAUDE.md, memory, rules) and the first user message are processed and written to cache; second turn — first turn content is now cached, Claude only processes new reply and next message, significantly lowering cost; subsequent turns follow the same pattern. The cache is divided into three layers: System layer (base instructions, tool definitions, output style — globally cached), Project layer (CLAUDE.md, memory, project rules — cached per project), Conversation layer (replies and messages, growing with each turn). If any content in the system or project layer changes mid-session, everything must be recached from scratch — the most expensive operation.
Common Cache-Breaking Traps: Model Switching & 1-Hour Idle
Cache TTL (time-to-live) for Claude Code subscription is 1 hour; for API it's 5 minutes by default; Sub-agents always have 5 minutes. If you idle more than an hour, previous cache expires, and your next message triggers a full rebuild. Instead of resuming a "cold" old session, a clean handoff followed by a new session often costs less. Model switching breaks cache because each model has its own cache; switching resets cached history. The "Opus plan" feature also switches models under the hood, which rebuilds cache each time (though it helps extend quota over long sessions). Commands like /compact or /clear also flush cache.
Practical Tip: Session Handoff Beats /compact for Cost Savings
Nate Herk built a custom session handoff skill to replace /compact. It summarizes what's been done, pending decisions, key files, and where to continue. Then he runs /clear and pastes the summary, effectively resuming without interruption while avoiding cache rebuild. Compact can be slow, but handoff usually finishes under a minute. Also, if you need to paste large files in Claude.ai, put them into a Project rather than directly into the conversation. Editing CLAUDE.md mid-session doesn't take effect until the next restart, so the current cache remains untouched. Nate also shared a self-made token dashboard (GitHub: nateherkai/token-dashboard) that deploys on localhost and reads all session logs, showing daily input, output, cache create, and cache read stats. Note that the dashboard runs locally, so numbers differ between desktop and laptop. Prompt caching is a deep topic, but developers only need the 80/20: cached tokens cost 10x less; Claude Code TTL is 1 hour; model switching breaks cache; clear handoffs between tasks beat resuming expired sessions.