A developer opens Claude Code on a Monday morning to finish a feature branch he started Friday. He picks up where he left off, points Claude at the same files, asks it to keep building. Three hours and a dozen back and forth messages later, he checks the usage dashboard out of habit and stops cold. The session cost four times what a similar session cost him last week. Same task, same model, same rough amount of code written. He didn't change anything he can point to. He just kept working the way he always works.
What changed is invisible unless you know where to look. Somewhere in that session, the cache reset. Every message after that point got billed at full price instead of the discounted rate he'd been paying without realizing it. He never saw an error, never got a warning, and the bill just quietly became someone else's problem to explain at the end of the month.
This is the part of working with Claude that almost nobody teaches directly. Everyone learns to write good prompts. Few people learn how the context window gets priced, when that pricing changes underneath them, and what commands exist to control it. This article covers all three, with the exact steps to put them into practice.
Tokens Are the Currency, the Context Window Is the Ledger.
Every word you send to Claude and every word it sends back gets counted in tokens, roughly one token per three-quarters of a word in English. The context window is the running total of everything in the current conversation: your messages, Claude's responses, the contents of any files it read, the output of any tool it ran. Claude Opus, Sonnet, and Fable all currently operate with a 1-million-token window, which sounds enormous until you remember that a single large codebase file can eat tens of thousands of tokens on its own.
Here's the part that surprises people coming from a chat-app mental model: Claude has no memory between messages. Every time you send a new prompt, the entire conversation history gets sent back to the model again, from the very first message. A 50-message conversation doesn't cost you one message's worth of tokens on message 51. It costs you the full history, every time, because that's the only way the model can see what happened earlier. This is why long sessions get progressively slower and progressively more expensive. You're not paying for the new message. You're paying to resend the whole conversation plus the new message.
That accumulation problem is exactly what prompt caching exists to solve, and understanding it is the single highest-leverage thing you can learn about running Claude efficiently.
How the Cache Prices Your Tokens.
Picture the conversation history as a physical document sitting in front of Claude. Every time you send a message, Claude has to read that document again before it can respond. Prompt caching means Claude keeps a copy of that document on hand instead of re-reading it from scratch on every turn.
Reading tokens into the model for the first time is called a cache write, and it costs roughly $20 per million tokens. Reading tokens that are already cached is called a cache hit, and it costs about $1 per million tokens, a 20 times difference. That gap is the entire reason cache management matters. A session that stays inside a warm cache is cheap. A session that keeps rewriting the cache is expensive, and the expensive version often looks identical to the user because nothing in the interface tells you which one is happening.
There's a second cost dynamic stacked on top of this: output tokens, the words Claude writes back to you, cost roughly five times more than input tokens. This means a chatty response that restates your question, explains its plan, and then does the work is burning money at the most expensive rate in the whole system before it's even gotten to the useful part. Keep that fact in your head. It matters later in this article when we get to output scaffolding.
Put the two together and the efficient pattern becomes clear: keep your input tokens inside the cache as long as possible, and keep your output tokens as lean as the task allows.
The Cache Is a Rental, Not a Purchase.
The cache doesn't last forever, and it doesn't last as long as most people assume. It expires after one hour of inactivity. Every message you send resets that hour-long timer, so an active session stays warm indefinitely. Walk away for lunch and come back an hour and ten minutes later, and the next message pays full cache-write price to rebuild what was already there.
The one-hour rule is predictable and easy to plan around. The part that catches people off guard is that several ordinary actions wipe the cache immediately, with no warning, regardless of how recently you sent a message. Know these four triggers, because each one is something you'll do without thinking:
Switching models mid-session, for example moving from Sonnet to Opus for a harder step, invalidates the cache. The new model has never seen your conversation before, so it has to build a fresh cache from zero.
Changing effort levels or toggling fast mode does the same thing, because it changes how the model processes the request underneath the conversation.
Connecting or disconnecting an MCP server changes the tool definitions available to Claude, and tool definitions render into the prompt before your conversation does. Add or remove one mid-session and everything downstream of that point gets reprocessed.
Upgrading the Claude Code software itself resets active sessions, since the underlying request shape can change between versions.
None of these are mistakes to avoid. They're all things you'll do routinely. The point isn't to never touch your MCP servers or never switch models. It's to know that doing so has a cost, so you can time it deliberately instead of triggering an expensive rebuild by accident in the middle of a task you thought was almost done.
Tools for Keeping the Window Lean.
Once you understand that the context window grows every turn and the cache can vanish at any moment, the next question is what to do about it day to day. Claude Code gives you three commands for this, each suited to a different situation.
/clear, which wipes the conversation history completely and starts a new session. This sounds wasteful, but it's often the cheapest option available. Claude can reconstruct almost everything it needs about the current state of your work just by reading your project files again, especially if you're working in a git repo with a CLAUDE.md file describing the project. Run /clear at natural breakpoints: after finishing a feature, before starting an unrelated task, or any time the conversation has drifted into territory you no longer need. You lose the specific back-and-forth reasoning from earlier in the session, but you gain a small, cheap prompt instead of a bloated, expensive one./compact, which summarizes the current conversation into a condensed form and starts a new session using that summary as its starting context. Use this when the conversation itself, not just the file contents, is worth preserving. If you and Claude worked through a tricky debugging session and arrived at conclusions you don't want to re-derive, /compact keeps that reasoning intact in compressed form instead of throwing it away. Run it when you notice responses getting slower or when you're deep into a long session and want to keep going without paying full price to resend the entire history on every turn. This is also the fix for what people call context rot, where a very long conversation starts producing worse answers because the useful signal is buried under accumulated noise.The third option is a custom handoff, which is a manual version of the same idea with more control. Instead of letting Claude Code summarize automatically, you ask Claude to write a markdown file to disk capturing exactly what it thinks the next session needs to know: what's been done, what's left, any decisions or constraints worth remembering. Something like "write a HANDOFF.md summarizing our progress and the remaining steps" before you end a session. Then start a fresh conversation and open with "read HANDOFF.md and continue from there." This costs you a small amount of output tokens to write the handoff, but it gives you a permanent, editable, human-readable artifact instead of an opaque auto-generated summary, and you can hand that file to a different model or a different day's session with full control over what carries forward.
Trimming the Base Weight of Every Prompt.
Everything above deals with the conversation as it grows. There's a separate category of cost that exists before you type a single word: your CLAUDE.md file, your enabled skills, and your connected MCP servers all get sent to Claude on every single message, whether they're relevant to the current task or not. This is your base token load, and it compounds across every request in every session you run.
/doctor periodically to audit this. It flags an oversized CLAUDE.md file, skills you've enabled but rarely invoke, and MCP servers sitting connected without being used in the current workflow. Trim what it flags. A CLAUDE.md file that's grown to several thousand words of instructions accumulated over months is adding that same weight to every request you send, forever, until you cut it down. This is the cheapest optimization in this entire article, because it's a one-time cleanup that pays off on every future session rather than something you have to remember to do repeatedly.Routing Work to the Model That Should Do It.
Not every step in a task deserves your most expensive model. Advisor mode, or model routing more generally, splits work between a high-intelligence model that plans and a cost-efficient model that executes. Use Opus or Fable to think through architecture, break a feature into steps, or make a genuinely hard judgment call. Then hand the actual implementation work, the file edits, the boilerplate, the mechanical parts, to Sonnet.
In practice this means starting your planning conversation with your strongest model, asking it to produce a concrete, numbered plan, and then either switching models for execution or opening a second session with a cheaper model and pasting the plan in as the starting instruction. Each model maintains its own independent cache, so this isn't a workaround that breaks caching. It's two separate cache lifecycles running in parallel, each priced appropriately for the work it's doing. The expensive model spends its tokens on the parts that need its intelligence. The cheap model spends its tokens on execution, at a fraction of the cost, without any real loss in output quality for that kind of work.
Shrinking the Expensive Side of the Ledger.
Remember that output tokens cost roughly five times more than input tokens. This means the fastest way to cut your bill isn't always about the input side at all. It's about getting Claude to write less.
The most direct version of this is adding a plain instruction to your CLAUDE.md file or system prompt: be brief. Ask Claude to skip restating the plan before executing it, skip narrating routine steps, and go straight to the change with minimal explanation unless you ask for detail. This alone noticeably reduces output token volume on tasks where Claude tends to explain itself more than the task requires.
A more structured version of the same idea is a compressed communication mode like Caveman, which strips filler words and connective prose from responses while keeping the technical content intact. Invoke it explicitly for a session where you want maximum token efficiency, particularly on tasks with a lot of back-and-forth commentary rather than a lot of code output. It won't help on tasks where the output is mostly code anyway, since code isn't where the verbosity lives. It helps most on tasks with heavy explanation, planning, or status updates, where a five-sentence summary can become a single line without losing anything you needed.
What to Do This Week.
/doctor. It costs nothing, takes a few minutes, and lowers the base weight of every session you run from here forward. Then build the habit of running /clear between unrelated tasks rather than letting one long conversation drift across three different projects. Reserve /compact and custom handoffs for sessions where the accumulated reasoning genuinely matters and is worth the smaller cost of preserving it. Route planning to your strongest model and execution to a cheaper one whenever a task naturally splits that way. And add a brevity instruction to your CLAUDE.md file today, because it's a single line that pays off on every response for the rest of the time you use Claude.None of this requires you to write worse prompts or ask for less capable output. It requires you to notice where the meter is running and to make a small number of deliberate choices instead of letting a long session and a stale cache make those choices for you.