我前几天盯着 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 基本不受影响因为模型回答的长度不会因为阈值改变而变化。结果大致如下配置平均单轮输入上下文输入 token 总量输出 token 总量总消耗默认 96 万才压缩48万9600万160万9760万提前到 40 万压缩33万6600万160万6760万算一下节省比例(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 我的动态档位表按任务类型切换阈值我现在不再全局统一设一个固定值而是按任务分档任务类型建议阈值注意事项日常编码、写测试、改 bug30-40 万配合手动压缩小任务尽量拆开中型项目重构、代码评审60-80 万关键决策提前写进 notes全局代码库分析、长文档核查90-100 万慎用自动压缩必要时手动控制这张表只是我个人的经验值不是标准答案。它的价值在于帮你避开两个极端既不会因为阈值太小导致频繁失忆也不会因为阈值太大导致账单失控。具体操作上我会在会话开头先花一句话说明任务类型然后根据类型决定要不要临时调整当前会话的阈值而不是全程依赖一个固定参数。调阈值本身也可以写到工作流的自动化脚本里不同项目加载不同配置省去手动切换的麻烦。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, encodingutf-8) as f: f.write(f{session_id},{round_idx},{input_tokens},{output_tokens}\n)这个表比任何人的建议都靠谱因为它用的是你自己的真实数据。我最初就是靠这张表发现自己的峰值集中在 30 万到 50 万之间才确定 40 万这个阈值后来也是靠这张表确认了“省近三成”不是玄学而是可以稳定复现的结果。我现在的做法是日常任务 40 万阈值加手动压缩重活临时调回 80 万再加上每周用量手账。从最初看到账单吓一跳到现在每周对 token 消耗心里有数整个过程靠的就是账算明白、配置调对、数据复盘这三件事。别直接照搬我的数字先统计你自己的上下文峰值再动手改配置。算完之后你会发现默认值 96 万大概率不是为你准备的而你自己的最佳阈值不一定正好是 40 万却一定能让账单瘦一圈。