Maximizing Claude Code Sessions: What Actually Costs You Tokens

Anthropic published Maximizing the value of your Claude Code sessions, written by Lydia Hallie, on August 14, 2026. It resurfaced on September 3 when Addy Osmani shared it, and the resurfacing is the interesting part: the post is not a tips listicle, it is a description of the billing mechanism, and almost every practical rule people argue about falls out of that mechanism automatically.

The framing line worth keeping: "Being efficient with tokens doesn't mean using fewer of them overall. It means making sure the ones you do use go towards the thing you actually asked for."

Below is the mechanism decoded, the five specific actions that throw your cached conversation away, and answers to the questions the thread under Osmani's post actually asked — including the one about whether the one-hour cache expiry applies to all models.

TL;DR — what people are actually asking

The mechanism: you're paying for GPU time, not text

You're billed per token, but the token is a proxy. What you're actually buying is inference time, and three things decide how much of it a token consumes: which model, whether it's input or output, and whether it was cached.

Input goes through prefill — one pass over the system prompt, your CLAUDE.md, your message, and everything added to the conversation since. Output goes through decode, one token at a time. A 200-token response is 200 sequential runs of the model. That sequential-ness is the entire reason output is priced at roughly 5x input.

This single fact reorders most people's intuitions. Reading a large file is cheap. Thinking about it at high effort, repeatedly, is not. If you want a fuller treatment of how per-turn accumulation compounds into a bill, our context window pricing breakdown works the math with real numbers.

Prompt caching, and why prefix order matters

If a request starts with exactly the same tokens as one the server just processed, the state for that shared beginning is identical, so it can be loaded instead of recomputed. Cache reads cost 0.1x normal input. Cache writes cost up to 2x — but the write happens once per token and the cheap reads happen on every turn afterward.

The critical detail is that the match has to run from the very start of the request forward. Claude Code always sends in the same order:

1. Tool definitions
2. System prompt
3. The conversation, with CLAUDE.md at the front of it

A tool result appended to the end of the conversation is the ideal case — nothing sits behind it, so nothing else has to be re-prefilled. Anything that changes the request further toward the front, or changes what the cache is keyed on, throws away everything behind it.

The five things that bust your cache

This is the part that costs real money, and four of the five are things people do casually mid-session:

That opusplan detail is the one most likely to be silently expensive, because plan mode feels like a UI state rather than a model switch. It isn't. Every entry and exit is a full re-prefill of the conversation. If you're weighing which model and effort level to be on in the first place, we covered that trade-off in model vs effort — knowing more versus trying harder and the effort parameter guide.

Answering the thread's question: is the one-hour expiry model-specific?

One reply under Osmani's post asked directly whether the prompt cache expires after an hour for all models or just for Claude Code. It's the right question, and the answer is that the hour is not a model property at all.

The TTL is a function of how you're billed: one hour on a subscription, five minutes on an API key, with ENABLE_PROMPT_CACHING_1H=1 raising the API-key case to an hour. The model you're running doesn't change the duration — it changes the cache, since each model has its own, which is a different problem entirely.

Two practical corollaries the article notes:

• Every turn resets the clock. An actively-used session never ages out. The expiry only bites during breaks.
• Resuming an old session almost always re-prefills. The cache is usually gone by then, and the system prompt gets rebuilt at launch regardless. Our guide to continuing and resuming previous conversations covers the workflow; the cost side is that resumption is never free.

/rewind is free. /compact never is.

This is the most immediately actionable thing in the whole post, and it's easy to miss.

/rewind cuts turns off the end of the conversation. Everything before them is untouched and still cached, so rewinding costs nothing. /compact rewrites the entire conversation into a summary, so by definition nothing behind the system prompt matches anymore — it always costs something.

The rule that follows: if the last few turns went somewhere you don't want to keep, rewind, don't compact. Compaction is for when the earlier part of a task is genuinely done, not for undoing a wrong turn.

And when you do compact, timing dominates. Summarizing is cheap while the old conversation is still in the cache and expensive once it has expired — which is why the article's advice is to /compact before you step away from the keyboard, not when you come back to a cold session an hour later.

Medium-sized output is the trap, not big output

Everything that enters the conversation — every file read, every command's output — is re-sent on every turn for the rest of the session. Cached, so each re-send is cheap. But cheap isn't free, and it occupies context the model has to reason around every single turn.

Here's the counterintuitive part. Output over 30,000 characters is fine: Claude Code writes it to a file and puts only a short preview plus the path into the conversation (BASH_MAX_OUTPUT_LENGTH controls the threshold). The genuine problem is everything under that limit — a test runner printing 400 passing tests one line at a time sails in under the cap, and those 400 lines are now part of every remaining turn.

Two fixes, in order of durability:

1. Quiet flags in CLAUDE.md. Write the two or three commands you run all day the way you'd type them yourself, flags included — for example, "run a single test file with npx vitest run <file> --reporter=dot". It's a couple of lines that save a turn and a few hundred lines of output in every session after it.
2. A hook that rewrites noisy commands before they run, so only the lines that matter come back. If you're deciding where a given rule belongs, skills vs hooks vs prompts covers the routing question, and steering Claude Code covers how CLAUDE.md, skills, hooks, and rules divide the work.

@-mention files instead of naming them

Saying "the tests are failing" makes Claude find out which tests: a grep or two, a few speculative file opens, and every one of those results stays in context long after it stopped being useful.

"Fix the failing test in utils.test.ts" skips the searching and costs one Read call. "Fix the failing test in @utils.test.ts" doesn't cost the Read call either — Claude Code attaches the file to your message before anything is sent, so it's in the very first request.

One caveat that matters: the file occupies the same context either way, and it stays there. @-mentioning the same file again on a later turn generally attaches a second copy. Mention once per conversation.

Audit what's loaded before you type anything

Run /context in a fresh session. It shows what's already in there — tool definitions, the system prompt, CLAUDE.md, MCP tool definitions — before you've contributed a single token. Most people have never looked, and most people are carrying something they don't need.

Two levers from there:

• Move workflow-specific instructions out of CLAUDE.md and into skills, which only load when they're actually used. CLAUDE.md is paid for on every turn of every session; a skill is paid for when invoked. Our agent skills guide covers the format.
• Turn off MCP servers you don't need this session with /mcp. MCP tool definitions sit in the prefix, ahead of your entire conversation.

One more lever the article mentions in passing and most people don't know: MAX_THINKING_TOKENS=0 claude turns thinking off for a single session (except on Fable 5) — a step below /effort low, worth knowing when you're certain the session is grunt work.

Subagents: real savings, real overhead

A subagent gets its own context window, its own system prompt, the tools, and your CLAUDE.md — but not your conversation. It runs its own turns, and the only thing that returns to the main session is its answer. Everything else is discarded.

That cuts both ways. Because it lacks your conversation, a subagent sometimes has to re-read what the main session already had, and it pays for its own turns doing so. For a small job that's pure overhead. It pays off when the job produces a lot of output you don't need to keep — reading through a long log being the canonical case, and one you can ask for explicitly ("go through this log in a subagent").

For a noisy job you hand off repeatedly, give it a subagent definition with model: haiku (or sonnet) — otherwise it inherits whatever your main session is running on, which is usually more model than the job deserves. Claude Code subagents and multi-agent workflows goes deeper on the orchestration patterns.

The trade-off to accept going in: the main session only gets back what the subagent chose to report. If you need the details, a subagent is the wrong tool.

The /loop gotcha

A /loop fires as a full turn in the session you set it up in, dragging that entire conversation along every time it runs. If more than an hour has passed since the last turn, it's a cache miss on top of that.

The fix is one line: start a fresh session in another terminal and run the loop from there. Our loop engineering guide and how to run loops in Claude Code both assume a dedicated session for exactly this reason.

What the thread added that the article didn't cover

The replies under Osmani's post surfaced three community techniques worth naming honestly — none are in Anthropic's post, so treat them as practitioner experience rather than documented behavior:

• Nested CLAUDE.md files per directory, so context is specific to the part of the project the agent is touching. The upside is a smaller always-loaded root file. The thing to watch is that a file pulled in partway through a session enters the conversation partway through too, so this is a context-relevance optimization first and a cache optimization only incidentally.
• A "pass the baton" appendix — having Claude write an explicit handoff document for the next session instead of relying on /compact. The argument is that an explicit spec beats a generated summary because you control what survives. Anthropic's own version of this lever is telling /compact what to keep, or putting a "Compact instructions" section in CLAUDE.md when it's always the same thing.
• A selectable file tree for pulling in whole folders from the start. This is a feature request, not a workaround — @-mention is currently per-file, and there's no folder-level equivalent that skips the Read calls.

Where to look first — explainx.ai's ranking

Anthropic closes with a diagram of four things to watch. Here's our ordering of the same material, by how much money is actually at stake for a typical working session:

1. Model and effort discipline. Everything else multiplies by the model's price, and a mid-conversation switch re-prefills the whole conversation. Decide at the start; /model and /effort both remember your last choice, so make that choice deliberate rather than inherited.
2. Session length. Turn 40 re-reads the 39 turns before it. /clear between tasks is the single cheapest habit available, and /rename before you clear keeps the session recoverable.
3. What accumulates in context. Medium-sized command output and speculative file reads, in that order. Quiet flags and @-mentions fix both.
4. What's loaded before you start. CLAUDE.md bloat and unused MCP servers are paid for on every turn of every session — the lowest-effort fix on this list, and a one-time one.

If you're managing this at the team or budget level rather than session by session, token budget planning and execution and Claude Code pricing approach the same problem from the finance side, and what happens when you hit the context limit covers the failure mode this guidance exists to prevent.

Honest limitations

• No dollar figures. The article gives ratios — 5x output, 0.1x cache read, 2x cache write — not prices, and ratios don't tell you whether a habit is worth changing at your volume. You'll need Claude Code pricing or your own usage data for that.
• Subscription users can't see any of this directly. As the post notes, the same requests draw down your limits, but there's no per-turn cost readout to verify the advice against. You're optimizing on trust plus /context.
• The opusplan cost is stated, not quantified. How much a plan-mode round trip actually costs depends on conversation size at that moment, and no figure is given.
• Nothing here is measured. These are mechanism-derived best practices from the vendor, not an A/B study — no before/after token counts accompany any of the six TL;DR items.
• Version-sensitive. /autocompact 200k, which restores the old auto-compact threshold on 1M-token models, requires Claude Code v2.1.221+. Behavior described here can change between releases.

Update — September 3, 2026: The same mechanism, measured on the Google side with published token counts — context caching in agent harnesses, and the cost math Google left out.

Related on explainx.ai

• Claude Code context window — what happens when you hit the limit
• Context window pricing, decoded — the real math
• Model vs effort in Claude Code — knowing more or trying harder
• Claude Code subagents and multi-agent workflows
• Steering Claude Code — CLAUDE.md, skills, hooks, subagents, rules
• Claude Code commands — complete reference
• Token budget planning and execution
• Claude Code pricing guide · agent skills directory

Primary source: Maximizing the value of your Claude Code sessions — Lydia Hallie, Anthropic, August 14, 2026.

Ratios, environment variables, and command behavior reflect Anthropic's post as published August 14, 2026 and read on September 3, 2026. Claude Code changes quickly — /autocompact 200k requires v2.1.221 or later, and thresholds like BASH_MAX_OUTPUT_LENGTH are configurable. Verify against the official docs for your installed version.