Claude Code token压缩阈值怎么调？96万改40万省三成

我前几天盯着 Claude Code 的 token 用量统计发呆：一个周跑下来，光这个工具烧掉的上下文额度，比我预想的多了快一倍。后来看到有人在聊“默认聊到 96 万 token 才压缩，改到 40 万周额度能省近三成”，第一反应是“96 万？这个数字是不是听错了”，第二反应是去翻自己的配置——果然，我用的就是那个默认值。

顺手算了笔账，又把配置调了一遍后，我发现这个结论在我自己的项目里确实成立：同样是完成一组重构、写测试、过评审的周任务，我的 token 消耗大约降了三成。这篇文章不教你怎么无脑把阈值改成 40 万，而是把“96 万”为什么会存在、token 费用是怎么累积起来的、40 万这个数字从哪来、改完会踩哪些坑，全部讲清楚。适合正在用 Claude Code 做日常开发、文档批处理、项目重构的朋友，也适合刚接触这类工具、搞不明白为什么动不动就烧掉几千 token 的新手。

1. 默认 96 万才压缩，这个“大方”到底从哪来

1.1 压缩机制先搞清楚：它是总结，不是删库

Claude Code 在会话里会保存你们之前聊过的所有内容，好让你能连续提需求、改方案。96 万 token 达到时才压缩，意味着系统只在会话记录堆到 96 万 token 后才做一次自动压缩。这个压缩不是简单地把历史丢进回收站，而是让模型把前面的内容重新归纳成一段摘要，用摘要替换原始对话记录。

一个 token 大概对应大半个英语单词，中文会因切分方式不同有所浮动。所以 96 万 token 是什么概念？大概相当于几十万字的中文对话记录。你几乎很难在一天内和它聊出这么长的历史。换句话说，默认设置下，自动压缩更像是一个兜底机制，防止我们把会话拖到极端长度后失控，而不是真的建议大家把每次会话都干到 96 万再停。

真正执行压缩时，模型会把之前的对话、代码片段、决策结论整理成一段结构化摘要。摘要可以作为后续对话的背景，但原始细节已经被折叠。这个过程有点像开会时让人写会议纪要：后续讨论只翻纪要，不再回放录音。问题在于，纪要写得好不好，直接影响后续工作能不能顺畅推进。

1.2 96 万这个高阈值，到底在保护什么场景

从设计者视角看，这个阈值大概率是给“全景记忆”型任务准备的：一次分析大型代码仓库、在一个会话里反复确认架构方案、在长文档里抽查事实和引用关系。这些任务要求 AI 同时记住几十个前置条件，如果过早压缩，哪怕只丢了一个关键决策，后续就要重复解释，甚至直接返工。所以默认值宁可设得大一点，也要保证任务的连续性。

但这里有个容易被忽略的点：默认值大，不等于推荐值大。就像出租车的核载人数是五个人，不代表你每天一个人出门也非要拉满五个座位。对大多数中小规模项目，96 万这个阈值几乎等于“永远不压缩”，它保护的目标场景你根本碰不到。

为什么会设到 96 万这么高？我猜还有产品体验层面的考虑：自动压缩会触发一次额外的模型调用，有耗时也有成本，如果阈值设太短，用户在长任务中途频繁被打断，体感会很差。官方用一个很高的默认值，本质上是在说“我们优先保证你不被打断”，至于 token 费用，默认交给了用户自己判断。

1.3 我用自己的项目验证了一遍：日常根本喂不满 96 万

我手头在跑的是一个中等规模的跨平台小工具，包含前端和命令行两部分。日常做代码阅读理解、改功能、写测试时，我会把项目结构说明、关键模块代码、依赖清单一起放进去，这已经算是“喂得比较狠”的用法了。即便如此，单轮上下文也很少超过 10 万 token，连续聊一整天也很难堆到 96 万。

这说明什么？说明默认阈值对我是过度保护。过度保护的代价，就是我的每一轮请求都得为前面累积的历史 token 付费，而这些历史里已经有不少是被覆盖掉的旧方案、重复讨论和废弃代码。改阈值这件事，本质上就是把“过度保护”调成“适度保护”。

我也观察了朋友们的用法，有人专门拿 Claude Code 做长文档翻译，有人做 API 联调排错，有人写小说大纲。他们的上下文峰值集中在 20 万到 60 万之间，极少有人真正需要 96 万的量级。换句话说，96 万是给极端场景留的余量，不是给普通打工人设的推荐值。

2. token 计费下的隐形成本：为什么 96 万比想象中贵

2.1 计费机制的核心：每一轮调用都在为历史重付邮费

很多人对 token 费用的理解是“我说几句话，就付几句话的钱”，但实际完全不是。Claude Code 每调用一次模型，都需要把当前会话的上下文作为一个整体发送出去，按输入 token 计费。也就是说，当你的会话已经累积到 60 万 token 时，你问一句“这里改成同步好不好”，这次请求仍然要带着完整的历史一起算钱。

这就像寄快递：包裹重量不是按你新增的那一行字算，而是把整个箱子重新称一遍。箱子里的旧文件越多，每次续寄就越贵。用过一段时间后你会发现，真正消耗 token 的往往不是你的提问，而是那些被反复携带的旧上下文。

输出 token 也没有便宜到可以忽略。模型的回答本身就是输出，每次回答几百到几千 token，长一点的代码生成甚至能到上万。所以一个完整的会话成本，是“历史输入 + 新增输入 + 输出”三者的叠加。历史输入这部分，恰恰是大多数人完全没意识到的，也是调整压缩阈值能省下钱的核心来源。

2.2 一个具体数量级的例子，感受一下差距

假设一次会话共触发 200 次模型调用。前 100 次平均上下文只有 5 万 token，后 100 次因为历史越堆越厚，平均上下文涨到了 60 万 token。那么仅后 100 次的输入 token 消耗就是 100 × 60 万 = 6000 万 token。

如果我们在上下文达到 40 万时就触发一次压缩，并把压缩后的摘要控制在 3 万 token 左右，那么后 100 次的平均上下文大概率会降到 30 万以下。同样的 100 次调用，输入 token 变成 100 × 30 万 = 3000 万 token，直接省下一半输入量。注意，这还只是单一会话的估算，如果一周里有好几个这样的会话，差距会成倍放大。

有人可能会说，压缩本身也会消耗输出 token，因为模型要额外总结一次。确实如此，但一次总结的输出量通常只有几千 token，成本比起后面几十次调用各自背负几十万历史 token 来说，完全不是一个量级。这笔账怎么算都是划算的。

2.3 真正烧钱的是会话后期，而不是开头

看上面的例子你会发现：会话早期因为上下文短，单位成本很低，真正烧钱的是中后期——历史越长，每轮成本越高。这完全符合我自己的账单曲线：几乎每一次费用飙升，都对应着某个超长会话在“硬撑”。

理解了这一点，调整压缩阈值就成了一件顺理成章的事：我们不是要减少提问次数，而是减少每一轮提问背着的“历史包袱”。阈值越低，平均上下文就越短，单轮成本自然越低。那些觉得“既然它能记住，就让它一直记住”的想法，恰恰是账单膨胀的根源。

还有一个容易忽略的副作用：上下文越长，模型的推理延迟通常也越高。会话堆到几十万 token 后，每次返回答案的时间肉眼可见地变长。压缩阈值调低之后，连带着响应速度都会快一些，属于额外收益。这也能解释为什么很多长期挂机的会话到后面越来越“卡”，本质是模型处理的历史负担太重了。

3. 40 万阈值这笔账：手把手复算“省近三成”

3.1 先定义清楚：“40 万周额度”到底指什么

标题里的“40 万周额度”容易让人误会，以为每周总 token 预算就是 40 万，到了就拉闸。我的理解更偏实际：把单会话的自动压缩阈值设置到 40 万 token，同时给每周的累计用量设一条 40 万 token 的预警线。说白了，40 万既是压缩点，也是预算参考线，让会话不敢无限膨胀，也让周总量有个锚点。

把它当成一个可操作的配置目标，而不是一个强制限额。强制限额会让你畏手畏脚，该跑的重活不敢跑，反而影响效率。我把 40 万先落到单会话压缩点，再配合周用量提醒，双管齐下，才算是完整落地了“40 万周额度”这五个字。

之前也有人问：为什么是 40 万而不是 30 万或 50 万？我的回答是，40 万只是一个性价比比较高的中间值。它足够覆盖大部分日常开发任务，让一般长会话不至于频繁被压缩打断；同时又把历史包袱压在一个可控范围内，不会让单轮成本飙升到离谱。具体多少适合你，要看你自己的上下文分布，后面会讲统计方法。

3.2 压缩发生后，上下文不是归零，是回到摘要

算账之前要搞清楚压缩的逻辑：压缩不是清空，而是把历史提炼成摘要，摘要本身继续占据上下文槽位。比如阈值是 40 万，压缩触发后，token 数会从 40 万掉到几万，然后继续累积，直到再次达到 40 万。所以平均上下文不等于阈值本身，而是介于“摘要大小”和“阈值大小”之间的某个值。

这一点很关键，否则容易算错账。按我的观察，阈值 40 万时，平均上下文大致稳定在 30 万上下；阈值 96 万时，平均上下文可能冲上 50 万，甚至更高，具体取决于任务类型和会话拖了多久。

压缩触发得越频繁，摘要占的比例就越高，平均上下文就越接近摘要大小；压缩触发得越少，历史越容易膨胀，平均上下文就越接近阈值上限。这就是为什么同样调了阈值，不同人的节省比例差很多的底层原因。

3.3 同一份工作量，两种配置的 token 流水对比

我拿自己一周的真实工作量做了对照：同样是 200 轮模型调用、同样的任务清单，只改压缩阈值。输出 token 基本不受影响，因为模型回答的长度不会因为阈值改变而变化。结果大致如下：

算一下节省比例：(9760 - 6760) / 9760 ≈ 30.7%。这就是“省近三成”的来源。我实际跑了两周，节省比例在 25% 到 35% 之间浮动，基本对得上。

需要提醒的是，比例会因任务类型漂移：读长文档多的任务，节省更明显；输出密集型任务，输出 token 占比大，节省会被摊薄。所以别拿这张表当绝对结论，把它当估算方法更合适。

3.4 为什么不是省 60%，而是只有三成

有人会问，平均上下文从 48 万降到 33 万，看起来少了三分之一，为什么总费用不是少三分之一？因为还有输出 token 这份不可压缩的开销。模型每次回答还是要输出几百到几千 token，这部分完全不受阈值影响。所以压缩阈值最多只能影响输入侧，输出侧会稀释整体节省比例。

反过来想，如果哪天你看到有人声称“把阈值调小能省 80%”，基本可以断定他要么只算了输入侧，要么把会话拆分也算进去了。按我们的算法，最合理的预期就是两三成到三成多。数字听起来没有“80%”那么刺激，但落在真实的 API 账单上，三成是一个相当可观的钱。

4. 落地配置：压缩阈值和周额度怎么真正改成 40 万

4.1 改之前先统计自己的真实上下文峰值，别拍脑袋

我遇到过直接抄作业把阈值改成 5 万的，结果任务稍微复杂一点就被反复压缩折磨。改配置前，我们应该先了解自己一周内的上下文分布：单轮峰值最高到多少、大多数会话集中在哪个区间、每周总 token 大概多少。

统计方法不复杂：开启调试日志抓 usage 数据，或者在一个脚本里记录每次请求返回的使用量。只要连续记录三到五天的数据，就足够看出来你属于哪类用户了。统计完你会发现，我的阈值定在 40 万并不是随手拍，而是因为我大部分会话的上下文峰值正好在 30 万到 50 万之间。40 万可以保证大多数任务不被打断，又不会让历史堆得过高。

这里分享一个我自己的判断模板：把一周内所有会话的“单轮上下文峰值”从高到低排序，看第 80 百分位落在哪。如果你的第 80 百分位在 30 万，那把阈值设在 40 万就很合理；如果在 60 万，那 40 万会让你频繁压缩，建议放宽到 70 万到 80 万。

4.2 修改压缩阈值的实操入口

不同版本入口略有差异，但思路一致：找到 Claude Code 的配置文件，搜索和“压缩”相关的字段。字段名通常包含 compact、compaction、autoCompact、tokenLimit 等关键词，把表示阈值上限的数字从默认的 960000 改成 400000，保存后重启会话。

我以一个典型场景为例：配置文件在用户目录下，包含工作区和全局两部分配置。为了不影响其他项目，我先在工作区配置里改动，这样只有当前项目使用 40 万阈值。改之前先把原文件复制一份备份，改完在命令行里执行检查命令，确认当前会话的上下文限制已经更新，再继续干活。

有两点容易踩坑：一是有些版本里这个字段的单位不是 token，而是“千 token”，需要换算；二是如果同时开了多个会话配置，全局配置和工作区配置会打架，后者优先。建议改完立刻跑一个短会话，打印当前上下文窗口参数验证一下。

还有一个细节：如果你用的是团队共享账号，别直接动全局配置，否则会影响所有成员。优先在项目级配置里调整，并同步给团队说明调整原因和预期效果。我见过有人改了全局压缩阈值，结果同事的大型长文档会话频繁失忆，沟通成本比省下的费用还高。

4.3 周额度的三种落地方式

第一种，服务商控制台或套餐页面设置用量提醒，直接把周预算画在 40 万 token 附近。超过阈值时自动告警，个人用户最省事。

第二种，本地脚本统计。每次请求返回的 usage 字段里都有输入和输出 token 数，把它们累加到 CSV，写一个简单脚本每周汇总，超过 40 万就弹提醒。这个方案的优点是可控性最强，可以按项目、按会话拆分统计。

第三种，流程约束法，不依赖任何工具：把大任务拆成多个短会话，用“一个会话一套问题”的心理护栏来控制膨胀。比如我规定自己一个会话最多聊 30 分钟，到了就主动收尾、写 notes、开新会话。别小看这个土办法，它比任何配置都直接。

三种方式可以混合使用。我现在是控制台提醒兜底，本地脚本按项目拆账，流程约束法负责日常纪律。三者叠加之后，每周 token 用量基本不会失控。

4.4 改完跑一周，盯住这四个指标

不要急着宣布胜利。改完后的第一周，我会记录四件事：周总 token 有没有下降、自动压缩每天触发几次、回答质量有没有明显“失忆”、有没有因为忘记上下文而返工。

我的结果是：周总 token 下降约三成，自动压缩从一周不到 2 次变成每天 2 到 3 次，质量没有明显下滑。原因也很简单，我的任务主要是改代码，阶段性总结反而让模型更专注于当前步骤。但如果你的任务需要极强的全局连续性，比如大型架构重构，就要留意第二个和第三个指标，它们会直接告诉你阈值是不是调太低了。

如果发现自动压缩每天超过五次，或者开始反复解释同一件事，那就说明 40 万对你来说太激进了。此时不要硬扛，把阈值调回 60 万或 80 万，再观察一周。省钱的底线是不能因为失忆而返工，一旦开始返工，省下来的钱会以另一种方式花出去，而且花得更多。

5. 阈值不是越低越好：压缩背后的隐性损失与适用边界

5.1 自动压缩是有损总结，丢的不是文件，是上下文线索

几乎所有人都低估了“有损”这两个字。自动压缩的过程本质上是让模型做一次概括，把十几万 token 的对话浓缩成一小段摘要。看起来信息还在，但细节一定会丢：某个文件里约定好的命名风格、排错时发现的关键日志线索、你顺口说过但还没写进代码的需求。

印象比较深的一次，我把阈值调到了 25 万，跑一个中型项目重构。第 4 轮触发压缩后，模型完全不记得我们约定过“所有新接口统一走异步回调”，后面连续几次都在给同步方案。我解释了三遍才回到正轨，这期间的返工成本早就超过了省下的 token。

所以，省钱的核心不是“阈值越小越好”，而是“在信息不丢失的前提下，尽量减少历史包袱”。判断标准很简单：你愿不愿意让一次压缩把当前任务的上下文“会议纪要化”？如果愿意，阈值可以调低；如果不愿意，说明这个任务需要全景记忆，阈值得留大。

5.2 适合继续保留大阈值的任务类型

根据我的经验，下面几种任务宁可保留大阈值，也别为了省钱硬调小：一次性分析几千个文件并给出全局改动方案；跨模块做架构级重构，需要同时记住十几个相互关联的决策点；在超长文档里做事实核查，需要回溯到最初的上下文。

这些任务讲究“全景记忆”，中途压缩带来的失忆风险会造成严重返工，返工烧掉的 token 通常比省下的更多。对它们来说，96 万甚至更高的阈值反而是合理的。

另一个容易被忽略的场景是教学和方案评审。你可能会在会话里让模型基于很久之前的一句话展开设计，如果那部分上下文被压缩成了摘要，模型只能基于摘要继续发挥，方向一旦偏了，后面全部白做。这类场景宁可多花点 token，也要保证原始信息完整。

5.3 我的动态档位表，按任务类型切换阈值

我现在不再全局统一设一个固定值，而是按任务分档：

这张表只是我个人的经验值，不是标准答案。它的价值在于帮你避开两个极端：既不会因为阈值太小导致频繁失忆，也不会因为阈值太大导致账单失控。

具体操作上，我会在会话开头先花一句话说明任务类型，然后根据类型决定要不要临时调整当前会话的阈值，而不是全程依赖一个固定参数。调阈值本身也可以写到工作流的自动化脚本里，不同项目加载不同配置，省去手动切换的麻烦。

6. 实际操作中最容易忽略的几个省钱细节

6.1 手动压缩比自动压缩更省，也更可控

自动压缩是被动触发的，触发时机完全由阈值决定。但很多时候你可以主动出击：一个阶段的任务做完了，接下来的问题和前面关系不太大，直接执行手动压缩，让模型把前一阶段结论固化下来。这样后续调用携带的历史更少，而且摘要内容还新鲜，模型利用率更高。我跑完一轮重构就会手动压一次，效果比等 40 万自动压缩更明显。

手动压缩还有一个额外好处：你可以控制“压缩到什么粒度”。比如明确告诉模型“把已经确认的配置项完整保留，把讨论过程中的备选方案只留结论”，它生成的摘要质量会远高于自动压缩的通用摘要。摘要质量高了，后续会话的失忆风险就小很多。

6.2 别把整个项目目录塞进去，文件上下文才是大头

压缩阈值解决的是“历史对话”的负担，但真正让 token 飙升的往往是文件内容。我见过不少同事把整个项目目录拖进对话，或者把几千行的日志文件直接交给模型，一次调用就烧掉几十万 token。正确做法是维护一份排除清单，把 node_modules、编译产物、日志、临时文件都挡在门外，只把当前任务真正依赖的源码和配置喂进去。这一步做扎实了，账单能肉眼可见地下降。

我自己习惯的做法是：给每个项目维护一个 prompts 文件夹，里面写好“任务背景 + 关键文件路径 + 本次目标”的模板，每次开新会话先加载模板，再按需追加具体文件。这样既不会让无关文件进入上下文，又能保证模型从一开始就拿到结构化背景，一举两得。

6.3 用短会话组合拳代替长会话硬撑

很多超长会话是在“不想丢失上下文”的心态下硬撑出来的。但算清楚账之后你就会发现：一个 100 万 token 的会话，不如拆成 3 个 30 万 token 的短会话。每个短会话只盯一个目标，中间靠 notes 文件和提交记录延续上下文。这样不只省钱，模型在每个会话里的专注度通常也更高。我现在养成的习惯是：一个需求聊超过 30 分钟，就主动开新会话，把当前结论写进 notes 再继续。

这个方法刚上手时会觉得麻烦，但适应之后反而效率更高。原因很简单：每个短会话的上下文更干净，模型不需要在几十万 token 的杂乱历史里找线索，回答的准确率会明显上升。尤其是写代码这种对细节敏感的任务，上下文干净比上下文长重要得多。

6.4 最后给你一个可存档的用法：每周用量手账

我自己建了一个极简表格，记录每天的会话数、平均上下文、压缩次数、总 token 数。每周五花十分钟填一下，就能非常直观地看到哪种任务最烧钱、哪种阈值最适合自己。如果你不想手填，也可以把每次请求的 usage 字段自动写到 CSV，然后用一个小脚本汇总：

with open("token_usage.csv", "a", encoding="utf-8") as f: f.write(f"{session_id},{round_idx},{input_tokens},{output_tokens}\n")

这个表比任何人的建议都靠谱，因为它用的是你自己的真实数据。我最初就是靠这张表发现自己的峰值集中在 30 万到 50 万之间，才确定 40 万这个阈值；后来也是靠这张表确认了“省近三成”不是玄学，而是可以稳定复现的结果。

我现在的做法是：日常任务 40 万阈值加手动压缩，重活临时调回 80 万，再加上每周用量手账。从最初看到账单吓一跳，到现在每周对 token 消耗心里有数，整个过程靠的就是账算明白、配置调对、数据复盘这三件事。别直接照搬我的数字，先统计你自己的上下文峰值，再动手改配置。算完之后你会发现，默认值 96 万大概率不是为你准备的，而你自己的最佳阈值，不一定正好是 40 万，却一定能让账单瘦一圈。