claude code 关闭 1m 上下文怎么配

CLAUDE_CODE_DISABLE_1M_CONTEXT 在 v2.1.223 起对所有原生 1M 模型压到 200K；含启动警告与未知模型窗口开关。

claude code 关闭 1m 上下文怎么配

额度吃紧、或自研网关对超长上下文不稳定时，有人会设环境变量把 Claude Code 从 1M 窗口拉下来。v2.1.223 改了 CLAUDE_CODE_DISABLE_1M_CONTEXT 的覆盖面：不再只拦一份写死的模型列表，而是对所有「原生带 1M 窗口」的 Claude 模型统一压到 200K，并靠 auto-compaction 维持。查 claude code 关闭 1m 上下文怎么配 时，还要分清：关 1M 不等于关压缩，启动时的 warning 也不等于配置失败。

作者：CodePass 技术编辑

环境变量怎么写

在启动 Claude Code 的同一 shell 或 systemd / launchd 单元里设置：

export CLAUDE_CODE_DISABLE_1M_CONTEXT=1

任意非空真值通常即生效（与多数 CLAUDE_CODE_* 开关一致；若你司镜像文档写了 true/1 以外格式，按镜像文档来）。设置后新开进程才会吃到；已在跑的会话不会热更新。

macOS 长期生效可放进 ~/.zshrc；CI agent 容器则在 job env 或 secret 映射里注入。Team 统一策略有时会和 Claude Code 2.1.223 托管设置合并规则 一起下发：同版 release 提到 server 侧 managed settings 与本地 env block 的合并方式变了，若你既关 1M 又吃 MDM 配置，升级后值得对一眼 env 是否被覆盖。

v2.1.223 起机制变宽了

官方 changelog 原文：

Changed CLAUDE_CODE_DISABLE_1M_CONTEXT to hold every Claude model with a native 1M window to 200K via auto-compaction, not just a fixed list; a startup warning now appears when auto-compaction isn't holding the session to 200K

可拆成四句事实：

  1. 开关作用对象是「原生 1M 窗口」的 Claude 模型全集，而不是旧版里 enumerated 的那几个 ID。
  2. 目标上限是 200K，手段是 auto-compaction（自动压缩历史），不是静默截断到第 N 个 token 就丢后面。
  3. 若压缩没能把会话压在 200K，启动阶段会出现 warning。
  4. 因此看到 warning 时，应查的是「压缩为何没跟上」或「是否还有别的路径把上下文撑大」，而不是删掉变量假装没事。

若你之前设过这个变量却感觉「换了个新 1M 模型名就不生效」，在 2.1.223 之后这类漏网之鱼应减少；仍异常时先确认客户端版本 ≥ 2.1.223，并对照下一节的未知模型窗口 enforcement。

启动 warning 该怎么读

warning 的触发条件是 changelog 里的 negation：auto-compaction 没有在把 session hold 在 200K。常见诱因包括：单轮注入超大文件、MCP 工具结果暴涨、或 fork/resume 会话带着异常大的 attachment（同版也修了 malformed diagnostics attachment 导致每轮失败的一类 bug，见 2.1.222 变更摘要 与 2.1.223 修复项）。

处理顺序建议：

  1. 看 warning 全文是否点名 model ID 或 compaction 状态（保留原文便于搜 issue）。
  2. 用 /context 或版本内置的上下文可视化（子命令名随 CLI 版本变）看哪几块占体积。
  3. 缩短 MCP 返回、拆会话，或主动 /compact，再重启 CLI 看 warning 是否还在。

warning 不是「变量写错了」的同义词；变量可能已经生效，只是当前会话负载仍超过 200K 目标，压缩尚未完成或来不及完成。

别误以为关掉 1M 就没有压缩

DISABLE_1M 名字像「禁用上下文能力」，实际行为是 cap 到 200K 再加 auto-compaction。长任务仍会 summarization，只是上限从 1M 量级收到 200K 量级。这和「把 compaction 全关、硬塞满窗口直到 API 报错」不是一回事。

从成本角度，200K 上限往往比 1M 更省输入 token，但压缩本身也有 summarization 调用与信息损失风险。哪些内容该留、哪些该压，和 AI Agent 浪费 token 怎么省 里讲的「脏上下文、重复贴全文件」是同一账本：关 1M 解决的是窗口上限，不替代 surgical context。

若你的真实诉求是「网关经常在 800K 附近 OOM」，关 1M 通常比硬开满窗更稳；若诉求是「完全不要自动摘要、我要每一字原文」，单靠这个变量达不到，需要另查 compaction 相关设置（不在 2.1.223 这条 changelog 里，本文不臆造开关名）。

未知模型 ID：CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT

同版还有一条并行变更：

Changed auto-compact to keep sessions on unrecognized model IDs within the assumed context window instead of letting them grow past it; set CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1 to restore the previous behavior

含义简述：

  • 默认（2.1.223+）：Claude Code 对认不出的 model ID 也会按「假设的 context window」做 auto-compact，避免会话无限长大直到远端拒绝。
  • 设 CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1：回到旧行为，即不对未知 ID 做这层 enforcement。

典型场景是走 ANTHROPIC_BASE_URL 自研网关、或 Bedrock/Vertex 上 provider-prefixed ID（2.1.223 也修了 gateway 隐藏 vertex_ai/claude-* 一类注册模型的 bug）。网关返回的字符串若不在客户端内置表里，以前可能野蛮生长；现在默认会压，但假设窗口若与实际不符，可能出现过早 compact 或仍 warning。

排查分叉：

  • 过早 compact、怀疑窗口估小了 → 在确认网关真实窗口后，临时设 DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1 对比行为（仅调试，生产慎用）。
  • 会话仍暴涨 → 保持 enforcement 开，并同时开 DISABLE_1M_CONTEXT 若你在用原生 1M 模型。

两个变量正交：一个管「原生 1M Claude 是否收到 200K」；一个管「未知 ID 是否做 assumed window enforcement」。

何时值得开、何时别开

建议开 CLAUDE_CODE_DISABLE_1M_CONTEXT 的情况：个人 Max/Team 额度紧、需要可预期的 200K 账单上限；公司 proxy 或 自定义 BASE_URL 网关 对 >200K payload 不稳定；你要和同事对齐「 everyone 200K」减少「有人 1M 有人 200K」的 support 噪音。

可以不开的情况：任务确实需要整仓级 1M 推理且额度允许；你已靠 workflow 拆会话，实际上从未触达 1M；关闭后频繁 compact 导致 agent 丢关键决策记录，返工成本高于省下的 token。

参考资料