Claude Code 省钱技巧排行榜：200K与自动压缩对比

聊聊近期Claude Code用户群里热议的一个话题——恰好我也踩过这个坑。

去年三月左右，Claude Code和Opus率先将默认上下文窗口扩展到100万token。对于总嫌“不够用”的人而言，这曾是个好消息。但实际体验下来，百万窗口带来的并非全是蜜糖，反而藏着隐形成本。简单总结：窗口太大，既降智又烧钱。降智毁项目，烧钱毁预算，两件事碰到一起就麻烦了。

有次我把上下文推到75万到80万token左右，模型直接表现出明显的弱智行为：一个简单的逻辑问题反复搞不定，试了多次毫无改善。另一次更夸张，缓存超时后，仅仅一句话就烧掉了我近40%的配额，且没有任何有效输出，让人非常无语。

所以今天就来拆解这个上下文控制坑，以及如何填平它。

1、默认 100 万上下文

100万上下文，如今成为不少国产模型跟进的卖点——它们把“支持百万token”当作碾压级的宣传点。但实际上，Claude Code和Opus早在3月左右就默认是1M上下文了。

上下文扩大确实有好处，比如可以塞更多内容，不用频繁手动压缩。但硬币的两面在这体现得非常充分：

上文大了降智且烧Token，烧Token费钱，降智费项目。

文字说得很直白，但实际体验远比这几个字猛烈。我遇到的情况并非孤例——Claude Code社区里不少用户被这个1M窗口搞得很惨。

2、设置成 200K 上下文

经历了那次“一烧40%配额”的暴击后，我开始有意识地控制上下文长度：几个问题解决后就马上重启新对话。但频繁手动操作终究不是长久之计。

有意思的是，Opus 4.8更新后，Claude客户端曾默认把上下文设成了200K——那段时间用起来非常舒服，还没到200K就自动压缩了，完全不用操心。但好景不长，一次小更新后，又悄悄变回了1M上下文。策略反复跳动，让人摸不着头脑。

最后决定自己动手，通过环境变量限制上下文。

具体来说，添加一个环境变量即可搞定：

CLAUDE_CODE_DISABLE_1M_CONTEXT=1

Windows平台上，我手动添加了这个系统环境变量，图个省事。

本以为这样就能高枕无忧，但实际跑起来，新问题立刻出现了：

从图上能看到，上限已显示为200K，但实际上下文已经达到了302.9K——明显超了。这个逻辑不太对，期望的是在200K之前就自动压缩，结果却冲过了头。

这时我跑去问Opus 4.8，它建议直接修改配置文件：~/.claude/settings.json。

具体改法如下：

{
  "env": {
    "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
  },
  "autoCompactEnabled": true,
  "autoCompactWindow": 200000
}

核心思路是：让auto-compact按20万窗口计算压缩触发百分比，而不是底层那100万。这样一来，压缩阈值才能真正卡到200K的量级。

也就是说，光关闭1M上下文还不够，还得将压缩窗口明确定义为200000，并确认自动压缩已启动——它一般默认启用。

让设置生效需注意两点：

• 必须完全重启Claude（退出进程重开，不是Ctrl+R或重载界面）。环境变量只在会话开始生效。
• 用/status或观察状态行，确认窗口显示为200K。
• 正常使用中，当上下文接近20万时，应该在64%~75%（大约13万~15万）自动触发压缩，不会再冲过200K。

3、自动压缩

这步完成后，按说应该万无一失了——Opus 4.8根据文档设定，自己设置的参数。但从实际跑下来看，又出现了新的“状况”。

这次确实没超过200K：它在85%（相当于170K左右）时触发了自动压缩。然后，压缩跑了整整16分钟还没结束，几乎到了卡死的状态。

更令人抓狂的是这个情况：

模型直接停下来，什么都不干了，只提示“上下文太长了”，要么手动压缩，要么开启新会话。一旦尝试压缩，就直接卡死。

终端里的表现也类似：

终端稍好一点——能看到压缩进度：上下文用掉83%就自动开始压缩，但进度条从0%跑到95%后，就彻底不动了。

这下真被搞死了——好多任务开发到一半，因为上下文达到上限且无法压缩，完全卡住了。

找了一圈，最终去问了Grok。Grok表示这个问题其他用户也遇到过，并给了三套方案：

1、立即中断方案：
按两次Esc尝试回退几条消息，然后再试 /compact 命令。
如果完全卡死，Ctrl + C 中断当前操作，再尝试手动 /compact。
​
2、重启会话恢复（最有效）：
​
完全关闭终端。
重新打开，用 claude --resume 选择对应的会话。
立即切换模型（/model 换成 Sonnet 4.5 或其它模型），发一条简单的消息，比如 "What happened?"。
成功压缩后，再切回原来的模型继续。
该方案被很多用户验证有效——强行通过压缩。
​
3、预防为主（强烈建议）：
​
提前手动压缩：在上下文使用率到60%-70%时主动 /compact，不要等到90%以上自动触发。
用 CLAUDE.md 文件固定核心规则和项目信息（压缩时会优先保留）。
定期 /clear + 手动总结关键点，或导出历史并新建会话。
少让模型输出巨型日志；必要时用工具过滤输出。

第一个方案按Esc，怕影响代码，我没有尝试——但后来查到它确实只会回退消息而不会丢失代码。

我选择了第二个方案。该方法被Grok标注为最有效的workaround，换句人话说就是：最有效的“骚操作”。

确实好用：Opus 4.8压了半天压不下去，切换成Haiku 4.5立马就压缩成功了。再切回去，对话就能继续了——配额消耗大概只少了2%，完全可以接受。

另外Grok也提到了手动压缩的要点：别等到自动压缩再处理。这个建议很实用。

不过说到这里，心里还是有些不甘。就在前几天，什么都不用配置、不用手动操作，居然跑得格外顺畅：不需要自己配置200K，不需要自己压缩，全自动推进、不降智、消耗也很低。 如果后面对话依然这么丝滑，那就真的太好了。

4、补充知识

在折腾压缩的过程中，有一个绕不过去的问题：压缩是在本地完成的，然后上传到服务端？还是服务端做好，再把结果传给本地？

此外，压缩过程中需不需要联网？一次压缩要消耗多少token？

通过查询与实践，结果大致是：压缩必须联网。

关于token消耗：

• 压缩完成后，后续对话的输入token会大幅减少，所以长期来看有利于节省。
• 但单次压缩本身比较贵，如果频繁触发，成本其实不低。

精打细算过日子太难了：不压不行，压得不好又费钱。1M窗口太贵，200K窗口如果频繁压缩也不便宜。这个问题套用缓存领域的一句话，有它的本质：5分钟缓存和1小时缓存，各有各的痛点。5分钟缓存配合1M上下文，如果节奏控制不好，分分钟把配额烧光。

一些偏经验性的建议：可以设置一个定时任务，比如每4分钟发一条非常简单的“打招呼”消息来刷新缓存——这是最省资源的做法。如果选择200K窗口，心理负担会小很多：即使缓存过期了，重新加载的数据量也不算大。

按照200K窗口加手动/自动结合的方式使用一阵子之后，Opus 4.8配合High配置确实很耐用。上午改了一堆功能，十几轮对话下来，只用了50%的配额。这在以前简直是难以想象的——以前可能两三轮对话配额就用完了。究竟是Claude Code用了什么黑科技、偷偷增加了配额，还是说我们上下文和缓存管理终于步入正轨，开始高效掌控节奏了？这个只有时间能给出答案。