上个月排查一起线上接口超时我顺手看了一眼 Claude Code 的 token 统计整个人都不好了。一个我认为只花了两小时的修复实际消耗的输入 token 接近 8000 万折算下来比其他同类工具贵了好几倍。查来查去问题不在我的代码而在 Claude Code 的默认行为上下文要一直攒到大约 96 万 token 才触发压缩。这个设计对长任务很友好但对钱包很不友好。后来我参考一个社区里流传的算账方法把每周额度和压缩阈值调到了 40 万 token跑了两个星期同样类型的活账单降了接近三成。这篇文章就把这笔账掰开揉碎讲清楚96 万是怎么来的、40 万改的是什么、怎么改、以及哪些场景千万别无脑抄。1. 为什么默认能“聊到 96 万 token 才压缩”先搞懂上下文是怎么长大的1.1 上下文不是流水账而是每次请求的“参演名单”很多刚开始用 Claude Code 的人会有一个误解上下文是“记忆”像人脑一样记住最近聊了什么就行。实际上不是这样。Claude Code 的上下文是每次请求都要带上台的全部材料相当于每次开会都要把历史纪要、全部附件、上一轮的笔记重新读一遍。举个例子。你让它改第 10 个文件它处理这个文件时输入里除了你刚说的“把超时时间改成 3 秒”还包括前 9 个文件里的代码、前面所有工具执行结果、报错信息甚至包括你最早说的“这个项目是处理订单状态的”。它不会像人一样凭印象干活而是每次调用模型都要把整段历史原样送进去。这也解释了为什么 token 会涨得这么快。你以为自己在对话实际上每次请求都在“重放”整个会话。越到后面单次请求的输入 token 越大费用也越高。很多人看账单只看到“调用次数”却忽略了每次调用背后的上下文体积。1.2 96 万这个数字是哪来的百万级窗口与安全余量Claude 家族的大模型目前支持百万级的上下文窗口Claude Code 默认就会尽量用满这个窗口直到接近上限才做压缩。大约 96 万 token 触发压缩不是随便拍出来的数字而是给窗口留出了“安全余量”。你想想看如果上下文真的到了 100 万再压缩那模型输出的时候窗口已经满了回复都可能写不下。所以它会在 96 万左右就动手预留约 4% 的空间给新输出。从机制上讲这个设计特别合理尽可能保留原始信息让模型在长任务里有完整的上下文减少“失忆”带来的返工。问题在于这个设计没有考虑成本曲线。上下文从 1 万涨到 96 万的过程里每一次请求的输入都在变大费用也在加速上涨。到 90 万 token 时一次请求的输入成本已经是 10 万 token 时的 9 倍。默认策略保证了任务质量和完整度但它是以“尽量不压缩”为优先级的对成本几乎不敏感。2. 这笔账到底怎么算从 96 万压到 40 万为什么会省近三成2.1 先搭一个算账模型要搞清楚 40 万阈值为什么省钱我们得先搭一个简化的计算模型。模型不需要精确只需要能量级正确能说明趋势。我拿一个典型的跨 20 个文件重构任务来举例。假设整次任务一共发生 800 次请求每次请求会产生大约 2000 token 的新增内容其中用户输入约 500 token模型输出和工具返回约 1500 token。这个数字在实际开发中会波动但量级是合理的。价格方面我按输入每百万 token 3 美元、输出每百万 token 15 美元的量级来估。不同渠道价格有差异但比例关系是一致的不影响后面的结论。2.2 默认策略下的 token 消耗默认策略下上下文从 0 开始增长到 96 万触发压缩。800 次请求里前 480 次左右把上下文从 0 推到了 96 万每次请求的平均上下文约 48 万输入 token 消耗 480 × 48 万 2.304 亿。触发压缩后模型会把之前的对话内容提炼成一份摘要假设这份摘要加上系统提示和工具定义总共约 5 万 token。接下来剩下 320 次请求上下文从 5 万继续增长到 69 万左右平均约 37 万输入消耗约 1.184 亿。两次加起来输入 token 约 3.488 亿。输出方面800 次请求的正常输出约 120 万 token压缩摘要输出约 5 万 token总共约 125 万。按前面的单价估算总费用在 1200 美元上下。这里最扎眼的是3.488 亿输入 token 里绝大部分是历史的反复重放而不是真正的新信息。2.3 40 万阈值下的 token 消耗把压缩阈值改成 40 万之后情况完全不同。同样 800 次请求上下文每攒到 40 万就压一次压缩后从 10 万左右重新开始增长。我重新算了四次分段第一次从 0 到 40 万平均 20 万200 次请求输入约 4000 万压缩后从 10 万再涨到 40 万平均 25 万大约 150 次输入约 3750 万第三次、第四次同样如此。最后还剩余约 150 次请求平均输入约 25 万输入约 3750 万。总输入约为 4000 3750 × 3 3750 1.9 亿 token。压缩摘要触发了 5 次输出约 25 万 token正常输出还是 120 万。总费用算下来约 650 到 700 美元和默认策略的 1200 美元相比理想节省大约 45%。2.4 理想节省 45%实测为什么只有“近三成”如果只看上面的模型你会觉得应该接近省一半但实际能省到 30% 就已经不错了。问题出在“压缩有代价”这件事上。每次压缩都是一次信息有损操作。模型把 40 万 token 的详细历史压成几千字摘要很多细节必然丢失。压缩之后你经常需要重新补充上下文比如告诉它某个文件里的接口定义是什么或者提醒它之前定下的命名规范。这些额外的补充输入都是默认策略下不需要花的。更麻烦的是压缩后模型偶尔会“假装记得”。有一次它压缩后忘了之前改过的函数签名还继续按旧签名写代码等测试报错才发现来回折腾了三轮。这种重试成本很难量化但在长任务里非常常见。所以我把理想模型和实际情况的差距拆成三块一是压缩摘要本身的输出成本被低估了摘要不是免费的二是压缩后用户要补充说明额外输入约增加 10% 到 15%三是压缩导致的返工和重试让请求数增加了 20% 左右。三块加在一起理想节省 45% 就被稀释到 30% 上下和标题里说的“近三成”基本吻合。策略输入 token输出 token理想费用实际节省默认 96 万压缩约 3.49 亿约 125 万约 1200 美元基准40 万阈值约 1.9 亿约 145 万约 700 美元约 30%3. 实际操作把阈值和额度改到 40 万的几种做法3.1 改配置的通用路径先说最重要的一句话不同版本、不同平台的 Claude Code 配置项名称不完全一样我下面给的是通用思路具体字段以你本地的提示为准。我用的是用户目录下的配置文件里面能看到 context 和 budget 两个区块。context 区域里有一个和“压缩阈值”相关的字段我把它从默认值改成了 400000单位是 token。budget 区域里有一个“每周额度”之类的字段我也改成对应的 400000避免单周超额。如果你找不到这两个字段可以在 Claude Code 的交互界面里输入 /config大部分版本会把上下文管理选项做成可视化菜单里面有 Context Management 或类似名称的一栏。选中后直接把阈值改成 400000 就行。注意改配置之前最好备份原文件改动后也先跑一个小任务验证不要直接拿正在进行的重构任务做测试。压缩阈值改坏了最坏的结果是上下文频繁被压任务逻辑全乱到时候连排查都无从下手。3.2 环境变量方案适合脚本化和多机器管理如果你习惯把 Claude Code 接入自动化脚本或者在多台机器上同步配置环境变量方案会更顺手。在启动 Claude Code 之前把与上下文限制、预算限制相关的参数通过环境变量传进去。具体可以用这个命令检查当前已经生效的变量env | grep -i claude你会看到一堆 CLAUDE 开头的变量。找到上下文管理相关的那几个在 shell 配置文件或启动脚本里添一行把它设成 400000。建议你在 .bashrc 或 .zshrc 里一次性写死这样每次打开终端都自动生效。我自己的习惯是在项目根目录放一个.env文件启动脚本里用set -a加载这样每个项目可以有不同的压缩阈值策略。比如一个小工具项目我用 30 万一个大型重构项目我用 60 万比全局统一配置灵活得多。3.3 验证阈值是否生效改完配置别急着干活先确认阈值真的变成了 40 万。我建议做一个最短验证流程起一个新会话随便让它写一段 300 行的代码然后查看当前的上下文大小。Claude Code 里可以用 /context 或类似命令查看当前会话 token 数具体命令不同版本有差异。确认它显示的上下文总量和剩余空间和改之前不一样说明配置已经生效。更直接的办法是故意快速积累大量上下文触发一次压缩看压缩发生时上下文是否在 40 万附近。刚开始我犯过一个错只改了每周额度以为压缩阈值也会跟着变。结果账单降得不明显一查才发现压缩阈值还是默认的 96 万额度只是做了硬性限制任务做到 40 万直接被拦停反而更痛苦。这两个配置要拆开理解额度是“刹车”阈值是“早转快转”省钱主要靠阈值提前。4. 阈值调低不等于白捡钱压缩的代价和适配场景4.1 便宜但有代价一个真实的翻车案例阈值调低确实便宜但它不是免费的。有一次我接了一个本地项目需要跨 12 个模块改公共状态管理逻辑。这个任务特别依赖全局记忆前面改过哪个模块、新架构里状态树长什么样、哪些旧接口被废弃每一步都建立在上一步的基础上。我当时为了省钱把阈值调到了 25 万。结果第一个模块还没改完上下文就触发了压缩。摘要里把架构调整方向写清楚了但丢了具体几个文件里旧的调用链。后续模型开始一本正经地写不存在的接口编译立刻报错。我花了大半天排查反复补上下文最后不仅没省到钱还比默认策略多花了 20% 的 token。这个案例给我一个很深的教训上下文是任务的“工作记忆”压缩就是让你失忆。失忆后你可以靠外部笔记补但补记忆的过程也有成本。对于强依赖长期记忆的任务阈值不是越低越好而是要找到一个平衡点。4.2 适合调低阈值的任务画像经过两个星期的实测我总结出三类特别适合低阈值的任务。第一类是相互独立的批量小任务。比如批量修正代码格式、给多个函数补注释、把一堆 JSON 换成 YAML。这类任务本身不依赖前面改过的内容压缩后丢一点历史也没关系反正下一步是独立文件。第二类是单文件深度修改。只改一个文件时上下文里最有价值的就是这个文件本身而它会被反复读取和重写压缩阈值低一点影响不大。我经常把这种任务的阈值压到 20 万到 30 万实测很稳。第三类是代码解释、文档生成、知识问答这类“读多写少”的场景。任务目标是理解代码生成文档不需要跨文件的长期一致性压缩丢一些细节反而更容易提炼重点。4.3 不适合的任务画像这些场景请把阈值调高和上面相反有四类任务我建议保留较高阈值别盲目抄 40 万。跨文件大规模重构是最典型的一种。多个文件互相依赖模型必须同时记得 A 文件的导出、B 文件的引用、C 文件的旧逻辑任何一环断裂都可能让整个重构变成灾难。长链路调试也是高危场景。从现象反推到根因往往要跨越十几次工具调用每次调用结果都是推理链条的一部分。压缩会把中间结果浓缩掉等于把侦探故事的最后三页撕了。还有涉及架构决策的任务比如设计新模块、规划数据模型、评估技术方案。这类任务的信息密度高且决策往往分布在上百次请求里前后呼应的细节非常多。压缩后哪怕丢一个“当时为什么选 A 不选 B”的原因都可能让方案跑偏。最后是长时间会话配合外部记忆物质导入。如果你已经往上下文里塞了大量参考资料压缩会把这部分资料当成普通文本摘要掉。参考资料的价值恰恰在原文细节摘要一出来参考价值就没了。4.4 已踩坑的人怎么办手动压缩 外部记忆组合拳如果你已经在低阈值下踩了坑别急着把阈值改回去可以先试着用手动压缩和工作区笔记来弥补。Claude Code 支持手动压缩命令我平时会在任务阶段告一段落时主动执行一次而不是等阈值自动触发。手动压缩的好处是你可以选时机两个模块之间、逻辑相对完整的节点。这时候压缩产生的摘要质量高信息丢失少。我还会在项目根目录放一个progress-notes.md把架构决策、已改文件清单、剩余任务、已知坑位都记进去。每次压缩后我会让 Claude Code 先读这个笔记再继续干活。这等于在外部建了一个“备份记忆”压缩把内部工作记忆清掉后外部记忆还在。实际操作下来这个组合比单纯调高阈值还省钱。因为它减少的是“上下文里塞太多重复内容”的问题而不是靠降低压缩频率来硬扛。5. 实测两周的数据、感受和值得抄的作业5.1 两周前后的账单对比我用两周时间做了对比实验。第一周保持默认 96 万压缩策略第二周把阈值和额度都改成 40 万任务类型基本一致都是日常的代码编写、Bug 修复和小型功能开发。结果如下第一周总输入 token 约 2.1 亿输出约 900 万压缩触发 1 次总费用约 750 美元。第二周总输入 token 约 1.4 亿输出约 1100 万压缩触发 4 次总费用约 540 美元。节省幅度约 28%。注意输出 token 反而增加了原因就是压缩更频繁每次压缩都要先生成一段摘要。但输入 token 从 2.1 亿降到 1.4 亿这个量级的降幅远超摘要花掉的成本所以整体还是省了。指标默认 96 万阈值40 万阈值变化输入 token约 2.1 亿约 1.4 亿下降 33%输出 token约 900 万约 1100 万上升 22%压缩次数1 次4 次增加总费用约 750 美元约 540 美元节省 28%5.2 心得一按任务类型分批跑别让一个会话背负所有上下文改完阈值后我发现一个更重要的问题上下文里塞了太多不需要的东西。有时候一个会话从早上写到晚上前面解决的是 A 模块后面切换到 B 模块中间还顺手查了两个报错。结果整个上下文 70% 的内容和当前任务无关。压缩阈值调得再低也只是在“已经攒了很多垃圾”的前提下做减负。真正的省钱方法是按任务类型分批跑一个会话只做一件事做完立刻新开一个会话。新会话的上下文干净一上来就是 0根本不需要压缩。我自己现在的习惯是每个独立功能开一个会话中间切换任务就用/clear或类似命令清理上下文把重要的结论写进 progress-notes.md下个会话直接读笔记。这比调阈值更有效两个方法叠加之后第二周的输入 token 其实已经低到接近理论下界。5.3 心得二压缩后花 30 秒做一次“状态核对”刚开始调低阈值时我经常一看到“上下文已压缩”的提示就继续往下走结果经常发现它把关键文件内容搞丢了。后来我养成了一个习惯每次压缩后先让它用三句话总结当前状态包括任务目标、已完成部分、下一步计划。如果它把某件事说错了我立刻纠正花 30 秒补全。这个核对动作的成本很低但能省掉后面几小时的返工。你可以在压缩后直接问“基于当前上下文你认为我们接下来要做什么有没有已知的约束条件” 看它回复和你记忆中的差异即可。这个做法本质上是在确认压缩摘要的质量。摘要质量高后面的任务就顺摘要质量差你必须尽早干预而不是等问题在代码里暴露后再回头查。5.4 心得三阈值不是越低越好40 万只是我的平衡点最后说说 40 万这个数字。它不是金科玉律只是我试出来的平衡点。我把阈值从 96 万降到 80 万、60 万、40 万、25 万、15 万分别跑过几天结果挺有意思。15 万到 20 万区间压缩次数太频繁经常一个文件还没改完就压一次摘要输出成本开始反超省下的输入成本总费用反而上升。25 万到 40 万之间费用下降最明显而且任务质量没有明显下降。50 万到 80 万区间费用比 40 万高一些但长任务的成功率高不少适合复杂重构。如果你日常任务比较重我建议从 60 万起步观察一周费用和返工频率再慢慢压到 40 万或更低。如果你只是写写小脚本、改改配置文件25 万也能跑得很舒服。关键是记录你自己的数据不要直接抄我的结论。根据我个人的实际体验压缩阈值这件事最值得做的不是马上改成 40 万而是先搞清楚现在的上下文到底是从哪里涨上去的。下次你扫一眼账单时如果发现输入 token 高得离谱九成是历史重放的成本而不是模型真的写了复杂代码。这时候再动手把阈值压低顺便把无关上下文清掉你会回来感谢那笔账。