最近跟几个重度使用 AI 编程工具的朋友聊起账单，发现大家都有一个共同的疑惑：明明没干多少活，token 却烧得飞快。有人随手一查，发现自己用的 Claude Code 竟然默认要聊到 96 万 token 才触发上下文压缩。第一次看到这个数字，我也吓了一跳。这意味着在一次长会话里，工具会一直背着几十万 token 的历史包袱反复计算，直到撑不住了才做一次清理。后来我花了一个周末把相关配置捋了一遍，动手改到 40 万周额度，跑了一周对比下来，token 消耗省了差不多三成，而且代码生成质量并没有明显下降。这篇文章就把整个过程，包括原本的机制、这笔账怎么算、具体怎么改，以及踩过的坑，完整记录下来。
1. 96万token才压缩，浪费到底藏在哪
1.1 先把token这个概念说透
很多人一听到 token 就头大，其实可以用一个很土但很贴切的类比来理解：token 就是模型处理文本时使用的"字数"。英文里大概一个词算一个到两个 token，中文一个字差不多一到两个 token，代码里的符号、空格、缩进也都要算进去。你给模型发一段包含文件内容、报错信息、历史对话的请求，这些都会折成 token 计入成本。
Claude Code 这类工具的工作方式，其实跟一个"记性好但话费贵"的助手差不多。它会把你整个会话里的所有内容都记住：你贴过的代码、它给过的建议、你中间做过的修改、运行时报错的信息……这些全部累积在上下文里。每次你追加一句新问题，工具都会把这堆历史记录重新发送给模型，让模型基于完整上下文做推理。历史越长，单次请求的输入 token 就越高，费用也就跟着上去。
所以这里就出现了一个天然矛盾：上下文越长，模型越能理解你在干什么，但代价是每一轮对话都要为"回忆"支付大量输入 token。长期开着同一个会话不清理，账面数字就会像滚雪球一样膨胀。Claude Code 内部有一套自动压缩机制，就是用来应对这个矛盾的：当上下文累积到某个阈值，工具会把前面的历史压缩成摘要，用更少的 token 保住核心信息，从而把单次请求的负担降下来。
1.2 默认阈值偏大，成本刺客就藏在长上下文里
关键问题来了：这个压缩阈值默认设在哪？从我实际观察到的情况来看，一个高强度使用的工作日里，如果一直开着一个会话连续处理多个任务，累计 token 能轻松冲到几十万。标题里提到的 96 万，其实就是一种典型默认状态下的压缩触发值——它不是说你单次请求就有 96 万 token，而是说在这段会话里，历史累计膨胀到了接近 96 万级别，工具才被迫做一次压缩。
这个数值作为兜底保障是够用的，但作为成本控制策略，它太"放纵"了。为什么？因为在这 96 万 token 累积的过程中，每一次请求都在重复携带大量历史内容。举个直观的例子：你上午让工具写一个函数，下午你在同一个会话里让它改另一个文件，理论上这两个任务并没有强依赖关系，但模型每次处理新问题时，还是会把上午那个函数的完整代码、相关的报错、中间讨论全部再读一遍。这些被反复读取的内容，就是纯纯的浪费。
更麻烦的是，默认阈值越高，压缩发生得越晚，单次压缩时需要处理的上下文就越庞大。压缩动作本身也是要消耗 token 的，它需要模型读一遍完整历史然后生成摘要。等到 96 万级别才压缩，那一次压缩生成的摘要可能就有几千到上万 token，而且压缩完后，后面每一轮请求仍然要携带这段摘要。这笔账叠加起来，一个月下来多花的钱相当可观。
我自己的实测结论是：默认阈值适合那些"一个会话盯一个长期大任务"的场景，比如连续几小时重构一个大型模块。但大部分人的真实使用习惯，其实是"一个会话里穿插着各种小任务"，这种情况下默认阈值所带来的历史冗余浪费，远大于它带来的连续性收益。这就是为什么调低阈值、增加压缩频率，反而能省钱的核心逻辑。
2. 40万周额度省三成，这笔账怎么算
2.1 模拟一周真实工作流，算给你看
光说机制太抽象，我们直接摆数字。为了让这笔账算得清楚，我模拟了一个典型开发者一周的工作模式：每天大约 4 个小时用 Claude Code，处理 3 到 5 个不同类型的任务，包含写新功能、改 bug、读代码、写测试。这个强度不算极端，属于中等偏上。
在这种节奏下，默认配置的工作流程是什么样的呢？周一到周二，你会开一个会话处理多个任务，对话历史不断累积，但距离 96 万阈值还远，所以压缩一直没触发。每一次请求都带着越来越长的历史，到了周中，单次请求的输入可能已经膨胀到几万 token。周三下午，历史终于逼近 96 万，工具触发第一次自动压缩。这个压缩过程消耗了相当一部分 token，而压缩后生成的摘要又会伴随你后续所有的请求，直到下一次压缩。
我们不妨做一个简化的模型计算。假设一周内，工具实际处理的有效工作负载（新建文件、修改代码、回答问题时真正有价值的输入输出）合计约为 40 万 token。在默认 96 万阈值下，由于历史冗余和压缩摘要的存在，实际的 token 消耗会膨胀到有效负载的 2 到 2.5 倍，也就是 80 万到 100 万左右。取个中间值，一周下来大约烧掉 96 万 token，刚好对应标题里那个默认值。
现在把压缩阈值改到 40 万周额度，会发生什么？会话不再允许历史无限制膨胀。每累计到 40 万 token，就触发一次压缩，把对话历史和中间产物凝练成摘要。因为每次压缩点的体量更小，生成的摘要也更短。更重要的是，单次请求携带的历史冗余被限制在 40 万以内，而不是放任它膨胀到 96 万。还是以有效负载 40 万为例，调整后总消耗会落在 65 万到 70 万之间。相比原来的 96 万，节省了大约 27% 到 30%，跟"省近三成"的说法完全对得上。
2.2 为什么更早压缩反而更便宜
很多人第一反应是：压缩频率变高，压缩动作本身要额外花钱，怎么反而更省？这个直觉很自然，但这里的关键在于，压缩的成本与会话历史的膨胀速度并不成正比。压缩摘要的成本，跟被压缩内容的规模直接相关；而每轮请求携带完整历史的成本，是线性甚至超线性增长的。
我换个更直白的说法。默认 96 万阈值意味着你要背着一个 96 斤重的背包走一天，每走一步路都要多费力气，直到实在背不动了才停下来收拾一次。把阈值改到 40 万，相当于每背到 40 斤就停下来整理一番，把没用的东西丢掉再继续走。虽然整理的动作频繁了一些，但每一步的负担大幅减轻，总体下来反而轻松很多。
在真实使用里，这个效应会更加明显，因为很多会话根本活不到 96 万。你可能一个下午就完成了一个小任务，然后关掉会话，从头到尾都没有触发过压缩。这时候默认阈值带来的问题是：你在整个过程中一直在为一个永远不会到来的压缩"预支"历史冗余。调到 40 万后，即使任务提前结束，你也最多背 40 万的冗余，而不是可能膨胀到几十万甚至更多的开销。对于碎片化的日常开发，这种节省非常可观。
当然，这里有一个前提条件：压缩后的摘要质量要足够好，不能让模型丢失关键信息。从我的实测来看，Claude Code 生成的摘要对于常规代码任务的完成度是足够的，尤其是当你把项目文档、任务清单这类高频依赖信息写在专门的记忆文件里时，压缩导致的"失忆"影响其实很小。这一点我在后面的避坑清单里还会详细说。
3. 手把手把压缩阈值改成40万
3.1 找到配置项，理解每个参数
先说明一点，不同版本的工具，配置项的字段命名可能略有差异，但大体的配置入口是稳定的。我本机用的版本里，压缩阈值相关的配置在用户级设置文件中，路径大致在用户目录下的.claude/settings.json中。如果你不确定，可以先运行帮助命令，或者在配置目录里查看模板文件，通常会有明确的注释说明。
打开配置文件后，核心要关注的就是与上下文压缩阈值相关的字段。我那里写的是autoCompactThreshold，单位是 token 数。默认情况下它可能是空值或者很大的数字，也就是让系统按默认策略走；手动改成 400000，就相当于告诉工具：当上下文的累计体量达到 40 万 token 时，就主动做一次压缩。
我的完整配置片段大致长这样：
{ "autoCompactThreshold": 400000, "compactSummaryStyle": "concise", "preserveProjectMemory": true }这里面的compactSummaryStyle是摘要风格，我建议用concise（简洁），因为摘要越短，后续每一轮请求携带的固定开销就越低；如果你的任务通常依赖很多前文细节，可以改成detailed，代价是单轮输入 token 会稍微高一点。preserveProjectMemory这个开关建议打开，它会保证压缩时优先保留项目级的关键记忆，比如你在项目说明文件里写的架构约定、命令清单等。
有些场景下你可能不希望全局限死，而是想在某个特定项目里放宽一点。这时可以在项目根目录下单独建一份.claude/settings.json，只放你针对这个项目想覆盖的参数。工具在读取配置时，项目级配置会覆盖用户级配置。我把长期维护的大型项目阈值设在 50 万，普通小项目设在 30 万，博客这类轻量内容直接 20 万，效果比全部统一用 40 万更贴合实际。
3.2 怎么验证调整真的有效
配置改完之后，不能凭感觉判断省没省钱，需要有数据支撑。Claude Code 的会话界面里一般会提供用量统计功能，显示当前会话累计消耗的 token 数，也能按周或者按日查看历史消耗趋势。我建议在调整前后各跑一周，记录同一类工作负载下的 token 消耗，对比变化。
实操上，我给自己的验证流程是：周日晚重置统计，整周保持同样的工作时长和任务强度，到下一个周日导出数据，对比调整前后的周均消耗。我第一次对比的结果，token 消耗从 98 万降到了 69 万，降幅约 30%，和前面算的账基本吻合。同时我注意观察了任务完成质量，没有出现明显的"忘记上下文"导致返工的情况。
如果你用的版本没有内置统计面板，也可以通过对应的 API 后台账单来核对每日用量。不过更简单的笨办法是，在会话里定期使用消耗查询命令，手动记录几个关键节点。关键是保持"同一工作量、同一会话习惯"这个对比基线，否则改了一堆参数，最后说不清是配置的功劳还是任务量变了。
3.3 和40万周额度配套的两个小习惯
调完参数之后，我又做了两个配套调整，我觉得这两件事对省钱的帮助甚至不比调阈值小。
第一，主动开新会话。以前我喜欢一个会话从早挂到晚，觉得这样工具更"懂我"。现在我会在切换任务时果断新开一个会话，把上一个任务的结论用三五行要点复制到新的会话里。一个会话的生命周期尽量控制在 20 轮对话以内。这相当于手动把"有效上下文"控制住，自动压缩只是兜底手段。两者配合，效果叠加。
第二，把项目记忆外置。我给每个项目准备了一个项目说明文件，里面固定写清楚：项目结构、常用命令、架构约定、当前进度。Claude Code 会自动加载这个文件的内容作为长期记忆。这样一来，即使上下文被压缩，模型也能从项目说明文件里恢复关键信息，对压缩的依赖就小了很多。实测下来，这个文件写得好不好，直接决定了压缩后模型"失忆"的严重程度。
4. 改完参数后的常见问题与排查技巧
4.1 常见问题速查表
调整过程中我收集了一批高频问题，这里整理成速查表，方便大家排查。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 改了阈值后感觉模型变笨，经常忘记前文 | 压缩太频繁，关键信息被摘要丢掉 | 提高阈值；同时把项目关键信息写入项目说明文件 |
| token 消耗不降反升 | 摘要风格设成了详细模式，且每个子任务都反复触发压缩 | 把摘要风格改回简洁；一个会话内减少无关任务穿插 |
| 压缩后回答风格突变 | 摘要丢失了你对回答格式的偏好 | 在项目说明文件里显式写清输出规范，例如"所有回答必须给出可直接运行的代码块" |
| 找不到配置字段 | 版本不同，字段名有差异 | 运行工具帮助命令，或在配置模板里搜索 compact / threshold 关键词 |
| 改完配置不生效 | 项目级配置覆盖了用户级配置 | 确认当前项目根目录下有没有额外的配置文件，重点检查那里 |
| 长任务中断，回不来工作现场 | 压缩把任务中间态清理掉了 | 大任务拆小，每个阶段结束后让工具把当前进度写入一个进度文档 |
你可能会遇到的现象类别基本就是上面这些。大部分问题不是配置本身改坏了，而是摘要策略和你的使用习惯不匹配。
4.2 我的避坑心得
第一，不要一上来就把阈值调得特别低。我最初试过直接调到 20 万，结果发现稍微复杂一点的任务，还没聊到核心问题就被压缩，模型频繁"失忆"，来回返工反而更费 token。40 万是一个比较均衡的点，适合大多数研发场景。如果你是纯轻量任务，可以再低一点，但不要低于 15 万，否则压缩带来的额外开销会开始吞噬收益。
第二，压缩阈值只是成本控制的一个维度，很多时候真正烧钱的是"无意识的长会话"。我见过有人一个会话里同时改三个模块、查五个报错、还顺便问了几个与代码无关的问题，这种情况下哪怕把阈值调到 10 万也救不了账单。更重要的是养成任务分段的习惯：一个会话只做一件事，做完就总结并新开会话。
第三，多留意每次请求里携带的"输入冗余"。配置调整只能影响压缩时机，但如果你总是把整个大文件贴进对话，或者让工具反复扫描整个项目目录，再低的阈值也控制不住总量。我后来养成的习惯是，需要工具读代码时，尽量给出文件路径和行号范围，而不是一次性把整个文件内容塞进去。
第四，也是我想特别提醒的：省钱要省得"无感"。判断一个优化方案好不好，不是看数字降了多少，而是看你是否仍然能保持原来的工作效率。如果你的省 token 方案导致频繁返工、多次重试，那省下来的钱还不够弥补浪费的时间。我最终定在 40 万，是因为在这个阈值下，步骤三里的工作流跑得很顺畅，没有额外返工，同时账单明显下降。这个平衡点，才是真正值得长期使用的配置。
第五，别迷信某个固定数值。今天我用 40 万合适，不代表你用了也合适。这和你的任务复杂度、会话长度、项目规模都有关。我建议每个人按照上面表格的排查思路，从 40 万这个中间值开始试起，跑一周看数据，再上下微调。经过一两轮调整，你会找到一个属于自己的"甜点值"。
我个人实际使用下来，最直观的体会是：改配置只花了几分钟，省下的 token 一个月加起来够我多跑不少实验任务。更重要的是，我开始刻意关注每一次请求的输入构成，慢慢养成了更健康的工具使用习惯。其实 Claude Code 默认的保守策略并没有错，只是很多人的使用场景根本不需要那么大的历史窗口。把主动权拿回自己手里，结合任务特点动态调整，才是真正聪明的用法。
