上下文窗口

随着对话的增长，您最终会接近上下文窗口的限制。对于长时间运行的对话和代理工作流，服务器端压缩是上下文管理的主要策略。



上下文窗口的工作原理

"Context window"（上下文窗口）是指语言模型在生成响应时可以参考的所有文本，包括响应本身。这与语言模型训练所用的大型数据语料库不同，而是代表模型的"工作记忆"。较大的上下文窗口允许模型处理更复杂和冗长的提示，但更多的上下文并不自动意味着更好。随着令牌数量的增长，准确性和召回率会下降，这种现象被称为上下文衰减（context rot）。这使得精心挑选上下文中的内容与可用空间的大小同样重要。

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

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

• 渐进式令牌累积： 随着对话轮次的推进，每条用户消息和助手响应都会在上下文窗口中累积，并且之前的轮次会被完整保留。
• 上下文窗口容量： 上下文窗口（最多 1M 令牌，取决于模型）容纳对话历史以及 Claude 生成的新输出。
• 输入-输出流程： 每个轮次包括：
  • 输入阶段： 包含所有先前的对话历史以及当前的用户消息
  • 输出阶段： 生成文本响应，该响应成为下一轮输入的一部分

请求中的所有内容都计入上下文窗口：系统提示、messages 中的每条消息（包括工具结果、图像和文档），以及您的工具定义。Claude 在该轮次生成的输出（包括其扩展思考）也计入其中。每个响应都会在其 usage 字段中报告该请求消耗的内容。如果您使用提示缓存，输入计数会被拆分为 input_tokens、cache_read_input_tokens 和 cache_creation_input_tokens，这三者都计入窗口。要在发送请求之前进行估算，请使用令牌计数 API。



各模型的上下文窗口大小

Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5 和 Claude Sonnet 4.6 在 Claude API、Amazon Bedrock、Google Cloud 和 Microsoft Foundry 上具有 1M 令牌的上下文窗口。Claude Mythos Preview 也具有 1M 令牌的上下文窗口。

Claude Fable 5 和 Claude Mythos 5（claude-fable-5 和 claude-mythos-5）也具有 1M 令牌的上下文窗口。对任何具有 1M 令牌上下文窗口的模型的单个请求最多可以生成 128k 个输出令牌（max_tokens）。其他 Claude 模型（包括 Claude Sonnet 4.5）具有 200k 令牌的上下文窗口。

对于每个具有 1M 令牌上下文窗口的模型，1M 是默认值：您不需要 beta 标头，并且长上下文请求按标准定价计费。

单个请求最多可以包含 600 张图像或 PDF 页面（对于具有 200k 令牌上下文窗口的模型为 100 张）。如果您发送许多图像或大型文档，您可能会在达到令牌限制之前达到请求大小限制。

请参阅模型比较表，了解各模型的上下文窗口大小列表。



带思考的上下文窗口

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

思考令牌是您的 max_tokens 参数的一个子集，按输出令牌计费，并计入速率限制。使用自适应思考时，Claude 会动态确定其思考分配，因此思考令牌的使用量会因请求而异。

先前助手轮次的思考块是否保留在上下文窗口中取决于模型。在 Claude Opus 4.5 及更高版本的 Opus 模型、Claude Sonnet 4.6 及更高版本的 Sonnet 模型、Claude Fable 5、Claude Mythos 5 和 Claude Mythos Preview 上，API 默认保留先前的思考块，它们像任何其他输入令牌一样计入上下文窗口。在较早的 Opus 和 Sonnet 模型以及所有 Haiku 模型上，当您将先前的思考块传回时，API 会自动从对话历史中剥离它们，从而为对话内容保留令牌容量。有关每个模型的默认值，请参阅各模型的思考块保留。要在任一方向上覆盖默认值，请使用思考块清除。

下图显示了在剥离先前思考块的模型上启用思考时如何管理令牌：

• 剥离思考块： 在剥离先前思考块的模型上，思考块（以深灰色显示）在每个轮次的输出阶段生成，但不会作为后续轮次的输入令牌向前传递。您不需要自己剥离思考块：如果您将它们传回，Claude API 会自动剥离它们。
• 计费： 思考令牌在生成时作为输出令牌计费一次。在保留先前思考块的模型上，保留的块随后成为后续请求输入的一部分，并像对话历史的其余部分一样按输入令牌计费。



带思考和工具使用的上下文窗口

下图说明了在剥离先前思考块的模型上将思考与工具使用结合时如何管理令牌：

• 带思考的工具使用注意事项：
  • 当您发布工具结果时，必须包含伴随该工具请求的完整未修改的思考块，包括其签名。
  • API 使用加密签名来验证思考块的真实性。如果您修改思考块，API 会返回错误。

要减少工具定义本身消耗的上下文，请参阅管理工具上下文，或使用工具搜索工具延迟工具定义。



上下文感知

Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5 和 Claude Haiku 4.5 具有上下文感知能力：这些模型在整个对话过程中跟踪其剩余的上下文窗口（即它们的"令牌预算"）。这使模型能够根据剩余空间管理长时间运行的任务，而不是猜测还剩多少令牌。上下文感知是自动的：您无需启用任何内容，也永远不需要自己发送本节中显示的标签。API 会注入它们。



工作原理

在每个请求的系统提示中，API 会向 Claude 提供其总上下文窗口：

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

该预算与您的请求可用的上下文窗口相匹配：Claude Sonnet 5 和 Claude Sonnet 4.6 为 1M 令牌，Claude Sonnet 4.5 和 Claude Haiku 4.5 为 200k 令牌。本节中的示例展示的是具有 200k 令牌上下文窗口的模型。

在每次工具调用之后，API 会向 Claude 提供其剩余容量的更新：

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

图像令牌包含在这些预算中。

Claude Opus 4.7 及更高版本的 Opus 模型、Claude Fable 5 和 Claude Mythos 5 不会收到这些注入的标签。在 Claude Opus 4.7 及更高版本的 Opus 模型、Claude Fable 5 和 Claude Mythos 5 上，您可以使用任务预算（处于 beta 阶段）为模型提供明确的预算。

有关使用上下文感知的提示指导，请参阅提示最佳实践。



使用压缩管理上下文

如果您的对话经常接近上下文窗口限制，请使用服务器端压缩。压缩会在服务器上自动总结对话的较早部分，因此对话可以在超过上下文窗口限制后继续进行。它在 Claude 4.6 及更高版本的模型和 Claude Mythos Preview 上以 beta 形式提供。

对于更专门的需求，上下文编辑提供了额外的策略：

• 工具结果清除： 在代理工作流中清除旧的工具结果
• 思考块清除： 在使用扩展思考时管理思考块

缓存的提示前缀仍然占用上下文窗口：提示缓存改变的是您为这些令牌支付的费用，而不是它们是否被计入。



上下文窗口溢出行为

如果仅输入就已经超过了模型的上下文窗口，API 会在每个模型上返回 400 invalid_request_error（"prompt is too long"）。

在 Claude 4.5 及更新的模型上，如果输入令牌加上 max_tokens 超过上下文窗口大小，API 会接受该请求。如果生成随后达到上下文窗口限制，它会以 stop_reason: "model_context_window_exceeded" 停止。在较早的模型上，API 会返回验证错误。要在这些模型上选择启用 model_context_window_exceeded 行为，请使用 model-context-window-exceeded-2025-08-26 beta 标头。有关详细信息，请参阅停止原因和回退。

要保持在上下文窗口限制内，请使用令牌计数 API 在向 Claude 发送消息之前估算令牌使用量。



后续步骤