实测Claude Code /compact成本：暖缓存0.06美元，冷缓存贵9倍

Claude Code 的 /compact 到底花多少钱？官方文档只说它「本身就是一个大请求」，却从未给出具体数字。有人用 38 个 claude -p 进程、136k token 的真实代码会话做了完整测量，把缓存命中、缓存过期、/clear 三种路径的成本全部拆开算清。结论比文档描述的更有操作价值。

Claude Code /compact 成本实测

官方文档说了什么，又没说什么

Claude Code 的成本文档承认 /compact「会读取它要总结的对话，所以压缩大上下文本身就是一个大请求」，也承认「想要全新开始而非延续时，/clear 不花任何费用」。两句话都对，但都不给数字：请求有多大？是 token 大还是美元大？压完之后下一轮又要多少钱？

文档还链接到 prompt caching 页面，补充了两个关键机制。缓存暖的时候，总结请求从缓存读取整个前缀，「一次会话中途的 /compact 只花上下文规模所暗示的零头」；缓存过期后，「总结请求会把完整历史当作未缓存输入重新处理」。同时，压缩后 Claude Code 会「重新读取最多五个最近修改过的文件」，超过 5,000 token 的文件只留路径引用、不带内容。这些规则在实测中全部得到验证。

Prompt caching（提示缓存） 是 Anthropic API 的一项机制：当多次请求共享同一段前缀（系统提示、工具定义、历史对话）时，服务端可以把这段前缀的计算结果缓存下来。下次请求若命中缓存，这部分 token 就按远低于普通输入的价格计费——以 Opus 5.5 为例，缓存读取仅为输入价的 5%，而普通输入是 $4/百万 token。

缓存有两个关键特性决定了本文的成本结构。其一是写入成本：第一次把 token 写进缓存时，价格高于普通输入（约 1.25 倍），所以刚读入一大段内容的那一轮反而更贵。其二是生存期（TTL）：缓存默认存活约五分钟，且每次命中会刷新计时；一旦超过生存期没有请求，缓存失效，下次请求必须把整段历史当作未缓存输入重新处理。这正是文中「冷压缩贵 9 倍」的根源。

实验怎么做的

测试用的全是真代码：从开源包里拷来的 31 到 41 KB JavaScript 文件（Jest 的 transform 构建、Babel 的 scope tracker、argparse、browserslist、Handlebars 编译器、minimatch、picomatch）。每个会话先让 Claude 用 Read 工具读一组文件并各用十个词描述，读一个、四个、七个文件分别对应 34.2k、84.7k、136.4k token 三种规模。

驱动脚本用 --input-format stream-json 把每条消息写进同一个 claude -p 进程，等 result 事件再发下一条。所有 token 数据来自请求体本身——开启遥测后 Claude Code 会把每个请求和响应写到磁盘，并按 query_source 标出哪次是 compact（总结请求）、哪次是 sdk（主对话）。每次压缩的 --debug-file 日志与响应体在 19 次压缩中全部吻合，total_cost_usd 的增量也与按 Opus 5.5 列表价计算的结果一致。

暖缓存下的 /compact 请求

压缩前上下文	普通轮次	压缩成本	相对普通轮次
34.2k	$0.0078	$0.037–$0.044	4.7–5.7 倍
84.7k	$0.019	$0.045–$0.046	2.3–2.4 倍
136.4k	$0.031	$0.056–$0.059	1.8–1.9 倍

token 层面它确实是大请求：携带了除最后一条短回复之外的整个对话，再加上约 2,000 token（探测问题、总结指令、一行 token 预算提醒），总量是所总结上下文的 1.01 到 1.06 倍。但在暖缓存下美元层面并不大，因为 138,344 个输入 token 里有 136,275 个是缓存读取。

136k 那次压缩的 $0.0589 拆开看：缓存读取 $0.027、总结输出 $0.023、2,069 个新 token 花 $0.008。如果按未缓存输入计价，同样上下文处理一次要 $0.545——暖压缩只相当于它的 10% 到 11%。34k 时这个比例升到 27% 到 32%，因为指令和总结本身不随会话缩小。总结的输出也几乎不随规模增长：34k 到 136k 的压缩，postTokens 落在 1,549 到 1,977 之间，六次压缩都完整列出了读过的每个文件。

缓存断点（cache breakpoint） 是理解压缩成本差异的核心概念。API 允许在一次请求中标记若干位置，服务端只缓存断点之前的内容。Claude Code 在构建总结请求时，把断点放在「最后一个被总结的助手消息」处。

请求在结构上被切成两段：断点之前是已缓存前缀，按缓存读取价计费；断点之后是新增内容，按普通输入价计费。正常压缩时，被总结的最后一条助手消息是 Claude 对文件的描述，所以文件内容都在断点之前、享受缓存价。而如果读文件后立刻压缩，被总结的那条变成了调用 Read 工具的消息，文件内容整体落到断点之后，只能按 $4/百万计价——这就是 $0.31 与 $0.045 之差的直接来源。

冷缓存：直接贵 9 倍

缓存过期后（测试强制使用五分钟缓存写入并静默 6.5 分钟），情况完全不同。

压缩前上下文	暖压缩	冷压缩	冷压缩的未缓存输入	冷/暖
84.8k	$0.045	$0.326–$0.333	75,336	7.0–7.4 倍
136.5k	$0.056	$0.529–$0.542	127,019	9.0–9.8 倍

只有 10,466 到 11,447 个共享的系统提示和工具定义 token 还来自缓存，其余全部按 $4/百万的普通输入计费。冷压缩的花费相当于把整个上下文按基础输入价读一遍的 96% 到 99%。

一个有意思的对照：同样等待 6.5 分钟后不压缩、直接继续对话，136k 下探测请求要重写 125,158 个 token 进缓存，花 $0.629；而冷压缩加下一轮只要 $0.53 到 $0.54 加 $0.021 到 $0.023。也就是说长时间中断后，压缩反而比硬着头皮继续更便宜，而且后续每轮只读约 15k 而不是 136k。

最贵的一种暖压缩：紧跟在读文件之后

这是文档完全没有提示的坑。如果读文件的那一轮之后不插入任何普通问答，直接发 /compact，即使缓存是热的，压缩成本也会跳到 $0.303 到 $0.315——是同等规模暖压缩的 6.5 到 7.0 倍。自动压缩（--autocompact）产生的请求完全一样，$0.305 到 $0.307。

原因在请求结构里：19 次压缩中有 18 次，最近的助手回复不在总结请求中，而是以 preservedMessages 形式保留在总结之后。请求的缓存断点落在「最后一个被总结的助手消息」上。正常压缩时那条消息是 Claude 对文件的描述，所以包括文件内容在内的所有内容都命中缓存；而立即压缩时被保留的是文件描述，最后一个被总结的助手消息变成了调用 Read 的那条，约 68,000 个文件内容 token 排在断点之后，只能按未缓存计价。

这可以提炼成一条位置规则，与手动或自动无关：总结请求中未缓存的部分，就是最后一个被总结的助手消息之后的所有内容。在真实会话里，那就是最后一步的工具结果——可能很小（一次测试总结），也可能很大（一次大文件读取或长日志）。

压缩后的下一轮要多少钱

第一次请求发生在	token 数	成本	探测回答
全新会话	15,180	$0.034（新前缀）或 $0.003（命中缓存）	NONE
`/clear` 之后	15,303	同全新会话	NONE
暖压缩，大文件	14,254–14,923	$0.026–$0.032	文件列表
暖压缩，小文件	28,316–29,287	$0.143–$0.151	文件列表
`/clear` 后读交接笔记	15,301 起	两次请求共 $0.044–$0.046	文件列表

暖压缩后的请求甚至比全新会话还小，因为两样东西没被重新注入：技能清单（约 6,805 字符）不再发送，超过 5,000 token 的文件只以一行说明的形式回来（「transform.js 在总结前被读过，但内容太大无法包含」）。系统提示和工具共 11,322 token 从缓存读取，其余 2,930 到 3,599 token 要写入缓存，所以压缩后的第一轮固定花 $0.026 到 $0.032。

小文件的情况正好相反。用 24 个都小于 5,000 token 的文件（约 90k token）测试时，压缩后 Claude Code 完整重读了最近修改的五个文件，postTokens 升到 9,817 和 10,438，下一轮请求达 28,316 到 29,287 token，写入 17,000 到 18,000 token 缓存，花 $0.143 和 $0.151——超过压缩本身（$0.054 和 $0.072）两倍。压缩的账单可能主要发生在压缩之后。

自动压缩（auto-compact） 是 Claude Code 在上下文逼近模型窗口上限时自动触发的压缩，默认阈值约 967K token。它和手动输入 /compact 调用的是同一套总结逻辑，因此成本结构完全一致，区别只在于触发时机由系统而非用户决定。

实践含义是：你无法通过「不主动压缩」来避免那次昂贵请求，只是把账单推到系统替你触发的那一刻。文中测试的 --autocompact 请求与手动压缩在相同位置产生完全相同的成本（$0.305–$0.307）。所以主动选择压缩时机——在自然停顿处而非刚拉入大工具结果之后——才有实际节省空间。

/clear 确实零成本，交接笔记不划算

13 次 /clear 全部没有发出任何 API 请求，耗时 0.05 到 0.34 秒，产生 conversation_reset 事件、新会话 id 和 total_cost_usd: 0。文档的说法精确成立。代价是连续性：/clear 后的探测 6 次全部回答 NONE。

常见的替代方案是让 Claude 先写一段简短交接笔记，清空后再读回来。实测这个方案在每个规模上都比压缩更贵：

压缩前上下文	压缩 + 下一轮	写笔记 + clear + 读笔记
34.2k	$0.063–$0.072	$0.074–$0.075
84.7k	$0.075–$0.076	$0.097
136.4k	$0.087–$0.091	$0.119–$0.120

交接笔记的优势在于几乎不依赖会话缓存。向新会话读入笔记每轮稳定花 $0.044 到 $0.046，而 136k 会话断开后的压缩要 $0.53 到 $0.54。写笔记产生 486 到 599 个输出 token，比一次总结还少。

什么时候压缩才划算

压缩的价值来自后续请求变小。后续每轮从缓存读取压缩后的上下文而非完整上下文，按 $0.20/百万缓存读取计价，节省幅度不大。136k 时每轮省约 $0.024，而压缩加随后的缓存写入约 $0.058，两三轮即可回本；85k 需要约四轮；34k 需要约十五轮。带工具调用的一轮会产生多次请求，所以大上下文在实际工作中一两轮就能回本。

基于这套数据，可以给出几条操作规则：

切换到无关工作时用 /clear，它不发送任何请求，下一轮就是全新会话的规模。
想在大会话中继续同一份工作，就在自然停顿处压缩——一句短回复之后，而不是刚拉进一个大工具结果的那一轮之后。同样规模下这是 $0.045 和 $0.31 的差别。
如果准备离开超过缓存生命周期，走之前就压缩或写笔记。断开后再压缩同一会话贵 9 倍，继续它更贵。
留意最近读的文件大小。小于 5,000 token 的文件压缩后会完整回来，五个这样的文件能让压缩后第一轮的成本超过压缩本身两倍。
小会话里压缩几乎不回本。34k 时后续轮次只从 34k 降到 14k，每轮省 $0.004。

回本周期在这里指压缩的一次性支出，需要靠后续每轮省下的缓存读取费摊销多久。算法是：压缩成本 ÷ 每轮节省额。压缩后每轮从缓存读取压缩后的上下文（约 15k token）而非完整上下文（136k），差额约 121k token 按 $0.20/百万缓存读取价计，每轮省约 $0.024；而压缩加随后的缓存写入约 $0.058，两者相除约得 2–3 轮。

需要注意的是，这里的「轮」指 API 请求数而非用户可见的对话回合。一次带工具调用的回合可能触发多次请求，所以真实工作中大上下文的回本往往在一两轮内就完成。上下文越小，压缩后省下的绝对量越小，回本所需的轮次就越多——34k 时每轮仅省 $0.004，需要约十五轮。

测不到的边界

全部测试跑在同一台机器、同一个账号、同一个模型（Opus 5.5）和同一版本（2.1.289）上，headless 模式、stream-json 输入。会话都很短——一次大读取加一两次探测，真实会话有更多轮次、编辑和工具调用，总结也可能更长。接近 967K 默认自动压缩阈值、带 focus 指令的 /compact、以及后台预生成总结都没有测试。

还有一点值得注意：Opus 5.5 的缓存读取折扣是输入价的 5%，比多数其他模型的 10% 更狠，所以这里的暖压缩看起来比在其他模型上更便宜。冷运行强制使用五分钟缓存写入，一小时的情况是计算值而非实测值。所有美元数字都是列表价估算，在订阅制下真正约束你的是套餐额度，这部分没有测量。