Anthropic 取消长上下文溢价，Claude 百万 token 窗口按标准计费

Anthropic 上周五宣布，Claude Opus 4.6 和 Claude Sonnet 4.6 的百万 token 上下文窗口（Context Window）现已正式可用。关键变化是：标准定价取代了之前的长上下文溢价费率，后者在提示超过一定大小时会触发。

这两款模型在今年 2 月相继发布。Claude Opus 4.6 是 Anthropic 的旗舰模型，专为需要跨大型内部数据集进行持续推理和复杂编码任务的企业工作负载设计。Claude Sonnet 4.6 则是更高效的通用模型，面向高吞吐量的开发者使用和生产应用，在保持强大推理性能的同时成本低于 Opus。

两款模型都支持百万 token 的上下文窗口——这个上限允许开发者将大量信息放入单个提示中，比如整个代码仓库、长篇研究论文、法律文件或需要 AI 系统一起分析的大型内部文档集合。

但之前有个重要限制：虽然模型技术上支持接近百万 token 的提示，但超过约 20 万 token 的请求会按更高的“长上下文”定价层级计费，整个请求都会进入溢价费率带。

现在，Anthropic 移除了这个定价区别。

在新的安排下，无论提示大小如何，请求都按相同的每 token 费率计费。包含数十万 token 的提示现在与更小的请求使用相同的每 token 费率定价。

通往百万 token 之路

Anthropic 向百万 token 上下文窗口的推进在过去两年中分阶段展开。

早期的 Claude 模型推出时带有 20 万 token 的限制，这在当时已经是公开可用的最大上下文窗口之一。当 Anthropic 在 2024 年初推出 Claude 3 系列时，公司指出这些模型技术上能够处理超过百万 token 的输入，尽管对这些更大上下文的访问最初仅限于“特定用例”且需申请。

百万 token 窗口的首次公开发布是在 2025 年 8 月，Anthropic 在 Claude Sonnet 4 中引入了该功能。这一跳跃代表了比早期 Sonnet 模型五倍的增加，尽管带有与提示大小相关的分层定价结构。

值得注意的是，Anthropic 在某些方面是在追赶：谷歌和 OpenAI 都已经推出了能够处理接近百万 token 提示的模型。

尽管如此，百万 token 里程碑已成为 AI 模型提供商间日益明显的基准。更大的上下文窗口允许模型处理更长的文档或更广泛的数据集，而无需将任务分解为多个步骤。

在当前定价下，Claude Opus 4.6 每百万输入 token 约 5 美元，每百万输出 token 约 25 美元；Claude Sonnet 4.6 每百万输入 token 约 3 美元，每百万输出 token 约 15 美元。之前，Sonnet 的输入定价在提示超过长上下文阈值后从约每百万 token 3 美元上升到约 6 美元，而 Opus 的输入定价从约 5 美元增加到约 10 美元。输出 token 定价在溢价层级下也会上升。

Anthropic 表示，百万 token 上下文窗口在 Claude 平台原生可用，并通过 Amazon Bedrock、Google Cloud 的 Vertex AI 和 Microsoft Foundry 提供。运行 Opus 4.6 的 Claude Code Max、Team 和 Enterprise 用户默认也会获得完整的百万 token 上下文窗口。

更便宜的长提示对开发者意味着什么

对开发者来说，移除长上下文附加费可能会影响应用的设计方式。

一个流行的降低成本机制是尽量减少一次发送到模型的信息量。检索系统（Retrieval Systems）——只提取最相关的数据片段——成为一种常见的架构模式，部分原因就是发送非常大的提示可能很快变得昂贵。

随着溢价层级的消失，这个约束也不复存在。开发者仍然可以依赖检索系统来管理 token 使用，但当更广泛的上下文有用时，他们也可能选择将更大的信息体直接发送到模型。

这可能会让某些工作流更简单。开发者有时可以将更大的数据切片放入单个提示中，并要求模型跨其进行推理，而不是将文档分块（Chunking）成更小的片段或编排（Orchestration）多个模型调用。

对于 AI 原生编码工具，这种方法尤其有吸引力。能够访问大上下文窗口的模型可以一次检查更多的代码库——包括多个文件、文档和之前的对话——这可以改进调试、代码重构或生成 PR 等任务。

Techstars 联合创始人兼风险投资人 Brad Feld 表示，更大的上下文窗口可以移除开发者之前为管理有限上下文大小所需的一些工程变通方案。

“Claude Code 的 100 万 token 上下文窗口完全改变了工程计算，”Feld 在 LinkedIn 帖子中写道。“我构建了四个总计 4700 行的 Markdown 状态机来管理我的开发工作流——从工单到部署。大部分复杂性存在是因为 20 万 token 的限制。”

有了更大的窗口，他写道，许多这些机制变得不必要了。

“有了 100 万 token，可靠性基本上通过有足够的空间解决了。约束转向了挂钟速度——而速度来自并行性。”

换句话说，模型现在有足够的内存来跟踪长任务，主要瓶颈变成了它处理所有这些信息的速度。

需要强调的是，移除附加费并不会让大型提示免费。token 使用量仍随输入大小增加，开发者必须权衡这个成本与其他架构方法。

但通过消除定价阈值，Anthropic 让长上下文工作负载更容易进行实验——并可能更容易部署到生产系统中。