开了一整天的会话，问一行问题也要按整段对话付费

在大多数计费模型里，「问一句话」是一个很小的事。但在 Claude Code 里，同一句话的成本可以差几十倍——差别不在你问的是什么，而在你是在什么时候问的。

原因是官方在文档里写清楚的一条机制：Claude Code 会自动开启 prompt caching，把系统提示、文件内容、历史对话这些重复出现的部分缓存起来，下次以更低的缓存价重新读入。这本来是个省钱设计。但它同时意味着另一件事：你每问一句，那整段对话历史都会被重新读一遍并计费。所以一段开了八小时的会话，第十次提问的输入量不是一句话，而是这八小时累积的全部内容。

这篇把 Claude Code 官方成本文档里四条影响单次提问成本的机制摊开，再补上一类更隐蔽的问题——版本相关的显示误差，也就是「你看到的数字不是账单数字」。最后给出按场景的操作建议。数据于 2026 年 9 月 24 日重新核对官方文档。

本文方法：官方公开数据交叉核对，未做本地实测。所有数字均标注来源，核对日期见文末。

一、为什么「问一行」要按整段对话付费

先把计费的基本口径说清楚。Claude Code 官方文档的第一句话是：「Claude Code charges by API token consumption.」按 API token 消耗计费。这句话意味着两件事：成本以 token 计量，而 token 的单价由模型决定。

在此之上，官方文档列出了两项自动优化，原文是：「Claude Code automatically optimizes costs through prompt caching, which reduces costs for repeated content like system prompts, and auto-compaction, which summarizes conversation history when approaching context limits.」一项是缓存，一项是压缩。

prompt caching 的常规理解是「重复内容打折」。但官方在同一份文档里给了它另一半含义，这段话是本文整篇的出发点：

「With prompt caching, Claude Code re-reads that history at the cached token rate, so a one-line question in a session that has been open all day still draws usage for the whole conversation.」

拆开来看这句话包含三层信息。第一，历史会被重新读取，不是被复用而不计费；第二，读取按缓存价计费，比标准输入价便宜，但不是零；第三，触发这个重新读取的可以只是一行问题。

所以「缓存价」这个折扣率值得单独理解。它是折扣，不是豁免。一段累积到 20 万 token 的会话，即使全部命中缓存，你每问一句话都要为这 20 万 token 的缓存读取付费。而如果会话只有 5 千 token，同样的提问只需为 5 千 token 付费。这就是标题里那句话的机制来源——成本不取决于问题的大小，取决于会话的长度。

官方还给出了缓存会失效的条件，这一条对「开会前挂着、回来接着问」这种用法特别关键：

「Cache misses: your first message after a break longer than the cache lifetime misses the cache and reprocesses your full context. The lifetime is an hour on a subscription and drops to five minutes once you’re drawing on usage credits; on an API key or cloud provider, it’s five minutes by default.」

这段话里有三个数字：订阅状态下缓存活 1 小时，一旦开始消耗 usage credits 就降到 5 分钟，用 API key 或云厂商通道默认也是 5 分钟。命中缓存是打折价，未命中缓存是「reprocesses your full context」——整段上下文按标准价重算。所以中午去吃饭超过一小时再回来，第一句话的成本结构和前面那些话完全不同。而且这个降级是叠加的：当你因为超出配额而开始消耗 usage credits，缓存寿命同时从 1 小时缩短到 5 分钟，单位成本上升和缓存有效期缩短会同时发生。

二、四条把单次提问推贵的官方机制

除了缓存重读，官方文档里还有三条机制会影响单次提问的计费量。下面把它们和第一条并排列出来。

第二条值得单独展开，因为它最反直觉。/compact 是「压缩上下文」的操作，直觉上它应该是省钱的——把长历史换成短摘要。但官方明确说，压缩本身要先读完你要压缩的那段对话：「compacting a large context is itself a large request」。你为了省下未来的成本，先付了一笔接近全量的当前成本。会话越长，这笔一次性支出越大，而且它和随后那句提问是分开计费的。

官方在同一个位置给了替代方案，措辞很克制但对比很明确：「When you want a fresh start instead of continuity, /clear costs nothing.」——当你想要的是一个全新的开始、而不是延续上下文时，/clear 不产生成本。两个操作的区别不在「压缩」与「清空」，而在你要不要保留这段对话的连续性。

第三条是 CLAUDE.md。官方对它的定位很明确：会话开始时载入上下文。官方给的时长建议是「Aim to keep CLAUDE.md under 200 lines by including only essentials.」——控制在 200 行以内，只放必需的内容。

官方还解释了为什么这条建议不是「为了整洁」，而是为了成本：「If it contains detailed instructions for specific workflows (like PR reviews or database migrations), those tokens are present even when you’re doing unrelated work.」——即使你在做完全不相关的工作，那些针对特定流程的详细指令仍然在上下文里。这是一个按会话收取的固定开销，而它是否相关完全取决于你这次要做什么。官方给的替代方案是把专用指令挪进 skills：「Skills load on-demand only when invoked, so moving specialized instructions into skills keeps your base context smaller.」——技能只在被调用时按需加载。

第四条是唯一一条减项。官方原文：「MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool.」默认情况下只有工具名和服务器指令进入上下文，完整的工具定义要等到真正调用时才载入。官方配套给了一个自查动作：「Run /context to see what’s consuming space.」以及一条清理建议：「Run /mcp to see configured servers and disable any you’re not actively using.」

把四条放在一起看，能得出一个判断：Claude Code 的成本结构里，固定开销（CLAUDE.md）和累积开销（会话历史）是两条不同的曲线，而只有后一条会随会话时长失控。固定开销按会话收，一次几十到几百行；累积开销按 token 累加，不设上限地长。这也是为什么「及时开新会话」比「把 CLAUDE.md 精简 50 行」在长任务里的效果更大——不过两件事都该做。

三、会话长度与单次提问的计费输入

把第一部分的机制画成图，横轴换成一个具体的量：同一句提问在不同长度的会话里，需要重读多少上下文。

这张图要说的是比例的悬殊：一段累积到 20 万 token 的会话里，一句「这个变量名改成什么好」的提问，输入侧的重读量是 5 千 token 会话里的 40 倍。而模型给出的回答长度可能完全相同——你为一个同样长度的回答付了 40 倍的输入成本。

这里必须说明清楚：这张图是按官方机制推导的示意，不是实测。Claude Code 的实际计费输入还受缓存命中情况影响——命中按缓存价，未命中按标准价重算整段上下文，两者的倍数关系由官方单价决定，官方没有公布缓存价的具体折扣率。图里画的是「需要重读的上下文量」，不是「最终账单金额」。

一个跨工具的旁证：GitHub Copilot 官方在说明「什么影响用量」时，把会话长度列为第一项——「Conversation length and complexity: Longer conversations and more elaborate tasks involve more back-and-forth with the model, consuming more.」也就是说，「会话越长越贵」不是 Claude Code 一家特有的现象，而是这一类工具的共性；Claude Code 的特殊之处在于官方把 prompt caching 的重读机制写进了文档。

四、你看到的数字不是账单数字

这一节是本文认为最容易被忽略的部分。Claude Code 会把成本显示在会话里，但官方文档明确列出了几处「显示与实际不一致」的版本差异。

第一行是最值得注意的一条。数据驻留的 1.1× 费率是真实存在于账单上的加价，官方原文说明它的正确算法是：「For a response from the Claude API billed at the 1.1× data residency rate, Claude Code multiplies the list price of that response’s tokens by 1.1 in the session cost figure.」但在 v2.1.239 之前，这个 1.1 没有乘上去，官方自己的结论是「the session cost figure was lower than the bill」——会话里显示的成本低于账单。而且这是一个只影响显示的 bug，不影响实际扣费。

第二行的方向相反。v2.1.211 之前，会话统计数字会跨 /clear 累积，也就是说你清空会话后看到的总额仍然是整个进程的累计值。官方现在的表述是：「These totals reset when /clear starts a new session, so the next session’s total cost starts at $0.」

第三、四行是同一类问题：默认按标价计算。官方对 modelPricing 设置的作用写得很清楚：「The setting changes what Claude Code reports, not what Anthropic charges.」——这个设置改的是 Claude Code 报告什么，不是 Anthropic 收你多少钱。反过来说，如果你的组织走的是合约价，那么在你配置 modelPricing 之前，/usage、状态栏和 OpenTelemetry 三个地方显示的数字都与账单不符。官方给了一个确认配置生效的标志：在收到托管设置的会话里运行 /usage，Session 区块的 Total cost 行会带上一句 at your organization's configured rates。

五、三个容易踩的坑

六、按场景怎么选

• 会话已经开了很久，只剩一两句话要问：不要再问在这段会话里。官方明确 /clear「costs nothing」，而在这段会话里继续问，每句话都要重读整段历史。开新会话、把必要的背景用一句话重新交代，通常比留在旧会话里更便宜。
• 会话还要持续很久，但上下文已经很满：这时候 /compact 才划算。它的成本是一次性的接近全量读取，收益是后续每一次提问的重读量下降。用官方支持的定向写法——/compact Focus on code samples and API usage——把该保留的重点指定清楚，避免压缩后又要重新读文件。
• 要控制固定开销：把 CLAUDE.md 压到官方建议的 200 行以内，只留每次都会用到的规则；把 PR review、数据库迁移这类专用流程挪进 skills，因为官方说明 skills 是「load on-demand only when invoked」。
• 想知道上下文里到底装了什么：官方给了两个自查命令。/context 用来看「what’s consuming space」，/mcp 用来查看已配置的服务器并「disable any you’re not actively using」。后者有实际收益——虽然官方说明 MCP 工具定义默认延迟加载，但工具名和服务器指令仍然会进入上下文，停掉不用的服务器能减掉这部分。
• 中途要离开一段时间：注意官方给出的缓存生命周期——订阅状态下 1 小时，走 usage credits 或 API key 时 5 分钟。超过这个时长后回来问的第一句话会「misses the cache and reprocesses your full context」，按标准价重算整段上下文。所以「挂着会话去开会，回来接着问」是一个成本上不划算的习惯。
• 给团队做预算：官方建议编码席位和聊天席位要分开估——「Budget more for a coding seat than a chat seat: each Claude Code turn carries file contents, tool calls, and multi-step reasoning, so one debugging session can consume more than a day of chat.」这句话解释了为什么同一个席位配额在聊天里很耐用，在编码里很快见底。
• 要核对成本：不要用会话里的数字对账。默认按标价计算，走合约价的组织需要配置 modelPricing 才能让显示值接近实际；确认生效的标志是 /usage 里 Total cost 行带 at your organization's configured rates。

最后回到这篇的出发点。本站此前几篇分别处理了订阅价格、免费额度、席位计费和上下文窗口四件事。这一篇处理的是它们的交叉点：上下文窗口决定会话能装多少，而计费机制决定这段上下文每被重读一次要付多少钱。两者相乘，才是「开了一整天的会话」的真实成本。官方把这条机制写在了文档里，只是没有把它放在定价页上。