Claude Code token 成本优化：从 96 万到 40 万的主动压缩实战

前段时间社区里有个话题讨论度很高某开发者发现自己明明只是连续写了一个周末的功能Claude Code 却悄无声息地累计消耗到了 96 万 token 才触发自动压缩。顺着这个数字往下算如果把每周任务额度主动压低到 40 万 token总成本能省出将近三成。这个结论乍看有点反直觉——同样是干活为什么少用反而更便宜但把 token 的计费逻辑和 Claude Code 的上下文压缩机制摊开看这笔账其实相当直白。这篇文章我想把这笔账完整复盘一遍96 万这个数字是怎么冒出来的、长会话的钱到底花在哪、40 万周额度的省法靠不靠谱最后会给出可以直接照抄的配置和操作习惯。适合所有用 Claude Code 做实际开发、又不想每个月为 token 账单肉疼的人。1. 96万这个阈值是谁在什么时候算出来的1.1 不是官方推荐值autoCompactThreshold 的默认行为很多人第一次听说“96 万 token 才压缩”第一反应是去翻官方文档找这个数字。实际上官方文档里并没有一个叫“96 万”的推荐阈值它是 Claude Code 根据会话上下文窗口动态计算出来的结果。简单说Claude Code 把一次会话里所有的对话、工具调用、文件读取、终端输出全部记成一份 transcript当这份 transcript 的体量超过某个比例时系统才会启动自动压缩。这个比例的默认值就是autoCompactThreshold它在配置里通常写法是maxTokens的某个百分比。比如你将maxTokens设置为 200k那么阈值可能被指定为它的四分之一或更大具体百分比会随版本浮动。社区里那位开发者之所以碰到“96 万”是因为他当时用的模型上下文窗口被放大得比较高加上会话中大量工具调用把 transcript 撑得飞快累计到接近 100 万 token 时压缩机制才触发。换句话说96 万不是一个精确的固定开关而是“默认参数 长会话 高频工具调用”三者共同作用下的实测结果。它真正说明的问题只有一个在默认配置下Claude Code 会允许一个会话非常“胖”地运行很久直到逼近窗口极限才动手清理历史。1.2 压缩发生时你失去的不只是“聊天记录”自动压缩听起来像是一次普通的整理但实际操作里它做的是“重写历史”模型会把此前一大段对话摘要成几百行文字再继续往下接。这个重写不是免费的压缩本身会额外消耗 token而且压缩之后之前对话里很多细枝末节会被丢掉。最典型的场景是你在会话里让 Claude Code 改过某个配置文件的第 37 行压缩之后你再问“刚才那个配置改到哪了”它可能只记得“改过配置文件”但具体行号和前后文全没了。一旦丢失这些细节你就得重新描述、重新定位、重新让它理解而这一轮轮“重新”全部会计入 token。所以把 96 万这个数字当成一个成本警示更合适当一个会话能拖到 96 万 token 才压缩说明你在此之前已经为大量低价值的历史换入换出付过很多遍钱了。2. 长会话的隐性账单为什么越聊越贵2.1 每次请求都在重放整个 transcriptClaude Code 和本地工具最大的区别是它不是在你机器上直接读文件而是把文件内容、上下文、历史操作记录统统塞进每次请求里发送给模型。假如你的会话累计了 60 万 token 的历史那么接下来每一次你发“帮我看看这个报错”模型实际要处理的可能就接近 60 万 token 再加新输入的几百 token。这就是长会话最贵的机制——不是因为你多聊了几句而是因为后面每一句都背着前面所有话的重量。用个生活化类比你拖着一个行李箱逛商场每进一家店门口都要把行李箱过一遍安检哪怕你只是进去买瓶水。行李箱越大买东西的成本越高而且这个成本是叠加的。2.2 工具结果重复计费与“部分重写”的隐藏消耗Claude Code 里最常见的工具是读文件、改文件、跑命令。每次工具调用工具返回的内容也会写进 transcript并在后续请求中持续存在。我见过最夸张的一次某个会话里同一个日志文件被反复读取了二十多次每次都是几千行那些内容从头到尾都在背景里被一遍遍重新计费。另一个容易被忽略的消耗是“部分重写”。有时候 Claude Code 只改了一个文件里的一小段但它生成的 diff 会把整个文件的新旧版本都留在会话里聊天窗口没感觉占多大地方可一旦折算成 token几十 KB 的文本就是几千上万个 token。长会话里这种“看着没什么、实际上很贵”的细节特别多。2.3 模型“失忆”引发的返工才是最大开销长会话对工作效率的影响比直接账单更难量化但我做了几次对比之后发现真正导致成本失控的是模型失忆带来的返工。会话越长模型对早期信息的记忆越模糊你问它“最早不是说过某模块要用异步方式吗”它可能答非所问。于是你得重新把需求梳理一遍它再重新设计方案前后多花好几轮对话。这些多出来的轮次本身就会再增加 transcript 长度进而让后续所有请求变得更贵形成一个恶性循环越聊越贵 → 越贵越舍不得重开 → 越舍不得重开越容易失忆 → 失忆导致返工 → 返工让聊天更贵。这也是为什么很多人聊到 96 万 token 才触发压缩时并不会觉得“省了压缩的麻烦”反而会觉得很亏——因为前面几十万 token 里有一大笔是在反复解释已经被说过的事情。3. 40万周额度的账省下的近三成从哪来3.1 我用两次等量任务跑的对照组光说理论和机制不够我特意把手头两种工作方式各跑了一周做了个对照组。任务规模是五个中小型功能改动包括新增接口、调整样式、修一个跨模块的 bug以及补一轮单元测试。不含模型订阅费用只统计 token 消耗。第一种方式是默认配置每个需求开一个会话但聊得比较随意经常跨越半天、带一堆上下文也不中断。第二种方式是给每周消耗设了 40 万 token 的硬上限具体做法是每个需求新建会话、任务一完成立刻手动压缩或直接关闭不让会话过夜。结果如下表工作方式总 token 消耗压缩/重写占比估算返工轮次默认长会话累计约 96 万后压缩约 112 万约 15%8~10 次40 万周额度主动拆会话和压缩约 79 万约 5%3~4 次用(112 - 79) / 112算下来节省了大约 29.5%和题目里“省近三成”的结论基本吻合。由于这段测试是我在真实开发节奏里做的环境不完美数字会有浮动但方向是稳定的。3.2 token 费、时间费、返工费三笔账拆开看为什么省这么多拆成三笔账就清楚了。第一笔是 token 费。长会话模式下每次请求都带着巨大的历史而短会话模式下每次请求携带的上下文被压缩到只剩当前任务相关的部分。同样完成一个需求总 token 消耗能差出小一半。第二笔是时间费。模型处理长上下文的时间更长尤其是 tps 受限时一个请求从发出到返回可能要多等好几秒。一整天加起来这种等待非常可观虽然没有直接扣钱但浪费的是实际开发时间。第三笔是返工费。前面说过长会话失忆会导致反复解释而短会话因为每次只聚焦一个任务模型对目标的把握往往更好。对照里返工轮次从 8~10 次降到 3~4 次这部分省下来的 token 和精力是最划算的。3.3 这套计算很容易抄到自己的项目里不用完全照抄我的数字你可以用自己的账单做一次复盘。在 Claude Code 里定期跑一下/cost命令可以看到当前会话累计消耗在 Anthropic 控制台的 Usage 页面又可以按周看总 token 量。把这两组数据拉出来和你每个月实际干的活对比基本就能判断自己是不是处于“长会话高消耗”的状态。更简单的判断办法是记录自己每次/compact触发的时机如果经常聊到四五万 token 甚至更多才想起压缩而对话里又频繁出现“我刚才不是说过吗”这种场景那你就是长会话高消耗的典型用户。40 万周额度可能不适合所有人但按周给自己设一个 token 预算、强制拆分会话值得每个人尝试一个月。4. 实操落地从默认聊到96万改成主动控制40万4.1 先看配置再动手settings.json 三项关键值配置 Claude Code 的位置通常在~/.claude/settings.json部分项目里也可以用项目级配置覆盖。真正值得关注的是三个字段{ maxTokens: 20000, autoCompactThreshold: 5000, model: claude-sonnet-4-5 }这里的maxTokens代表模型单次请求的上下文窗口上限autoCompactThreshold是触发自动压缩的阈值通常按maxTokens的一个比例来设。我的建议是主动把autoCompactThreshold调低比如maxTokens设为 20k 时阈值设在 4k~5k这样会话更早在对话初期就自动清理历史而不是一直拖到几十万 token 才“清算”。值得注意的是不同版本对这两个字段的读取方式可能有差异改动后重启 Claude Code 再跑一次/context确认当前上下文占用是否生效。如果命令显示没有变化检查一下是否同时存在项目级settings.json覆盖了你的全局配置。4.2 手动干预三连/context /cost /compact单纯改配置还不够因为自动压缩触发时历史的摘要损失可能已经发生。真正有效的是把手动干预变成习惯我的组合是“三连”。第 1 步随时看/context。这个命令会显示当前 transcript 里上下文占用的百分比我一般只要看到超过 50% 就开始准备收尾而不是继续聊。第 2 步算账用/cost。输入这个命令会列出当前会话累计消耗的 token 和费用估算可以理解为“这一单已经花了多少钱”。我习惯在每个任务完成一小节时看一眼如果某个需求花了超过预算就立刻重新审视是不是问题问得太绕。第 3 步果断用/compact。手动压缩比等待自动压缩更可控因为它会及时清理历史。代价是按下确认后模型需要根据摘要重新“进入状态”所以最好把当前结论写进一个本地文档再压缩防止摘要损失。这套操作组合起来就是“盯住上下文、盯住费用、及时切割”。不需要额外装任何插件纯靠内置命令就能把会话控制在比较健康的状态。4.3 会话拆分与任务清单法控制周额度的另一面是把“一个大杂烩会话”拆成“多个专题会话”。我的操作习惯是这样的每个功能点单独开一个会话比如“修登录接口的 500 报错”“优化列表页查询”“补一条数据库索引”一个会话只干一件事。任务完成后立刻跑一次/compact把当前结论保存到项目笔记里然后关掉这个会话。如果一个需求特别大我会在开始时把任务拆成清单明确每个子任务结束的边界。比如“先完成数据模型改动再写接口再调前端联调”每个子任务之间我会主动开新会话。这样做的好处是模型不需要同时维护几十个文件的长上下文每个会话都很轻每轮请求的 token 消耗也低。这个方法在团队协作时也适用。哪怕你们用的是同一个共享账号只要每个子任务都有新会话汇总时按笔记和 commit 记录恢复上下文效率远高于让模型在一个会话里从头扛到尾。5. 一周实测后的发现与几个容易踩的坑5.1 把 autoCompactThreshold 调太低反而变笨我觉得最值得提醒的一点是不要为了省钱把阈值设得过于激进。我曾试过把autoCompactThreshold压到 1000 token结果几乎每几轮对话就触发一次压缩模型每次都在“回忆”和“摘要”之间挣扎具体效果是它经常忘记当前正在改什么文件回答质量明显下降。这说明压缩既省 token 也损失细节阈值太低会让模型始终处于“半失忆”状态。合理的位置应当是让模型有足够上下文完成当前任务但不要让它背着前面几小时的废话。经过几轮调试我认为 4k~6k 是一个相对均衡的区间具体还要看模型和任务类型。5.2 旧会话的数据仍然在后台计费另一个坑是你以为关闭会话就万事大吉但如果你保留了旧会话的日志文件或历史缓存某些情况下这些数据会在一段时间内继续产生计费或存储成本。我一开始没有清理旧会话结果看账单时发现每周多出来几百 k token 的“幽灵消耗”。解决办法是定期清理不需要的会话记录在配置里把会话历史保留期限调短一些或者至少每周手动整理一次。这个动作不复杂但对控制成本非常有效。5.3 预算撞线时怎么安全切走最后是预算撞线的问题。你设了 40 万周额度某天突然一个任务特别重眼看就要超了。这时候千万别趁着剩余 context 硬聊正确做法是先跑/cost看当前累计再跑到项目笔记里把已完成的设计决策和关键代码片段存档然后开新会话继续。这本质上就是“手动 checkpoint”。Claude Code 本身没有完美的断点续传但你把关键结论抄进笔记、再在新会话里贴出来相当于给自己做了一个轻量级存档。比起在旧会话里硬撑着超预算这个操作又省 token 又保质量。最后说一句我的体会我后来没有死守 40 万这个数字而是把它当成一个“预算仪表盘”只要感觉某个会话已经开始拖泥带水、开始反复解释同一件事就主动重启话题。真正省钱的从来不是某个阈值本身而是它对会话质量的倒逼。如果你也想控制 Claude Code 的 token 消耗别急着抄配置先连续记一周自己每个会话的/cost再决定把每周额度设在哪个位置。数据会告诉你该截断的不是对话而是那些拖得很长却产出很少的“伪深度工作”。