Concise Summary简洁概述
LLMs have no memory — every request re-reads the full input from scratch, so cost scales with context length, not with 'how many turns you've had'.
Prompt caching turns repeated prefixes into ~1/10-price reads, but only if the prefix matches exactly and hasn't gone stale (1hr main-agent window) — so /clear-ing an active session usually costs more than continuing it.
大语言模型没有记忆，每次请求都要把完整输入从头读一遍，成本和上下文长度成正比，而不是和聊了几轮成正比。
提示缓存能把重复的前缀内容压到约十分之一的价格，但前提是前缀完全匹配且没过期（主智能体窗口 1 小时）——所以在活跃会话里 /clear 往往比继续聊更贵。
Infographic信息图
No memory, only re-reading
没有记忆，只有重读
An LLM has no persistent memory between turns — every request reprocesses the full input (system prompt, tool defs, history) from scratch, with cost scaling linearly with length. This is the structural root of runaway spend, not a discipline failure.
大语言模型在轮次之间没有记忆，每次请求都要把系统指令、工具定义、对话历史从头处理一遍，耗时耗钱与内容长度成正比。这是配额烧得快的结构性根源，不是某个坏习惯的问题。
Prompt caching = pre-made notes
提示缓存＝提前做好的笔记
Caching stores the intermediate computation from a prior read as reusable 'notes'; a cache hit costs about 1/10th of full recomputation. But it only works on exact-match prefixes — a single changed character early in the input invalidates everything after it.
缓存把上一次读取产生的中间计算结果存成可复用的“笔记”，命中时成本约为全量重算的十分之一。但它只对逐字匹配的前缀有效——只要靠前的位置改动一个字，后面全部失效。
The clock, not turn count, kills the cache
杀死缓存的是时钟，不是轮数
Main-agent cache windows last about 1 hour, refreshed on every hit; sub-agents get only 5 minutes. Idle time — not conversation length — is what triggers expensive full rebuilds, which is exactly why habitual /clear-ing backfires on an active session.
主智能体的缓存窗口约 1 小时，每次命中都会刷新计时；子智能体只有 5 分钟。真正触发昂贵全量重建的是“闲置时间”而非“聊了多久”，这正是习惯性 /clear 在活跃会话里适得其反的原因。
1M context is a trap for idle sessions
1M 上下文是给「闲置会话」挖的坑
The 1M window costs the same as 200K, but one idle gap over an hour invalidates a much larger accumulated cache, forcing a proportionally larger full rebuild — which is why the team is reportedly considering lowering the default to 400K.
1M 窗口和 200K 同价，但一旦中间闲置超过一小时，失效的缓存量也成倍放大，触发的全量重建代价随之放大——这也是团队考虑把默认上下文从 1M 降到 400K 的原因。
Detailed Summary详细解读
The piece opens with a counter-intuitive phenomenon: many users treat frequent /clear or a new session per step as 'traveling light,' when in fact this often triggers a full-price context rebuild that costs more than continuing. Rather than staying at the surface, the author digs into the mechanism first — an LLM has no memory; every message forces it to reprocess the fixed part (system prompt, tool defs, CLAUDE.md), the conversation history, and the new message from scratch, with cost proportional to length. The library analogy (re-reading a 500-page report every visit) sets up everything that follows about caching.
The second layer of argument introduces the mechanics of prompt caching: after reading input, the model produces intermediate computation results ('reading notes') that later generation reuses instead of re-scanning the original text, at roughly 1/10th the cost of recomputation — a 20-turn, 100K-token session with a consistently hot cache can cut input costs by more than 6x versus paying full price every time. But two constraints are immediately flagged: caching only works on exact-match prefixes (one changed character upstream invalidates everything downstream), and it has a TTL (1hr for the main agent, 5min for sub-agents, 5min by default for API users), refreshed on every hit. These constraints explain why Claude Code's input is structured with static content first and new messages last — a cache-friendly layout, not an arbitrary formatting choice.
The third layer is the article's central pivot: translating the caching mechanism into three counter-intuitive money-saving rules. First, continuing a live session beats starting fresh while the cache is warm, because a new session pays full write-price for roughly 50K tokens of 'infrastructure' (system prompt, tool defs); the operative word, per Anthropic's Lydia Hallie, is idle time, not duration. Second, a complex task solved in one pass with extended thinking often costs less than three cheap retries with thinking disabled, since each extra turn re-sends the whole context — the accumulated cost of retries can exceed one deep-thinking pass; simple tasks flip this, where disabling thinking is the right call. Third, feed file paths rather than pasting long content, letting Claude grep for what it needs — 'the cheapest token is one that never enters the context at all.'
The fourth layer operationalizes the strategy into a decision table: stay in the current session if the task hasn't changed, the last message was under an hour ago, or prior context is still useful; start fresh if the task has switched, idle time exceeds an hour, or the context is cluttered with irrelevant content. This table grounds the abstract caching principles in an actionable rule, and corrects a common misreading of 'one task per session' as 'clear after every step' — the real boundary is the task, not the step.
The fifth layer tackles the 1M context window as a specific counter-intuitive trap: although the 1M window has carried no price premium since March 2026, it's becoming a leading cause of quota exhaustion — a long accumulated session left idle over an hour returns to find the entire 1M-token cache expired, so a single message triggers a full rebuild whose cost scales with window size. The author cites community data that most sessions hit compaction at 80-120K anyway, quality degrades noticeably past 200K, and results above 350K are essentially luck — landing on a compromise recommendation to keep the 1M window but set a conservative auto-compact threshold, with concrete settings.json snippets.
The final layer extends into six operational rules and delegation strategies: use Sonnet for daily work, never switch models mid-session (caches are model-specific, so switching resets to zero), keep CLAUDE.md under 200 lines and move occasional-use instructions into skills, prefer CLI tools over MCP servers (MCP injects full schema definitions on both request and response), spend tokens planning upfront on complex tasks to avoid costly re-scans after a wrong turn, and use permissions.deny to exclude noise paths like node_modules. It also debunks several community myths (context past 256K burning faster, the malware-check prompt wasting tokens, anomalous adaptive-thinking consumption), and distinguishes agent teams (roughly 7x a standard session's cost) from sub-agents (isolated context, shorter cache window but savings in the main session) — warning readers not to equate concurrency with cheapness.
文章的起点是一个反直觉的现象：很多用户以为频繁 /clear 或每步一开新会话是“轻装上阵”，实际上这个操作经常触发一次全价的上下文重建，花的钱比继续聊下去还多。作者没有停留在现象层面，而是先追问底层原理——大语言模型处理输入的方式和人类的“接着读”完全不同，它没有记忆，每次收到消息都要把固定部分（系统指令、工具定义、CLAUDE.md）、对话历史、新消息这三部分从头处理一遍，耗时和长度成正比。这个类比（每次都重新翻一遍 500 页的书）为后文的缓存机制铺好了地基。
第二层论证引入提示缓存的具体机制：模型读完输入后生成一组中间计算结果（相当于“阅读笔记”），后续生成时直接用笔记而不回头看原文，命中成本约为重新计算的十分之一，一个 20 轮、10 万 Token 的会话如果缓存持续命中，输入成本能比每次全价处理低 6 倍以上。但作者立刻限定了两个前提：缓存只对精确匹配的前缀有效（前面改一个字，后面全部失效），且有存活时间（主智能体 1 小时、子智能体 5 分钟，API 用户默认仅 5 分钟），每次命中会刷新计时器。这两条限制解释了为什么 Claude Code 把不变内容放最前面、新消息放最后——这是缓存友好的结构设计，不是随意的排版选择。
第三层是全文的核心转折：把缓存机制翻译成三条反直觉的省钱策略。其一，缓存还热时继续聊比开新会话便宜，因为新会话要为系统提示、工具定义等约 5 万 Token 的“基础设施”重新付全价写入费；关键词是 Lydia Hallie 说的“闲置”而非“时长”。其二，复杂任务开着扩展思考一次做对，往往比关掉思考来回改三轮更省，因为每多一轮整个上下文都要重发一次，累积成本容易超过一次深度思考的额外开销；简单任务则相反，该关思考就关。其三，长内容给文件路径而不是贴进对话，让 Claude 自己用 grep 之类工具按需检索，“最便宜的 Token 永远是根本没进上下文的 Token”。
第四层把策略具体化为一张决策表：任务没变、距上条消息不超过 1 小时、上下文内容仍有用——满足任一条就继续当前会话；任务已换、闲置超过 1 小时、上下文被无关内容塞满——满足任一条就开新会话。这张表把前面抽象的缓存原理落到了可操作的判断标准上，也纠正了“一个会话只做一件事”被简化理解为“每步都清空”的误读——真正的边界是任务粒度，不是步骤粒度。
第五层专门处理 1M 上下文窗口这个“反常识陷阱”：虽然 2026 年 3 月起 1M 窗口和 200K 同价，但正在成为很多人配额见底的头号原因——积累了很长的会话后离开电脑超过一小时，回来时整整 1M Token 的缓存全部过期，一条消息就触发全量重建，代价随窗口线性放大。作者引用社区经验数据：多数日常会话在 80-120K 就会触发压缩，超过 200K 表现明显下降，350K 以上基本靠运气，因此给出“保留 1M 但设保守自动压缩阈值”的折中建议，并给出具体的 settings.json 配置。
最后一层扩展到六条操作规则和委派策略：日常用 Sonnet、别在会话中途换模型（缓存按模型隔离，切换等于清零）、CLAUDE.md 控制在 200 行内并把偶发性说明挪到技能里、命令行优先于 MCP（后者把结构定义注入上下文两端都花钱）、复杂任务先花 Token 做计划避免走错方向后的重扫重写、用 permissions.deny 排除 node_modules 等噪音路径。同时澄清了社区流传的几个误解（256K 后消耗变快、恶意软件检测提示浪费 Token、自适应思考异常消耗），并把智能体团队（约 7 倍标准会话消耗）与子智能体（隔离上下文、缓存窗口更短但省主会话空间）做了区分，避免读者把“并发”和“便宜”画等号。
FAQ常见问答
When would continuing a session actually cost more than starting fresh?为什么继续聊有时候比开新会话更贵？
When the context is cluttered with irrelevant content — abandoned approaches, unrelated files read along the way — even a cache hit means the model must find signal in noise, quality drops, and compaction risks dropping key details. That's when a fresh session beats continuing.
当上下文已被大量无关内容塞满（试了十几种方案、读了大量无关文件），即使缓存命中，模型也要在噪音里找信号，输出质量下降，压缩时还可能丢关键信息——这时该开新会话，而非继续为噪音付费。
Should I actually use the 1M context window?1M 上下文窗口到底该不该用？
It's suited to loading a large codebase for a global refactor, or a long session you don't want interrupted by compaction — but not everyday coding/debugging, and an idle gap over an hour invalidates the entire cache, with rebuild cost scaling with window size. The recommendation is to keep it but set a conservative auto-compact threshold.
它适合一次性加载大型代码库做全局重构、或不想被压缩打断的长会话，但日常写代码改 bug 用不上，而且一旦闲置超过一小时缓存全部过期，重建代价会随窗口大小线性放大，作者建议保留但设保守的自动压缩阈值。
Is the '256K threshold causes faster burn' claim related to caching mechanics?缓存机制和「上下文超过 256K 消耗变快」的说法是什么关系？
The Claude Code team has clarified this claim is false. The likely real cause is users resuming long-idle sessions, triggering a large-scale cache miss that gets misattributed to context length itself, rather than length having an actual threshold effect.
Claude Code 团队已澄清这个说法不成立；真实原因很可能是用户重启了闲置已久的会话，触发大规模缓存未命中，被误归因于上下文长度本身，而不是长度这个变量真的有阈值效应。
How do sub-agents differ from agent teams in terms of cost?子智能体和智能体团队在省钱上有什么区别？
Sub-agents have isolated contexts and return only a summary to the main session, keeping verbose output out of it, though their cache window is just 5 minutes. Agent teams, by contrast, run each member as an independent instance maintaining its own context — planning-mode usage runs roughly 7x a standard session, so concurrency doesn't mean cheaper.
子智能体有独立上下文，完成后只返回摘要给主会话，能隔离掉详细输出，缓存窗口仅 5 分钟；智能体团队里每个成员都是独立实例各自维护上下文，计划模式下消耗约为标准会话的 7 倍，并发不等于便宜。
What do the settings.json snippets in the article actually configure?文中给出的 settings.json 配置具体做什么？
Setting CLAUDE_CODE_DISABLE_1M_CONTEXT to 1 disables the 1M window; setting CLAUDE_CODE_AUTO_COMPACT_WINDOW to 200000 triggers automatic summarizing compaction as context approaches 200K tokens, preserving continuity while capping runaway cost.
CLAUDE_CODE_DISABLE_1M_CONTEXT 设为 1 可禁用 1M 窗口；CLAUDE_CODE_AUTO_COMPACT_WINDOW 设为 200000 可让上下文接近 20 万 Token 时自动压缩摘要化，在保留连续性的同时防止成本失控。
In-depth Analysis · Pros & Cons深入解读 · 优缺点
This piece reframes Claude Code's token-burn problem as a caching-mechanics issue, not a discipline issue. It replaces the common '/clear often' instinct with a rule derived from how prefix caching actually works: keep sessions alive while the cache is warm, split only when the task or the clock genuinely changes.
这篇文章把 Claude Code 配额消耗问题，从“要不要自律”重新定义为“是否理解缓存机制”。它用前缀缓存的实际运作方式，推翻了“频繁 /clear”的直觉，给出一条新规则：缓存还热就继续聊，只有任务真正切换或缓存过期时才开新会话。
- Mechanism-first explanatory power机制先行的解释力The piece doesn't stop at 'what to do' — it first explains prompt caching's mechanics (prefix matching, TTL) in enough depth that every recommendation can be derived from first principles, letting readers judge edge cases rather than memorize rules.文章没有停在“怎么做”，而是先讲透提示缓存的运作原理（前缀匹配、存活时间），让每条建议都能从机制反推出来，读者能自己判断边界情况，而不是死记规则。
- The decision table operationalizes the theory决策表把抽象原理落地The continue-vs-new-session criteria are compressed into a clear conditional checklist that's immediately actionable, closing the common gap between 'understanding the theory' and 'knowing what to actually do.'继续聊 vs 开新会话的判断标准被压缩成清晰的条件列表，直接可执行，避免了“理解了原理但不知道怎么用”的常见落差。
- Actively debunks community myths主动澄清社区误解The article cites the Claude Code team's official responses to myths like the '256K threshold' and the malware-check prompt, steering readers away from plausible-but-wrong explanations and raising overall credibility.文章引用了 Claude Code 团队对“256K 阈值”“恶意软件检测提示”等流言的官方回应，避免读者被似是而非的解释带偏，提升了整体可信度。
- Concrete, copy-pasteable configuration给出可复制的具体配置Specific settings.json fields (disabling 1M, setting the auto-compact threshold, permissions.deny paths) let readers act immediately, rather than settling for vague advice like 'you should manage your context carefully.'settings.json 的具体字段（禁用 1M、设置自动压缩阈值、permissions.deny 路径）让读者能立刻落地，而不是停留在“应该注意上下文管理”这类空泛建议。
- Cache-savings multiples lack sourcing缓存倍数缺乏来源支撑Specific figures like 'more than 6x savings' or 'Codex uses about a third the tokens' come mostly from community estimates or single cases, without a stated methodology, making it hard to know how broadly they apply.“6 倍以上”“Codex 省三分之一 Token”等具体数字多来自社区估算或单一案例，没有给出计算方法或统计口径，读者难以判断适用范围。
- Team plans are still in flux团队计划仍在变化中The claim that the team is 'considering' lowering the default context from 1M to 400K is an unshipped plan; the default could change after publication, and readers need to verify the current state themselves.文中提到团队“正在考虑”把默认上下文从 1M 降到 400K，这是未落地的计划，文章发布后配置默认值随时可能变化，读者需要自行核实当前状态。
- The decision table skips ambiguous middle cases决策表未处理模糊地带Criteria like 'the task hasn't changed' or 'context is still useful' are themselves subjective, and the piece offers no method for detecting when a task has quietly drifted — the real-world boundary is fuzzier than the table suggests.“任务没变”“上下文仍有用”这类判断标准本身带有主观性，文章没有给出如何量化或识别“任务已经悄悄漂移”的方法，实践中边界会比表格呈现的更模糊。
- Relies on third-party and internal claims with uncertain shelf life依赖第三方与内部信息，时效性存疑The Codex plugin's savings claim comes from 'user feedback' rather than systematic benchmarking, and the $134 AWS Bedrock cost estimate is a single anecdote — as pricing and models iterate, these specific figures could go stale quickly.Codex 插件的省钱效果来自“有用户反馈”而非系统评测，AWS Bedrock 134 美元的成本估算也是个案，随着定价和模型迭代，这些具体数字可能很快过时。
This piece is best read by developers who use Claude Code heavily and are confused about where their quota is going — it offers not a checklist of tricks but a principled framework readers can extend to their own edge cases. The caveat: several figures come from community estimates rather than official benchmarks, and the mentioned default change (1M→400K) hasn't shipped, so treat specific numbers as directional rather than exact, and re-check current official settings periodically.
这篇文章适合每天高频使用 Claude Code、又对配额消耗感到困惑的开发者阅读——它提供的不是“省钱技巧清单”，而是一套能自己推导边界情况的原理框架。局限在于部分数字来自社区估算而非官方基准测试，且提到的默认值调整（1M→400K）尚未落地，读者应把具体数字当作方向性参考，而非精确保证，并定期核实当前的官方配置状态。
Original Text原文
The English text on this side is an AI translation provided for convenience; the authoritative version is the source in the other language.
There's been a lot of grumbling in the community recently: quotas are burning through way too fast. Some Max users are exhausting a week's allowance in two days. Someone ran the numbers on AWS Bedrock and found the real cost of a single session exceeded $134, while a Pro Max 5x subscription is only $100 a month. Anthropic's subscriptions themselves are being sold at a loss.
Many people's first instinct is to run /clear frequently, or start a new session after every step, thinking this 'traveling light' approach saves money. But once you understand the caching mechanism behind Claude Code, you realize this habit often backfires: you've just triggered a full-price context rebuild, which costs more than continuing the conversation would have.
The model 're-reads' everything every time
To understand why quotas burn so fast, you first need to understand how large language models process input — it's nothing like how humans 'keep reading.'
Imagine you're writing a paper on climate change, and every time you visit the library you have to do the same thing: find that 500-page Global Climate Report, flip to the section you need, and copy down the key data. The first time takes 40 minutes. The second time, you ask a different question, but it's the same book — another 40 minutes. Third time, fourth time, same 40 minutes each.
That's exactly what large language models do. They have no 'memory' — they don't skip something just because they just read it. Every time it receives your message, it has to 're-read' the entire input from scratch, and the time this takes is proportional to the length of the content.
In Claude Code, the input typically consists of three parts:
Fixed part: system instructions, tool definitions, project rules from CLAUDE.md
Conversation history: all previous turns of the conversation
New message: the line you just typed
The first two parts barely change within the same session, but the model has to 're-read' them every single time. After 20 turns of conversation, every new message might be carrying 100,000 tokens of 'old baggage' — slow and expensive.
Prompt caching: storing the 'notes'
Having to flip through that 500-page book from scratch every single time is unbearable for anyone. The solution is straightforward: prepare the notes in advance, and next time just flip through the notebook.
That's exactly what prompt caching does.
After the model reads through a segment of input, it generates a set of intermediate computation results — equivalent to 'reading notes.' When generating a subsequent response, the model relies on this set of notes rather than going back to the original text. The mechanism of prompt caching is: after computing the notes the first time, they're saved; the next time the same input prefix is encountered, the saved notes are used directly, skipping the redundant computation.
The cost of reading from cache is only one-tenth the cost of recomputing.
A rough calculation: for a 20-turn session with 100,000 tokens of context, if the cache keeps hitting, the input cost is more than 6 times lower than processing everything at full price each time.
But caching has two preconditions.
First, caching only works on 'prefixes.' It has to match exactly, character for character, from the beginning.
Here's an analogy: you write an essay on paper, and the first 3 pages match exactly, but on page 4 you change one word. Only the first 3 pages can use the cache — from page 4 onward everything has to be recomputed. And if you changed a word on page 1? The entire cache is invalidated, and everything is recomputed from scratch.
That's why the structure of Claude Code's input matters: unchanging content like system instructions and tool definitions goes at the very front, conversation history in the middle, and the new message at the end. Each turn only needs to recompute that small trailing segment, while the large preceding chunk can hit the cache.
Within the same active session, the prefix is naturally consistent, and each turn just appends new content at the end, so the cache hit rate is high. But if you start a new session, the prefix starts from zero, and all the cache accumulated before becomes useless.
Second, caches have a time-to-live. According to the Claude Code team, the main agent's cache window is 1 hour, while subagents get 5 minutes. API users get only 5 minutes by default (you can pay to enable 1 hour, but it's more expensive). Every cache hit refreshes the timer, so as long as you keep interacting frequently, the cache can stay alive indefinitely.
In the Claude Code team's own words:
"Claude Code is the framework with the highest cache utilization."
But the cost of a cache miss increases sharply as context length grows. A cache miss on 200K context and a cache miss on 1M context are completely different orders of magnitude in expense.
Three counterintuitive money-saving strategies
Once you understand caching, some 'common sense' needs to be flipped on its head.
While the cache is still warm, continuing to chat is cheaper than starting a new session
Every time Claude Code starts a new session, it has to reload the system prompt, tool definitions, CLAUDE.md, and project configuration. This 'infrastructure' amounts to roughly 50,000 tokens. Running /clear frequently is equivalent to repeatedly paying the full write price for this unchanging content.
Whereas in an active session, this content stays in cache the whole time, and each request only costs one-tenth the price.
When Anthropic employee Lydia Hallie said 'for large sessions that have been idle for about an hour, it's recommended to start fresh,' the key word is 'idle.' For a session in active work, the cache stays hot the whole time, so continuing to chat is actually the most economical option.
Getting a complex task right in one pass is cheaper than three rounds of back-and-forth revisions
Turning off extended thinking does save tokens on a single request. But for a complex refactoring task, doing it once with extended thinking on versus turning it off and going back and forth for three rounds of revisions — the latter is very likely to be more expensive. Because with every additional conversation turn, the entire context has to be resent, and the tokens accumulated over three rounds far exceed the extra cost of one round of deep thinking.
For simple tasks, it's the opposite. Turning /effort down or disabling thinking mode in /config produces an immediate effect. Thinking tokens are billed at the output rate, and for simple tasks the default budget is clearly wasteful.
For long content, give a path — don't paste it into the conversation
More effective than controlling output length is controlling input quality. Don't copy-paste 10,000 lines of logs into the conversation and ask Claude to find the error itself — just send it the log file's path. Claude Code will use tools like grep on its own to retrieve the information it needs, pulling only the relevant content into context. The cheapest token is always the one that never entered the context at all.
Continue chatting or start a new session: a decision table
This might be the single most critical judgment call for saving tokens in Claude Code. Many people's default habit is to 'clear as soon as done,' but the actually money-saving default should be the reverse: keep going by default, and starting a new session should be a conditionally triggered action.
Continue the current session if any of the following hold:
The task hasn't changed. You're still fixing the same bug, writing the same module, working around the same set of files.
It's been no more than an hour since the last message. The cache is still alive, so the accumulated context ahead barely costs anything.
The content in context is still useful for the current work. Files read earlier, solutions discussed earlier — the model is still using them.
If you're thinking things through and temporarily have no input, you can send a short message to keep the cache alive. Some users have even written a heartbeat extension to automatically keep the cache alive — refreshing the cache once costs only one-tenth of a full cache miss.
Start a new session if any of the following hold:
The task has changed. You just finished the authentication module and are now moving to the payments feature — the two have completely different contexts. The code files and debugging records piled up in the old session are useless for the new task, and every request would be paying for this irrelevant content.
It's been idle for more than an hour. The cache has most likely expired, so continuing to chat would trigger a full rebuild anyway — you might as well start from a clean state.
The context is stuffed with irrelevant content. You tried a dozen approaches, read a bunch of unrelated files, and this content is still taking up space. Even if the cache hits, the model has to find the signal amid the noise, output quality drops, and compaction might drop key information.
One-sentence summary: if the cache is still warm and the task hasn't changed, keep chatting. If the cache has expired, the task has switched, or there's too much noise in the context, restart decisively.
Some in the community have reported that a workflow of doing only one thing per session almost never runs into quota problems.
The 1M context window: use with caution
Starting March 2026, the Max, Team, and Enterprise plans default to Opus 4.6's 1M context window. Anthropic removed the 2x price premium for long context — the 1M window now costs the same as 200K.
But the 1M context is becoming the number one reason many people's quotas are running dry.
The problem lies in the cost of cache invalidation. You accumulate a very long session using the 1M context, then step away from the computer for more than an hour, and come back to continue chatting — at this point the entire 1M-token cache has expired, and a single message will trigger a full rebuild. The team has confirmed this issue and is considering lowering the default context from 1M to 400K.
Moreover, most everyday sessions trigger compaction at around 80-120K context — they never even reach 200K, let alone 1M. Community data points to the same conclusion: model performance drops noticeably once context exceeds 200K, and beyond 350K it's basically down to luck.
There are indeed scenarios suited to 1M: loading an entire large codebase at once for a global refactor, or long multi-turn conversations you don't want interrupted by compaction. But everyday coding and bug-fixing doesn't need it.
My suggestion: keep the 1M window but set a conservative auto-compaction threshold, balancing flexibility with efficiency.
If you want to disable the 1M context window, add this to ~/.claude/settings.json:
If you want to set a threshold for auto-compacting context:
When context approaches 200,000 tokens, it auto-compacts into a summary — preserving context continuity while preventing costs from spiraling out of control.
Six operating rules
1. Use Sonnet for everyday work
Opus's input cost is roughly 1.7 times that of Sonnet, but more critically, Opus burns through tokens at roughly twice the rate of Sonnet. Instead of spending a lot of time figuring out how to get Opus to say less, many teams should first ask: does this actually need Opus? Sonnet is enough for most coding tasks; save Opus for complex architectural decisions and multi-step reasoning. Type /model in Claude Code to switch.
2. Don't switch models mid-session
Prompt caching is isolated per model. If you've built up 100,000 tokens of cache on Opus, then switch to Sonnet to ask a simple question, Sonnet has to build its own cache from zero. In that case, having Opus answer directly actually costs less than switching to the 'cheaper' Sonnet. For scenarios where you need a lightweight model, use a subagent rather than switching the main model.
3. Trim CLAUDE.md, control the number of skills
The content of CLAUDE.md gets injected into every single request. The official recommendation is to keep it under 200 lines, retaining only rules that are genuinely valid long-term. Long instructions needed only at specific moments — like code review workflows or database migration steps — should be moved into skills; skills are only loaded on invocation by default and don't occupy context ahead of time.
But more skills isn't always better either. Loading too many skills and agents is a hidden killer of quota consumption, and the team is working on making this consumption more visible in the interface. Put skills in the project directory (.claude/skills/) rather than the global directory, installing only what the current project actually needs. Also remember to turn off any MCP services that aren't in use.
One small trick: write maintainer notes in CLAUDE.md using HTML comments — Claude strips out comments before injecting context, so they don't cost any tokens.
4. Prefer the command line over MCP
GitHub's gh command-line tool consumes far fewer tokens than the GitHub MCP server. MCP tools inject the full schema definitions into context, and both the request and response sides cost tokens. Whatever can be handled via the command line, don't install an MCP for it.
5. Spend a few tokens up front on planning
For complex tasks, entering plan mode first — letting Claude explore the code and propose an approach before implementing — often produces lower total cost. What's truly expensive is re-scanning the code, rewriting the implementation, and rerunning tests after going in the wrong direction.
The same goes for how you phrase requests: a vague prompt like 'help me optimize this codebase' triggers a broad scan; a specific instruction like 'add input validation to the login function in auth.ts' significantly reduces file reads and trial-and-error.
6. Use permissions.deny to restrict the model's reading scope
An unindexed codebase forces the model to search through files to find context, which is extremely inefficient. In .claude/settings.json, use permissions.deny to strictly limit what the model can read — for example, excluding node_modules, build artifacts, and large data files:
Files matching these patterns are excluded from file discovery and search results, and read operations are directly denied. The model can sometimes get stuck in codebase search loops lasting more than 5 minutes — even when you specify the file path, it may still repeatedly read unrelated files in the background. permissions.deny cuts off this kind of waste at the source.
Delegate part of the work elsewhere
Two delegation approaches can reduce token consumption in the main session.
Subagents: Claude Code's subagents have independent context and, once done, return only a brief summary to the main session. A subagent's cache window is only 5 minutes (versus 1 hour for the main agent), so cache utilization per call is lower. But its value lies in context isolation: the detailed output from work like code review, running tests, or checking documentation doesn't linger in the main session, so subsequent messages don't have to pay for that content.
Agent teams are different from subagents. In an agent team, every member is an independent Claude instance maintaining its own context window. In plan mode, an agent team's token consumption is several times that of a standard session (community estimates put it around 7x), and idle members keep consuming tokens too. Concurrent speedup comes at a cost — more agents doesn't mean cheaper.
Codex plugin: if you also have an OpenAI subscription, some in the community use openai/codex-plugin-cc to offload some tasks. This is a third-party community solution, and some users report Codex completes equivalent tasks using roughly a third the tokens of Claude Code, though results vary by task. Well-suited for delegation: structured bug fixes, code review, writing tests. Best left to Claude Code: architectural design, cross-file refactoring, complex work that requires understanding the whole codebase.
Installation method:
Some misconceptions worth clarifying
The community has been circulating various claims about quota consumption, and the Claude Code team offered official clarification during a discussion.
The most widespread claim is that "consumption speeds up once context exceeds 256K." The official response was direct: this is not true. The likely real cause is that users restarted sessions that had been idle for a long time, triggering large-scale cache misses that got misattributed to context length.
Others complained that the model checks for malware every time it reads a file, wasting tokens. This security-detection prompt has existed since Sonnet 3.7, and every new model has been evaluated against it without causing regressions. Opus 4.6 has already removed this prompt. As for "adaptive thinking causing abnormal quota consumption," the team has also ruled that out. The team said it hasn't blindly trusted internal metrics and is still investigating:
"We're taking this seriously and continuing to investigate. We haven't blindly trusted our internal metrics."
The core idea for saving tokens comes down to one sentence: get the cache hit as often as possible, and keep as little irrelevant content in the context as possible.
Starting a new session is just a means to an end — once you understand prompt caching, you'll realize that "continuing to work in an active session" is the default strategy, while "starting a new session" is an optimization triggered only under specific conditions.
Many in the community are comparing whose quota is more generous among Claude Code, Codex, and Cursor. But quota tightening may be an industry-wide trend — some say we're in the "late stage of the subsidized-compute era," similar to the days of $3 Uber rides. Rather than betting on which company subsidizes longer, it's better to understand the cost structure and spend money where it counts.
How long do your sessions usually run? Do you have a habit of running /clear frequently because you're afraid to keep chatting?
最近社区里怨声载道：配额烧得太快了。Max 用户一周的额度，有人两天就用完。有人在 AWS Bedrock 上算了一笔账，一个会话的真实成本超过 134 美元，而 Pro Max 5x 订阅一个月才 100 美元。Anthropic 的订阅本身就是亏本在卖。
很多人的第一反应是频繁 /clear，或者每做完一步就开新会话。觉得这样"轻装上阵"能省钱。但如果你理解了 Claude Code 背后的缓存机制，会发现这个操作经常适得其反：你刚刚触发了一次全价上下文重建，花的钱比继续聊下去还多。
模型每次都在"从头读"
要理解配额为什么烧得快，得先搞清楚大语言模型处理输入的方式——它跟人类的“接着读”完全不同。
想象你在写一篇关于气候变化的论文，每次去图书馆都要做同一件事：找到那本 500 页的《全球气候报告》，翻到需要的章节，把关键数据抄下来。第一次花 40 分钟，第二次问了个不同的问题，还是同一本书，又花 40 分钟。第三次、第四次，同样的 40 分钟。
大语言模型干的就是这件事。它没有“记忆”，不会因为刚读过就跳过。每次收到你的消息，它都要从头“读”一遍完整的输入内容，读的时间和内容长度成正比。
在 Claude Code 里，输入内容通常包括三部分：
固定部分：系统指令、工具定义、CLAUDE.md 里的项目规则
对话历史：之前所有的对话轮次
新消息：你刚刚输入的那句话
前两部分在同一个会话里几乎不变，但模型每次都要重新"读"一遍。聊了 20 轮之后，每条新消息可能要带上 10 万个 Token 的"旧行李"，既慢又贵。
提示缓存：把"笔记"存起来
每次都从头翻那本 500 页的书，任谁都受不了。解决办法很直接：把笔记提前做好，下次只翻笔记本。
提示缓存干的就是这件事。
模型读完一段输入后，会生成一组中间计算结果，相当于"阅读笔记"。后续生成回答时，模型靠的就是这组笔记，不会再回去看原文。提示缓存的机制是：第一次算完笔记后存下来，下次再遇到相同的输入前缀，直接用存好的笔记，跳过重复计算。
读取缓存的成本只有重新计算的十分之一。
粗略算一下：一个 20 轮的会话，10 万 Token 的上下文，缓存一直命中的话，输入成本比每次都全价处理低 6 倍以上。
但缓存有两个前提条件。
第一，缓存只对"前缀"有效。 必须从头开始、一字不差地匹配。
打个比方：你在作文纸上写了一篇文章，前 3 页一字不差，第 4 页改了一个字。只有前 3 页能用缓存，第 4 页开始就得重新计算。如果你在第 1 页就改了一个字？整个缓存全部失效，从头算。
所以 Claude Code 的输入结构很重要：系统指令、工具定义这些不变的内容放在最前面，对话历史在中间，新消息放在最后。每次只有末尾那一小段需要重新计算，前面一大段都能命中缓存。
在同一个活跃会话里，前缀天然一致，每一轮只是在尾部追加新内容，缓存命中率很高。但如果你开了一个新会话，前缀从零开始，之前积累的缓存全部用不上。
第二，缓存有存活时间。 根据 Claude Code 团队的说明，主智能体的缓存窗口是 1 小时，子智能体是 5 分钟。API 用户默认只有 5 分钟（可以付费开启 1 小时，但更贵）。每次缓存命中都会刷新计时器，只要你保持交互频率，缓存可以一直活着。
Claude Code 团队的原话：
"Claude Code 是缓存利用率最高的框架。"
但缓存未命中的代价，随上下文长度增大而急剧增加。一个 200K 的缓存未命中和一个 1M 的缓存未命中，完全是两个量级的开销。
三个反直觉的省钱策略
理解了缓存之后，有些"常识"要翻过来。
缓存还热的时候，继续聊比开新会话便宜
Claude Code 每次新会话启动，都要重新加载系统提示、工具定义、CLAUDE.md、项目配置。这些"基础设施"大约 5 万 Token。频繁 /clear 等于反复为这些不变的内容付全价写入费。
而在活跃会话里，这些内容一直在缓存中，每次只付十分之一的价格。
Anthropic 员工 Lydia Hallie 说的"闲置约一小时的大型会话，建议重新开始"，关键词是"闲置"。活跃工作中的会话，缓存一直是热的，继续聊才最省。
复杂任务一次做对，比来回改三轮更省
关掉扩展思考确实能在单次请求里省 Token。但一个复杂的重构任务，开着扩展思考一次搞定，和关掉之后来回改三轮，后者更贵的概率很大。因为每多一轮对话，整个上下文都要重新发送一次，三轮累积的 Token 远超一次深度思考的额外开销。
简单任务反过来。把 /effort 调低或者在 /config 里关掉思考模式，效果立竿见影。思考 Token 按输出价计费，默认预算对简单任务来说浪费明显。
长内容给路径，别往对话里贴
比起控制输出长度，更有效的是控制输入质量。不要把 10000 行日志复制粘贴到对话里让 Claude 自己找错误，直接把日志文件路径发给它。Claude Code 会自己用 grep 之类的工具去检索需要的信息，只把相关内容拉进上下文。最便宜的 Token，永远是根本没进上下文的 Token。
继续聊还是开新会话：一张决策表
这可能是 Claude Code 省 Token 最关键的一个判断。很多人的默认习惯是"做完就清"，实际上最省的默认习惯应该反过来：能继续就继续，开新会话是有条件触发的操作。
满足以下任一条件，继续当前会话：
任务没变。还在调同一个 bug、写同一个模块、围绕同一组文件工作。
距离上一条消息不超过 1 小时。缓存还活着，前面积累的上下文几乎不花钱。
上下文里的内容对当前工作仍然有用。之前读过的文件、讨论过的方案，模型还在用。
如果在思考问题暂时没有输入，可以发一条简短消息保持缓存活跃。有用户甚至写了心跳扩展来自动保活缓存，刷新一次缓存的成本只有完整缓存未命中的十分之一。
满足以下任一条件，开新会话：
任务换了。刚写完认证模块要做支付功能，两件事的上下文完全不同。老会话里堆的代码文件、调试记录对新任务毫无用处，每条请求都在为这些无关内容付费。
闲置超过 1 小时。缓存大概率已经过期，继续聊等于触发全量重建，还不如从干净状态开始。
上下文被不相关内容塞满。试了十几种方案、读了大量无关文件，这些内容还在占位。即使缓存命中，模型也要在噪音里找信号，输出质量下降，而且压缩后可能丢掉关键信息。
一句话总结：缓存还热、任务没换，继续聊。缓存过期、任务切换、上下文里噪音太多，果断重开。
社区里有人反馈，一个会话只做一件事的工作方式，几乎不会触发配额问题。
1M 上下文窗口：慎用
从 2026 年 3 月起，Max、Team、Enterprise 计划默认使用 Opus 4.6 的 1M 上下文窗口。Anthropic 取消了长上下文的 2 倍价格溢价，1M 窗口和 200K 同价。
但 1M 上下文正在成为很多人配额见底的头号原因。
问题出在缓存失效的代价上。你用 1M 上下文积累了一个很长的会话，中间离开电脑超过 1 小时，回来继续聊，这时候 1M Token 的缓存全部过期，一条消息就要触发全量重建。团队确认了这个问题，正在考虑将默认上下文从 1M 降到 400K。
而且大多数日常会话在 80-120K 上下文时就会触发压缩，根本用不到 200K，更别说 1M。社区里的经验数据也指向同一个结论：上下文超过 200K 后模型表现明显下降，350K 以上基本靠运气。
适合 1M 的场景确实存在：一次性加载大型代码库做全局重构、长时间多轮对话不想被压缩打断。但日常写代码改 bug 用不上。
我的建议：保留 1M 窗口但设一个保守的自动压缩阈值，兼顾灵活性和效率。
如果你想禁用 1M 上下文，在 ~/.claude/settings.json 中添加：
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}如果你想设置自动压缩上下文的阈值：
{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
}
}上下文接近 20 万 Token 时自动压缩摘要化，既保留上下文连续性，又防止成本失控。
六条操作规则
一、用 Sonnet 做日常工作
Opus 的输入成本大约是 Sonnet 的 1.7 倍，但更关键的是 Opus 消耗 Token 的速度大约是 Sonnet 的两倍。很多团队花大量时间研究怎么让 Opus 少说点，不如先问一句：这件事真的需要 Opus 吗？大多数编码任务 Sonnet 就够了，Opus 留给复杂架构决策和多步推理。在 Claude Code 里输入 /model 切换。
二、别在会话中间换模型
提示缓存按模型隔离。你在 Opus 上积累了 10 万 Token 的缓存，切到 Sonnet 问个简单问题，Sonnet 要从零建立自己的缓存。这时候让 Opus 直接回答，反而比切到"更便宜"的 Sonnet 花得少。需要用轻量模型的场景，用子智能体而非切换主模型。
三、精简 CLAUDE.md，控制技能数量
CLAUDE.md 的内容会注入到每一次请求里。官方建议控制在 200 行以内，只保留真正长期有效的规则。代码审查流程、数据库迁移步骤这类只在特定时刻需要的长说明，挪到技能里去；技能默认只在调用时加载，不会提前占上下文。
但技能也不是越多越好。加载太多技能和智能体是配额消耗的一个隐形杀手，团队正在改进界面让这些消耗更可见。技能放在项目目录（.claude/skills/）而非全局目录，只装当前项目真正需要的。没在用的 MCP 服务也记得关掉。
一个小技巧：在 CLAUDE.md 里用 HTML 注释写维护者备注，Claude 注入上下文前会把注释剥掉，不花 Token。
四、命令行优先，MCP 其次
GitHub 的 gh 命令行工具比 GitHub MCP 服务器消耗的 Token 少得多。MCP 工具会把完整的结构定义注入上下文，请求和响应两端都在花 Token。能用命令行解决的事，别装 MCP。
五、先花一点 Token 做计划
复杂任务先进入计划模式，让 Claude 先探索代码、提出方案，再进入实施，总成本往往更低。真正昂贵的是方向错了以后重扫代码、重写实现、重跑测试。
提问也是一样：「帮我优化这个代码库」这种模糊提示会触发广泛扫描；「给 auth.ts 里的 login 增加输入校验」这种具体指令，文件读取和试错都会显著减少。
六、用 permissions.deny 限制模型的阅读范围
没有索引的代码库会迫使模型通过文件搜索来寻找上下文，效率极低。在 .claude/settings.json 中用 permissions.deny 严格限制模型可读取的范围，比如排除 node_modules、构建产物、大型数据文件：
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./node_modules/**)",
"Read(./build)"
]
}
}匹配这些模式的文件会被排除在文件发现和搜索结果之外，读取操作也会被直接拒绝。模型有时候会陷入长达 5 分钟以上的代码库搜索循环，即便你指明了文件路径，它仍可能在背景中反复读取不相关文件。permissions.deny 能从源头减少这种浪费。
把部分工作委派出去
两个委派思路可以减少主会话的 Token 消耗。
子智能体：Claude Code 的子智能体有独立上下文，完成后只返回简短摘要给主会话。子智能体的缓存窗口只有 5 分钟（主智能体是 1 小时），每次调用的缓存利用率更低。但它的价值在于隔离上下文：代码审查、跑测试、查文档这些工作的详细输出不会留在主会话里，后续每条消息都不用为这些内容付费。
智能体团队和子智能体不同。智能体团队里每个成员都是独立 Claude 实例，各自维护自己的上下文窗口。计划模式下智能体团队的 Token 消耗是标准会话的数倍（社区估算约 7 倍），闲置的成员也在继续消耗。并发加速有成本，多智能体不等于更便宜。
Codex 插件：如果你同时有 OpenAI 订阅，社区里有人用 openai/codex-plugin-cc 把部分任务分出去。这是第三方社区方案，有用户反馈 Codex 完成同等任务大概只用 Claude Code 三分之一的 Token，但具体效果因任务而异。适合委派的：结构化的 bug 修复、代码审查、写测试。留给 Claude Code 的：架构设计、跨文件重构、需要理解整个代码库的复杂工作。
安装方式：
claude mcp add codex -- npx -y @openai/codex-plugin-cc一些被澄清的误解
社区里流传不少关于配额消耗的说法，Claude Code 团队在讨论中做了官方澄清。
流传最广的一条是"上下文超过 256K 之后消耗会更快"。官方回应很直接：这不是真的。 实际原因很可能是用户重启了闲置已久的会话，触发了大规模缓存未命中，被误归因于上下文长度。
还有人抱怨模型每次读文件都在检查是否为恶意软件，浪费 Token。这个安全检测提示从 Sonnet 3.7 就有了，每次新模型都做过评估，没有引发退化。Opus 4.6 已经移除了这个提示。至于"自适应思考导致配额消耗异常"，团队也已排除。团队表示没有盲目相信内部指标，仍在持续调查：
"我们在认真对待这件事，仍在持续调查。我们没有盲目相信内部指标。"
省 Token 的核心思路就一句话：让缓存尽可能多地被命中，让上下文尽可能少地装无关内容。
开新会话是手段，理解了提示缓存之后你会发现，"在活跃会话里继续工作"才是默认策略，"开新会话"是特定条件触发的优化操作。
社区里很多人在比较 Claude Code、Codex、Cursor 的配额谁更慷慨。但配额收紧可能是个行业趋势，有人说我们正处在"补贴算力时代的末期"，类似当年 Uber 3 美元打车的阶段。与其赌哪家补贴更久，不如搞清楚成本结构，把钱花在刀刃上。
你们平时一个会话大概多长？有没有因为不敢继续聊而频繁 /clear 的习惯？
See all posts