上下文窗口

随着对话增长，你最终会接近上下文窗口限制。对于长时间运行的对话和 agentic 工作流，服务端压缩（server-side compaction） 是上下文管理的主要策略。

上下文窗口如何工作

“上下文窗口”（context window）指语言模型在生成回复时可参考的全部文本，包括回复本身。这不同于语言模型训练所用的大规模语料，而是模型的“工作记忆”。更大的上下文窗口让模型能够处理更复杂、更长的 prompt，但更多上下文并不自动意味着更好。随着 token 数量增长，准确性和召回会下降，这一现象称为 context rot。因此，策选上下文中有什么，与可用空间有多大同样重要。

下图说明了 API 请求的标准上下文窗口行为1：

1 诸如 claude.ai 之类的聊天界面也可以按滚动的“先进先出”方式管理上下文窗口。

• token 逐步累积： 随着对话按 turn 推进，每条 user message 和 assistant 回复都会在上下文窗口中累积，且先前的 turn 会被完整保留。

• 上下文窗口容量： 上下文窗口（最多 1M tokens，取决于模型）保存对话历史，加上 Claude 新生成的输出。

• 输入-输出流程： 每个 turn 包括：

  • 输入阶段： 包含全部先前对话历史加上当前 user message
  • 输出阶段： 生成一段文本回复，该回复会成为下一 turn 输入的一部分

请求中的所有内容都计入上下文窗口：system prompt、messages 中的每条消息（包括工具结果、图片和文档），以及你的工具定义。Claude 为本 turn 生成的输出（包括其 extended thinking）也计入。每次响应都会在 usage 字段中报告该请求消耗了什么。如果你使用 Prompt Caching，输入计数会拆分到 input_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，这三项都计入窗口。要在发送前估算请求，使用 token counting API。

各模型的上下文窗口大小

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5、Claude Sonnet 4.6 和 Claude Mythos Preview 具有 1M-token 上下文窗口。对其中任一模型的单次请求最多可生成 128k 输出 tokens（max_tokens）。其他 Claude 模型，包括 Claude Sonnet 4.5，具有 200k-token 上下文窗口。

对每个具有 1M-token 上下文窗口的模型，1M 是默认值：你不需要 beta header，长上下文请求按 标准定价 计费。

单次请求最多可包含 600 张图片或 PDF 页（对具有 200k-token 上下文窗口的模型为 100）。如果你发送大量图片或大型文档，可能会在达到 token 限制之前先达到 请求大小限制。

各模型上下文窗口大小列表见 模型对比 表。

带 thinking 的上下文窗口

使用 thinking 时，所有输入和输出 tokens（包括 thinking tokens）都计入上下文窗口限制，在多 turn 情况下有一些细微差别。

thinking tokens 是你的 max_tokens 参数的子集，按输出 tokens 计费，并计入速率限制。使用 adaptive thinking 时，Claude 会动态决定其 thinking 分配，因此 thinking token 用量会因请求而异。

先前 assistant turn 中的 thinking blocks 是否留在上下文窗口中取决于模型。在 Claude Opus 4.5 及之后的 Opus 模型、Claude Sonnet 4.6 及之后的 Sonnet 模型、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview 上，API 默认保留先前的 thinking blocks，它们像其他输入 tokens 一样计入上下文窗口。在更早的 Opus 和 Sonnet 模型以及所有 Haiku 模型上，当你把先前的 thinking blocks 传回时，API 会自动从对话历史中剥离它们，从而为对话内容保留 token 容量。各模型默认值见 thinking block 按模型的保留策略。要向任一方向覆盖默认值，使用 thinking block 清除。

下图展示了在会剥离先前 thinking blocks 的模型上启用 thinking 时如何管理 tokens：

• 剥离 thinking blocks： 在会剥离先前 thinking blocks 的模型上，thinking blocks（深灰色所示）在每个 turn 的输出阶段生成，但不会作为后续 turn 的输入 tokens 向前携带。你不需要自己剥离 thinking blocks：如果你把它们传回，Claude API 会自动剥离。
• 计费： thinking tokens 在生成时作为输出 tokens 计费一次。在会保留先前 thinking blocks 的模型上，被保留的 blocks 随后会成为后续请求输入的一部分，并像对话历史的其余部分一样作为输入 tokens 计费。

带 thinking 和工具调用的上下文窗口

下图说明了在会剥离先前 thinking blocks 的模型上，将 thinking 与工具调用结合时如何管理 tokens：

• 将 thinking 与工具调用一起使用时的注意事项：

  • 当你提交工具结果时，必须包含伴随该工具请求的整个未经修改的 thinking block，包括其 signature。
  • API 使用加密签名来验证 thinking block 的真实性。如果你修改了 thinking block，API 会返回错误。

1

<budget:token_budget>200000</budget:token_budget>

1

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>