The Claude Code community has been buzzing with frustration lately: subscription quotas are burning up too fast. Some users are exhausting their weekly Max plan allowance in just two days. One user calculated the real cost on AWS Bedrock: a single session can exceed $134, while the Pro Max 5x subscription costs only $100 per month. Anthropic is essentially selling subscriptions at a loss.
Many users' first instinct is to frequently use /clear or start a new session after every task, thinking this "lightweight" approach saves money. But if you understand Claude Code's caching mechanism, you'll realize this often backfires: you just triggered a full-price context rebuild that costs more than continuing the conversation.
To understand why quotas vanish so quickly, you need to grasp how large language models process input—it's completely different from human "reading."
Imagine you're writing a paper on climate change. Every time you go to the library, you do the same thing: find that 500-page "Global Climate Report," flip to the needed chapter, and copy down key data. First time: 40 minutes. Second time, different question, same book: another 40 minutes. Third, fourth: same 40 minutes.
That's what large language models do. They have no "memory"—they don't skip content just because they just read it. Every time they receive your message, they must "read" the entire input from scratch, with reading time proportional to content length.
In Claude Code, input typically consists of three parts:
- Fixed components: System instructions, tool definitions, project rules in CLAUDE.md
- Conversation history: All previous dialogue turns
- New message: What you just typed
The first two parts remain nearly unchanged within the same session, but the model must "reread" them every time. After 20 turns, each new message might carry 100,000 tokens of "old baggage," making it slow and expensive.
Prompt Caching: Storing "Notes" for Later
Nobody wants to flip through that 500-page book from scratch every time. The solution is straightforward: take notes in advance, then just refer to the notebook next time.
That's what prompt caching does.
After the model reads a segment of input, it generates a set of intermediate calculations—essentially "reading notes." When generating subsequent responses, the model relies on these notes instead of revisiting the original text. The caching mechanism works like this: after computing notes the first time, they're stored; next time the same input prefix appears, the stored notes are used directly, skipping redundant computation.
Reading from cache costs only one-tenth of recomputing.
Rough estimate: a 20-turn session with 100,000 tokens of context, if cache hits consistently, reduces input costs by over 6x compared to full-price processing every time.
But caching has two prerequisites.
First, cache only works for "prefixes." They must match from the start, character-for-character.
Analogy: You write an essay on lined paper. The first three pages are identical, but you change one word on page four. Only the first three pages can use cache; from page four onward, recomputation is needed. If you change one word on page one? Entire cache invalidated, start over.
Thus, Claude Code's input structure matters: place system instructions, tool definitions, and other unchanging content at the beginning, conversation history in the middle, and new messages at the end. Each time, only the small tail segment needs recomputation, while the large preceding segment hits cache.
In an active session, prefixes naturally match; each turn merely appends new content to the end, yielding high cache hit rates. But if you start a new session, prefixes begin from zero, and previously accumulated cache becomes unusable.
Second, cache has a lifespan. According to the Claude Code team, the main agent's cache window is 1 hour; sub-agents have 5 minutes. API users default to 5 minutes (can pay for 1 hour, but it's more expensive). Each cache hit refreshes the timer—as long as you maintain interaction frequency, cache can stay alive.
The Claude Code team's exact words:
"Claude Code is the framework with the highest cache utilization."
But the penalty for cache misses increases dramatically with context length. A 200K cache miss versus a 1M cache miss are completely different magnitudes of expense.
Three Counterintuitive Money-Saving Strategies
Understanding cache flips some "common sense" on its head.
When Cache Is Hot, Continuing Costs Less Than Starting Fresh
Every new Claude Code session must reload system prompts, tool definitions, CLAUDE.md, and project configurations. This "infrastructure" totals about 50,000 tokens. Frequent /clear means repeatedly paying full write fees for this unchanging content.
In an active session, this content remains cached, costing only one-tenth the price each time.
Anthropic employee Lydia Hallie's advice—"for large sessions idle about an hour, recommend restarting"—key word is "idle." For active work sessions, cache stays hot; continuing is cheapest.
Getting Complex Tasks Right the First Time Saves More Than Multiple Revisions
Turning off extended thinking can save tokens per request. But for a complex refactoring task, using extended thinking to complete it once versus turning it off and revising three times—the latter is likely more expensive. Because each additional dialogue turn resends the entire context; three rounds accumulate far more tokens than the extra overhead of one deep-thinking session.
Simple tasks are the opposite. Lowering /effort or disabling thinking mode in /config shows immediate effects. Thinking tokens are billed at output rates; default budgets are clearly wasteful for simple tasks.
Give Paths for Long Content, Don't Paste into Dialogue
Instead of controlling output length, focus on input quality. Don't copy-paste 10,000 lines of logs into dialogue for Claude to find errors; just send the log file path. Claude Code will use tools like grep to retrieve needed information, pulling only relevant content into context. The cheapest tokens are those never entering context.
Continue or Start Fresh: A Decision Table
This might be Claude Code's most crucial token-saving judgment. Many users' default habit is "clear when done," but the cheapest default should be the opposite: continue when possible; starting fresh is a conditional trigger.
If any condition below is met, continue current session:
- Task unchanged. Still debugging the same bug, writing the same module, working with the same set of files.
- Last message within 1 hour. Cache still alive; previously accumulated context costs almost nothing.
- Context content remains useful for current work. Files previously read, solutions discussed—the model still uses them.
If pondering with no input, send a brief message to keep cache active. Some users even wrote heartbeat extensions to automatically refresh cache; refreshing cache costs only one-tenth of a full cache miss.
If any condition below is met, start new session:
- Task changed. Just finished authentication module, moving to payment functionality—two completely different contexts. Old session's piled code files and debugging records are useless for the new task; each request pays for this irrelevant content.
- Idle over 1 hour. Cache likely expired; continuing equals triggering full rebuild, better to start clean.
- Context clogged with irrelevant content. Tried dozens of approaches, read many unrelated files—these still occupy space. Even with cache hits, the model must find signals in noise, output quality drops, and compression might discard key information.
Summary: Cache hot, task same—continue. Cache expired, task switched, context noisy—restart decisively.
Community feedback: working one task per session rarely triggers quota issues.
1M Context Window: Use with Caution
Starting March 2026, Max, Team, and Enterprise plans default to Opus 4.6's 1M context window. Anthropic removed the 2x price premium for long contexts; 1M window costs same as 200K.
But 1M context is becoming the top reason many quotas hit zero.
The problem lies in cache miss penalties. You accumulate a long session with 1M context, step away from computer over 1 hour, return to continue—now 1M tokens of cache are expired, and one message triggers full rebuild. The team confirmed this issue, considering lowering default context from 1M to 400K.
Moreover, most daily sessions trigger compression at 80-120K context, never reaching 200K, let alone 1M. Community experience data points to the same conclusion: model performance noticeably declines past 200K context, beyond 350K it's basically luck.
Legitimate 1M scenarios exist: one-time loading of large codebases for global refactoring, long multi-turn dialogues avoiding compression interruptions. But daily coding and bug fixes don't need it.
My advice: Keep 1M window but set a conservative auto-compression threshold, balancing flexibility and efficiency.
To disable 1M context, add to ~/.claude/settings.json:
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}To set auto-compression context threshold:
{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
}
}When context nears 200,000 tokens, auto-compression summarizes it, preserving continuity while preventing cost spikes.
Six Operational Rules
1. Use Sonnet for Daily Work
Opus's input cost is about 1.7x Sonnet's, but more critically, Opus consumes tokens roughly twice as fast as Sonnet. Many teams spend time figuring how to make Opus talk less; better to ask first: does this really need Opus? Most coding tasks are fine with Sonnet; reserve Opus for complex architecture decisions and multi-step reasoning. Switch with /model in Claude Code.
2. Don't Switch Models Mid-Session
Prompt cache is model-isolated. You accumulate 100,000 tokens of cache on Opus, switch to Sonnet for a simple question—Sonnet must build its own cache from zero. Having Opus answer directly might cost less than switching to the "cheaper" Sonnet. For lightweight model needs, use sub-agents rather than switching main model.
3. Streamline CLAUDE.md, Control Skill Count
CLAUDE.md content injects into every request. Official recommendation: keep under 200 lines, retaining only truly long-term effective rules. Move lengthy instructions like code review processes or database migration steps to skills; skills load only when invoked, not occupying context prematurely.
But more skills aren't better either. Loading too many skills and agents is a hidden quota killer; the team is improving interfaces to make these costs more visible. Place skills in project directory (.claude/skills/) rather than global, installing only what the current project truly needs. Also remember to turn off unused MCP services.
A small trick: write maintainer notes in CLAUDE.md using HTML comments; Claude strips comments before injecting context, saving tokens.
4. Command Line First, MCP Second
GitHub's gh command-line tool consumes far fewer tokens than GitHub MCP server. MCP tools inject full structure definitions into context, costing tokens on both request and response sides. If command line can handle it, skip MCP.
5. Spend a Few Tokens on Planning First
For complex tasks, enter planning mode first—let Claude explore code, propose solutions, then implement. Total cost is often lower. What's truly expensive is re-scanning code, rewriting implementations, and re-running tests after going in the wrong direction.
Same for questions: vague prompts like "help optimize this codebase" trigger broad scanning; specific instructions like "add input validation to login in auth.ts" significantly reduce file reads and trial-and-error.
6. Use permissions.deny to Limit Model's Reading Scope
Unindexed codebases force models to search for context via file exploration, extremely inefficient. In .claude/settings.json, use permissions.deny to strictly limit model-readable areas, e.g., exclude node_modules, build artifacts, large data files:
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./node_modules/**)",
"Read(./build)"
]
}
}Files matching these patterns are excluded from file discovery and search results; read operations are directly denied. Models sometimes get stuck in codebase search loops lasting over 5 minutes; even if you specify file paths, they might repeatedly read irrelevant files in background. permissions.deny reduces this waste at the source.
Delegate Some Work Out
Two delegation approaches can reduce main session token consumption.
Sub-agents: Claude Code sub-agents have independent contexts, returning brief summaries to main session upon completion. Sub-agent cache windows are only 5 minutes (main agent: 1 hour), with lower cache utilization per call. But their value lies in context isolation: detailed outputs from code reviews, test runs, documentation checks don't remain in main session; subsequent messages don't pay for this content.
Agent teams differ from sub-agents. Each team member is an independent Claude instance maintaining its own context window. Planning mode with agent teams consumes several times more tokens than standard sessions (community estimates ~7x); idle members continue consuming. Concurrent acceleration has costs; multiple agents don't equal cheaper.
Codex plugin: If you also have an OpenAI subscription, some community members use openai/codex-plugin-cc to offload tasks. This is a third-party community solution; user feedback suggests Codex uses about one-third Claude Code's tokens for equivalent tasks, but effectiveness varies. Suitable for delegation: structured bug fixes, code reviews, test writing. Leave for Claude Code: architecture design, cross-file refactoring, complex work requiring understanding of entire codebase.
Installation:
claude mcp add codex -- npx -y @openai/codex-plugin-cc
Some Clarified Misconceptions
The community circulates many claims about quota consumption; Claude Code team provided official clarifications in discussions.
The most widespread: "consumption accelerates after context exceeds 256K." Official response is direct: Not true. Actual cause is likely users restarting long-idle sessions, triggering large cache misses, mistakenly attributed to context length.
Others complain models waste tokens checking files for malware each read. This security check prompt existed since Sonnet 3.7; each new model was evaluated, no regression caused. Opus 4.6 removed this prompt. Regarding "adaptive thinking causing abnormal quota consumption," team also ruled it out. Team stated they're not blindly trusting internal metrics, still investigating:
"We're taking this seriously, still investigating. We're not blindly trusting internal metrics."
Core token-saving philosophy in one sentence: Maximize cache hits, minimize irrelevant content in context.
Starting fresh is a tool; understanding prompt cache reveals that "continuing work in active session" is the default strategy, while "starting new session" is an optimization triggered by specific conditions.
Many in community compare Claude Code, Codex, Cursor for whose quota is more generous. But quota tightening might be an industry trend; some say we're in the "end of subsidized compute era," similar to Uber's $3 ride phase. Rather than betting which company subsidizes longer, understand cost structure, spend wisely.
How long are your typical sessions? Do you frequently /clear from fear of continuing?