Claude Code 上下文 200k 1M 与自动压缩实操

Claude Code 的 200k 和 1M 到底能装什么

很多人看到 Claude Code 使用 200k 或 1M 上下文，第一反应是把整个仓库贴进去。实际不是。窗口标称值是整个请求的 token 上限，包括系统提示、工具定义、历史对话、当前用户输入、工具返回内容，以及模型要生成的回答。一个空仓库的 Claude Code 会话并不会从 0 开始，它已经有内置指令、可用工具 schema、项目记忆和最近的文件读取记录。按常见会话粗算，200k 模型真正留给历史和新输入的空间大概在 170k 到 185k token 左右；1M 模型看起来更大，但系统指令、工具 schema、缓存和输出预留同样会先吃掉一块，且中转分组未必开放完整 1M。

如果你是在排查 Claude Code 接入与排错完全指南里提到的模型不可用、base_url 配置、分组倍率问题，建议先把会话长度问题区分开。上下文截断不是登录失败，也不是 base_url 错；它通常发生在模型已经能返回内容，但历史里已经塞了太多文件、命令输出或长 prompt。遇到这类现象，可以看请求返回的 usage 和 error type，而不是只看界面上没有回复。

自动压缩什么时候开始起作用

Claude Code 的 compact 是对历史消息做摘要和折叠，不是删除模型窗口。触发时机一般和两个条件有关：一是当前会话 token 接近模型可用上限，二是下一轮工具调用或长回答会让请求超限。界面里可能会先出现压缩提示，也可能在你继续让它读整个目录、把日志都贴出来时直接报错。手动执行 /compact 可以提前把历史压成摘要，保留关键决策、文件路径和未解决问题，丢掉重复的工具原始输出。这个命令适合在连续调试、跑完一批测试、贴过大量 stack trace 之后使用。

一个 prompt 写太长导致截断的真实例子

有一次我在项目里排查构建失败，为了让 Claude Code 看清依赖，直接写了这样的 prompt：把 node_modules/typescript/lib/*.d.ts 和 package-lock.json 全部读出来，再逐个解释为什么构建失败。这句话听起来合理，实际会把大量第三方类型定义和 lockfile 塞进上下文。TypeScript 类型文件本身就很碎，package-lock.json 又常有几万行，工具返回内容加上历史很快超过 200k。API 返回的报错原文会是：

{"type":"error","error":{"type":"invalid_request_error","message":"prompt is too long: 231842 tokens > 200000 maximum"}}

这里的 231842 不是用户手动输入了 23 万汉字，而是 tokenizer 把代码、JSON、路径、空格和工具消息都算进去。修复方式也不是换 1M 就万事大吉，而是缩小读取范围：只让 Claude Code 读 package.json、tsconfig.json、报错涉及的 2-3 个文件，或者先用命令行过滤 lockfile。把全部读出来换成只读 src/api 和最近修改的 5 个文件，上下文压力会立刻下降。

判断剩余空间，别只盯 token 数字

在 Claude Code 里，最省事的检查方式是看当前会话是否频繁触发压缩提示，或者用 /compact 主动压一次。更底层的是看 API 响应里的 usage 字段，尤其 input_tokens、cache_read_input_tokens、cache_creation_input_tokens。缓存命中能降低重复长 prompt 的成本，但不代表缓存内容不占上下文；它只是避免部分重复计费。中转平台上的模型分组也会影响价格，比如 Sonnet 长上下文常见输入价格从每百万 token 几美元到十几美元不等，1M 分组还可能按倍率计费。具体单价最好对照寓守API 模型价格表，尤其是你准备把大量文件一次性喂进去时。

如果你是通过 API 中转跑 Claude Code，base_url 的末尾斜杠、/v1/messages 路径、鉴权头大小写都可能影响请求是否成功。相关细节可以放在 Claude Code中转API配置base_url避坑指南里一起看。上下文长度问题往往不是单独出现的：一个错误的 base_url 会让请求失败，一个过大的 prompt 会让请求在模型侧被拒绝，一个没有缓存的长会话会让账单和延迟同时变差。

让长会话继续可用的三个动作

第一，把读代码拆成定位。先让 Claude Code 用文件路径和关键词搜索，不要让它整目录读取。第二，把一次性调试和长期任务分开。临时跑测试、看日志、改配置，适合短会话；架构评审、多文件重构，适合在压缩后保留一份清晰的任务摘要。第三，观察用量。若你的项目经常接近上限，可以查看大模型调用排行榜了解不同模型的 token 消耗差异，再决定是换更稳的窗口、加缓存，还是拆任务。

一个常见配置片段是这样：ANTHROPIC_BASE_URL 指向你的中转地址，ANTHROPIC_AUTH_TOKEN 放密钥。若你使用支持缓存的分组，还可以观察响应中的 cache_control 是否命中。上下文压缩与配置无关，但配置错误会让你误判为上下文问题。

如果你正在用 Claude Code 做长会话开发，上下文长度、自动压缩和 token 成本最好一起看。需要把模型接入、分组价格和用量放在同一个面板里观察时，可以通过寓守API 接入 Claude Code 相关模型，并在配置前先用小范围文件读取跑一轮，确认 base_url、鉴权和上下文限制都正常，再开始处理更大的任务。