1. 为什么你的 Claude Code 越用越贵1M 上下文与压缩失控Claude Code 默认走 1M 上下文这件事很多人是后知后觉的。你只是正常聊天、改代码、让它读几个文件上下文就悄悄涨到几十万 token然后某一次缓存过期一句话把配额烧掉一大截还什么都没干成。更难受的是模型在超长上下文里会明显变笨一个简单 bug 反复改不对你以为是它状态不好其实是上下文太长了。这篇要解决的就是这件事把 Claude Code 的上下文上限摁回 200K并让自动压缩在接近 200K 之前就触发而不是冲到 300K 才动手。核心落在~/.claude/settings.json里的三个字段CLAUDE_CODE_DISABLE_1M_CONTEXT、autoCompactEnabled、autoCompactWindow。我会给你一份可直接复制的配置骨架再逐项说明每个字段干什么、生效顺序是什么、怎么验证压缩真的被触发了。适合谁看已经在用 Claude Code 做日常开发、被配额和降智折磨过、想自己掌控上下文节奏的人。如果你还没装 Claude Code这篇的配置逻辑同样适用于理解它的上下文管理机制但操作步骤以已安装为前提。先说结论避免你走弯路只设CLAUDE_CODE_DISABLE_1M_CONTEXT1是不够的。它只把窗口上限标成 200K但自动压缩的百分比可能仍按底层 1M 计算于是你会看到状态行显示 200K、实际上下文却干到 300K 的诡异现象。真正把压缩阈值摁到 200K必须同时设置autoCompactWindow。2. 前置准备TaoToken 接入与 Claude Code 环境确认在动settings.json之前先把接入层理顺。Claude Code 需要一个兼容 Anthropic 协议的 API 端点我用的是 TaoToken 的接入方式官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。它的作用是给你一个统一的入口去调用模型省得自己维护多套 key 和端点。你需要先拿到 API Key。打开 https://taotoken.net/api-keys 创建复制出来备用。注意这个 key 只显示一次丢了就重新建。然后确认 Claude Code 能读到你的环境变量。Claude Code 读取配置的顺序大致是进程环境变量 →~/.claude/settings.json的env段 → 项目级.claude/settings.json。也就是说settings.json里env段写的值会覆盖同名系统环境变量这一点很关键后面排障会用到。如果你还没配过接入先确认这两件事一是ANTHROPIC_BASE_URL指向 https://taotoken.net/api 二是ANTHROPIC_API_KEY是你的 TaoToken key。这两个可以放在系统环境变量里也可以直接写进settings.json的env段。我倾向写进settings.json因为换项目、换机器时更好迁移。注意环境变量只对新启动的会话生效。改完配置后必须完全退出 Claude Code 进程再重开CtrlR 或界面重载不算。3. 可复制配置settings.json 骨架与字段逐项说明下面是完整的~/.claude/settings.json骨架。如果你文件里已有其他字段把这几项合并进去不要整个覆盖。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, CLAUDE_CODE_DISABLE_1M_CONTEXT: 1 }, autoCompactEnabled: true, autoCompactWindow: 200000 }逐项拆开讲。CLAUDE_CODE_DISABLE_1M_CONTEXT设为1作用是关闭 1M 上下文模式让 Claude Code 把窗口上限按 200K 处理。注意值是字符串1不是数字1环境变量本质都是字符串写错类型可能不生效。autoCompactEnabled设为true开启自动压缩。这个默认一般是开的但显式写出来更稳避免某次更新后默认值变了你还不知道。autoCompactWindow设为200000这是整份配置的核心。它告诉自动压缩逻辑按 20 万 token 的窗口去算触发百分比。如果不设这一项压缩阈值可能仍按底层 1M 算于是 80% 才触发也就是 80 万 token 才压缩那 200K 上限形同虚设。生效顺序是这样的进程启动时先读系统环境变量再读settings.json的env段并覆盖同名项然后初始化上下文窗口和压缩策略。CLAUDE_CODE_DISABLE_1M_CONTEXT决定窗口上限autoCompactWindow决定压缩触发基准两者配合才完整。提示autoCompactWindow的值是 token 数不是百分比。写 200000 表示 20 万 token 窗口。如果你想更保守可以设成 180000让压缩更早触发。4. 验证请求确认 200K 上限与压缩触发行为配置写完重启 Claude Code然后做三步验证。第一步看窗口上限。在会话里输入/status或者看状态行显示。正常情况下应该显示 200K 窗口而不是 1M。如果还显示 1M说明CLAUDE_CODE_DISABLE_1M_CONTEXT没生效回去检查值是不是字符串1、有没有完全重启进程。第二步观察压缩触发点。正常聊到接近 20 万 token 时应该在 64% 到 75% 之间也就是大约 13 万到 15 万 token 时自动压缩而不是冲过 200K。你可以故意让它读几个大文件把上下文推上去盯着状态行的百分比变化。第三步确认压缩真的执行了。压缩发生时你会看到进度提示压缩完成后上下文占用会明显下降。如果压缩卡在 95% 不动那是另一个问题下一节专门讲。这里给一个手动触发压缩的命令用来对比自动压缩行为# 在 Claude Code 会话内输入 /compact手动/compact和自动压缩走的是同一套服务端逻辑区别只是触发时机。手动压缩适合你在上下文到 60% 到 70% 时主动做别等自动触发。如果你只是想验证模型对话是否正常可以先用 https://taotoken.net/api 的模型对话入口发一条简单请求确认 key 和端点没问题再回到 Claude Code 里调上下文。模型对话入口在 https://taotoken.net/models 接入文档在 https://taotoken.net/doc 。5. 本篇常见错排查压缩卡死、超限、不生效这一节是踩坑合集按现象对号入座。现象一状态行显示 200K实际上下文干到 300K。原因是只设了CLAUDE_CODE_DISABLE_1M_CONTEXT没设autoCompactWindow。压缩阈值仍按 1M 算所以 200K 上限没被真正执行。补上autoCompactWindow: 200000并重启。现象二压缩卡在 85% 到 95% 不动进度条跑一半停住。这是压缩本身卡死不是配置问题。最有效的处理方式是重启会话并临时切换模型完全关闭终端重开用claude --resume选回原会话输入/model换成另一个模型发一条简单消息触发压缩压缩通过后再切回原模型。实测切换模型后压缩能立刻完成配额只多花一点点。现象三改完配置没反应。九成是没完全重启进程。环境变量和settings.json的env段都只对新会话生效CtrlR 或界面重载不算重启。彻底退出再开。现象四settings.json里env段和系统环境变量冲突。记住settings.json的env段优先级更高会覆盖系统环境变量。如果你在系统里设了CLAUDE_CODE_DISABLE_1M_CONTEXT0但settings.json里写1最终生效的是1。排查时以settings.json为准。现象五压缩一次消耗多少 token。压缩是服务端操作需要联网由 API 完成。典型情况是输入 15 万到 18 万 token 的历史输出 3k 到 5k token 的总结这部分单独计费。压缩后后续输入 token 大幅减少长期看是省的但频繁压缩本身不便宜。所以策略是提前手动压缩别等自动触发。注意压缩过程需要联网离线状态下会报错或卡住。如果你在网络不稳的环境里用提前手动/compact更稳。6. 长期编码与 Agent 场景把上下文节奏握在自己手里配置只是第一步真正省钱靠的是使用节奏。我自己的习惯是上下文到 60% 到 70% 就手动/compact不等自动触发用CLAUDE.md固定核心规则和项目信息压缩时会优先保留这些内容定期/clear加手动总结关键点或者导出历史新建会话少让模型输出巨型日志必要时用工具先过滤再喂给它。如果你长期用 Claude Code 做编码和 Agent 任务可以考虑 Coding Plan 这类按周期计费的方式比按量计费更好控预算入口在 https://taotoken.net/coding-plan 。配合 200K 窗口和提前压缩一个上午改一堆功能只用到一半配额是能做到的。回到最开始那个问题为什么以前什么都不用配就很丝滑现在要自己折腾因为默认策略会变1M 和 200K 之间来回切。与其等它变不如自己把settings.json写死让窗口和压缩阈值都按你的预期走。这份骨架你直接抄改完重启用/status确认然后正常开发就行。压缩卡死时记得切模型这个后手比干等强得多。
Claude Code 省钱小妙招！200K 与自动压缩的 settings.json 配置骨架
1. 为什么你的 Claude Code 越用越贵1M 上下文与压缩失控Claude Code 默认走 1M 上下文这件事很多人是后知后觉的。你只是正常聊天、改代码、让它读几个文件上下文就悄悄涨到几十万 token然后某一次缓存过期一句话把配额烧掉一大截还什么都没干成。更难受的是模型在超长上下文里会明显变笨一个简单 bug 反复改不对你以为是它状态不好其实是上下文太长了。这篇要解决的就是这件事把 Claude Code 的上下文上限摁回 200K并让自动压缩在接近 200K 之前就触发而不是冲到 300K 才动手。核心落在~/.claude/settings.json里的三个字段CLAUDE_CODE_DISABLE_1M_CONTEXT、autoCompactEnabled、autoCompactWindow。我会给你一份可直接复制的配置骨架再逐项说明每个字段干什么、生效顺序是什么、怎么验证压缩真的被触发了。适合谁看已经在用 Claude Code 做日常开发、被配额和降智折磨过、想自己掌控上下文节奏的人。如果你还没装 Claude Code这篇的配置逻辑同样适用于理解它的上下文管理机制但操作步骤以已安装为前提。先说结论避免你走弯路只设CLAUDE_CODE_DISABLE_1M_CONTEXT1是不够的。它只把窗口上限标成 200K但自动压缩的百分比可能仍按底层 1M 计算于是你会看到状态行显示 200K、实际上下文却干到 300K 的诡异现象。真正把压缩阈值摁到 200K必须同时设置autoCompactWindow。2. 前置准备TaoToken 接入与 Claude Code 环境确认在动settings.json之前先把接入层理顺。Claude Code 需要一个兼容 Anthropic 协议的 API 端点我用的是 TaoToken 的接入方式官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。它的作用是给你一个统一的入口去调用模型省得自己维护多套 key 和端点。你需要先拿到 API Key。打开 https://taotoken.net/api-keys 创建复制出来备用。注意这个 key 只显示一次丢了就重新建。然后确认 Claude Code 能读到你的环境变量。Claude Code 读取配置的顺序大致是进程环境变量 →~/.claude/settings.json的env段 → 项目级.claude/settings.json。也就是说settings.json里env段写的值会覆盖同名系统环境变量这一点很关键后面排障会用到。如果你还没配过接入先确认这两件事一是ANTHROPIC_BASE_URL指向 https://taotoken.net/api 二是ANTHROPIC_API_KEY是你的 TaoToken key。这两个可以放在系统环境变量里也可以直接写进settings.json的env段。我倾向写进settings.json因为换项目、换机器时更好迁移。注意环境变量只对新启动的会话生效。改完配置后必须完全退出 Claude Code 进程再重开CtrlR 或界面重载不算。3. 可复制配置settings.json 骨架与字段逐项说明下面是完整的~/.claude/settings.json骨架。如果你文件里已有其他字段把这几项合并进去不要整个覆盖。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: 你的_TaoToken_Key, CLAUDE_CODE_DISABLE_1M_CONTEXT: 1 }, autoCompactEnabled: true, autoCompactWindow: 200000 }逐项拆开讲。CLAUDE_CODE_DISABLE_1M_CONTEXT设为1作用是关闭 1M 上下文模式让 Claude Code 把窗口上限按 200K 处理。注意值是字符串1不是数字1环境变量本质都是字符串写错类型可能不生效。autoCompactEnabled设为true开启自动压缩。这个默认一般是开的但显式写出来更稳避免某次更新后默认值变了你还不知道。autoCompactWindow设为200000这是整份配置的核心。它告诉自动压缩逻辑按 20 万 token 的窗口去算触发百分比。如果不设这一项压缩阈值可能仍按底层 1M 算于是 80% 才触发也就是 80 万 token 才压缩那 200K 上限形同虚设。生效顺序是这样的进程启动时先读系统环境变量再读settings.json的env段并覆盖同名项然后初始化上下文窗口和压缩策略。CLAUDE_CODE_DISABLE_1M_CONTEXT决定窗口上限autoCompactWindow决定压缩触发基准两者配合才完整。提示autoCompactWindow的值是 token 数不是百分比。写 200000 表示 20 万 token 窗口。如果你想更保守可以设成 180000让压缩更早触发。4. 验证请求确认 200K 上限与压缩触发行为配置写完重启 Claude Code然后做三步验证。第一步看窗口上限。在会话里输入/status或者看状态行显示。正常情况下应该显示 200K 窗口而不是 1M。如果还显示 1M说明CLAUDE_CODE_DISABLE_1M_CONTEXT没生效回去检查值是不是字符串1、有没有完全重启进程。第二步观察压缩触发点。正常聊到接近 20 万 token 时应该在 64% 到 75% 之间也就是大约 13 万到 15 万 token 时自动压缩而不是冲过 200K。你可以故意让它读几个大文件把上下文推上去盯着状态行的百分比变化。第三步确认压缩真的执行了。压缩发生时你会看到进度提示压缩完成后上下文占用会明显下降。如果压缩卡在 95% 不动那是另一个问题下一节专门讲。这里给一个手动触发压缩的命令用来对比自动压缩行为# 在 Claude Code 会话内输入 /compact手动/compact和自动压缩走的是同一套服务端逻辑区别只是触发时机。手动压缩适合你在上下文到 60% 到 70% 时主动做别等自动触发。如果你只是想验证模型对话是否正常可以先用 https://taotoken.net/api 的模型对话入口发一条简单请求确认 key 和端点没问题再回到 Claude Code 里调上下文。模型对话入口在 https://taotoken.net/models 接入文档在 https://taotoken.net/doc 。5. 本篇常见错排查压缩卡死、超限、不生效这一节是踩坑合集按现象对号入座。现象一状态行显示 200K实际上下文干到 300K。原因是只设了CLAUDE_CODE_DISABLE_1M_CONTEXT没设autoCompactWindow。压缩阈值仍按 1M 算所以 200K 上限没被真正执行。补上autoCompactWindow: 200000并重启。现象二压缩卡在 85% 到 95% 不动进度条跑一半停住。这是压缩本身卡死不是配置问题。最有效的处理方式是重启会话并临时切换模型完全关闭终端重开用claude --resume选回原会话输入/model换成另一个模型发一条简单消息触发压缩压缩通过后再切回原模型。实测切换模型后压缩能立刻完成配额只多花一点点。现象三改完配置没反应。九成是没完全重启进程。环境变量和settings.json的env段都只对新会话生效CtrlR 或界面重载不算重启。彻底退出再开。现象四settings.json里env段和系统环境变量冲突。记住settings.json的env段优先级更高会覆盖系统环境变量。如果你在系统里设了CLAUDE_CODE_DISABLE_1M_CONTEXT0但settings.json里写1最终生效的是1。排查时以settings.json为准。现象五压缩一次消耗多少 token。压缩是服务端操作需要联网由 API 完成。典型情况是输入 15 万到 18 万 token 的历史输出 3k 到 5k token 的总结这部分单独计费。压缩后后续输入 token 大幅减少长期看是省的但频繁压缩本身不便宜。所以策略是提前手动压缩别等自动触发。注意压缩过程需要联网离线状态下会报错或卡住。如果你在网络不稳的环境里用提前手动/compact更稳。6. 长期编码与 Agent 场景把上下文节奏握在自己手里配置只是第一步真正省钱靠的是使用节奏。我自己的习惯是上下文到 60% 到 70% 就手动/compact不等自动触发用CLAUDE.md固定核心规则和项目信息压缩时会优先保留这些内容定期/clear加手动总结关键点或者导出历史新建会话少让模型输出巨型日志必要时用工具先过滤再喂给它。如果你长期用 Claude Code 做编码和 Agent 任务可以考虑 Coding Plan 这类按周期计费的方式比按量计费更好控预算入口在 https://taotoken.net/coding-plan 。配合 200K 窗口和提前压缩一个上午改一堆功能只用到一半配额是能做到的。回到最开始那个问题为什么以前什么都不用配就很丝滑现在要自己折腾因为默认策略会变1M 和 200K 之间来回切。与其等它变不如自己把settings.json写死让窗口和压缩阈值都按你的预期走。这份骨架你直接抄改完重启用/status确认然后正常开发就行。压缩卡死时记得切模型这个后手比干等强得多。
