Claude Opus 5.5 Fast Mode 取消候补名单，但速度依然有代价

Anthropic 已取消 Claude Opus 5.5 fast mode 的候补名单，为愿意支付溢价的开发者承诺最高可达 2.5 倍的输出吞吐量。

这一变化使 Opus 5.5 fast mode 不再局限于 Claude Platform 上的研究预览。符合条件的 API 组织现在可以直接申请启用这一加速配置，无需预先申请访问权限。该功能也扩展至托管在 Azure 上的 Microsoft Foundry 部署。

这不是一个新模型，也不是 Opus 的轻量版本。Anthropic 表示，fast mode 使用与标准 Opus 5.5 相同的模型权重和行为。区别在于 Anthropic 如何提供该模型服务，以及客户为额外速度支付多少费用。

这一差异构成了核心权衡。更快的输出可以缩短智能体循环、编码会话和交互式工作流。不过，它并不能降低所有类型的延迟，运营细节也可能使实际成本高于表面溢价。

因此，开放访问与其说是一项产品公告，不如说是基础设施战略的转变。Anthropic 正将推理速度转化为其最强通用模型可选的服务等级。

Claude Opus 5.5 Fast Mode 现已成为开放的 API 选项

最重要的变化在于访问权限：受支持的客户在发出 fast-mode 请求前不再需要获得批准。

Anthropic 于 2026 年 10 月 15 日通过其开发者账号宣布这一变化。该公司表示，Opus 5.5 fast mode 已结束研究预览阶段，候补名单也已取消。

现行的 fast mode 文档反映了这一更广泛的访问范围。处于 Anthropic Start、Build 和 Scale 用量层级的组织，会获得 Opus 5.5 的默认 fast-mode 速率限制。评估组织必须升级至符合条件的用量层级后才能使用该功能。

开发者只需在 Messages API 请求中添加 speed: "fast" 即可选择启用。Opus 5.5 不再需要此前的 fast-mode beta header，不过仍在发送该 header 的现有请求依然兼容。

响应会在其用量数据中包含 speed 字段。该字段让应用能够确认 Anthropic 是以 fast 还是标准模式处理请求。在团队比较性能、归因用量或调查延迟不一致问题时，这一细节至关重要。

Fast mode 也拥有独立的速率限制，与组织的标准 Opus 配额分开计算。当请求超出可用的 fast 容量时，API 可能返回包含 retry-after 值的 429 速率限制错误。

Anthropic 还提供用于 fast-mode 输入和输出容量的额外响应 header。这些 header 会报告适用限制、剩余容量及重置时间。实际配额可能因组织而异，因此开发者必须查看自己的 Claude Console，而不能假定存在统一阈值。

取消候补名单并不意味着所有旧版 fast-mode 实现都已普遍开放。根据 Anthropic 的文档，Opus 5 和 Opus 4.8 的 fast mode 仍处于研究预览阶段。这些版本仍遵循现有的受限访问要求。

这种按模型区分的方式，使 Opus 5.5 成为希望获得加速 Opus 推理、又不想协商访问权限的团队的实际默认选择。它也为 Anthropic 提供了从早期预览配置迁移的更清晰路径。

Claude Code 则遵循独立的产品路径。Anthropic 表示，其 fast-mode 行为保持不变，且仍会消耗额外用量额度。这项 API 公告并未取消终端和编辑器用户在计费上的这一差异。

结果是，这项功能更易获得，但并不是适用于所有 Claude 产品的通用开关。团队仍需区分 Claude API、Claude Code、云托管部署以及旧版 Opus 模型。

速度承诺适用于输出，而非整个请求

Anthropic 的核心速度指标描述的是每秒生成 token 数量，而不是总任务时间缩短 2.5 倍。

Fast mode 是相同 Opus 5.5 模型的更快推理配置。Anthropic 表示，其每秒可生成的输出 token 数量最高可达标准速度的 2.5 倍。该公司并未声称每个请求都会快 2.5 倍完成。

差异始于首 token 时间，通常简称为 TTFT。它衡量模型开始返回答案前的等待时间。每秒输出 token 数量，即 OTPS，则衡量生成开始后响应抵达的速度。

Anthropic 明确表示，fast-mode 的优势主要集中在 OTPS，而非 TTFT。因此，涉及较长推理阶段、大型工具结果、网络延迟或缓慢外部服务的请求，其端到端改进幅度可能更小。

以一个编码智能体为例：它读取代码库、提出补丁、运行测试并解读失败结果。更快的文本生成可以缩短模型可见的响应和规划阶段，但无法让测试套件、源代码管理服务器或软件包注册表更快完成工作。

当模型生成较长输出时，收益会更加明显。代码编写、详细审查、迁移计划和文档起草都会花费相当多时间持续输出 token。Fast mode 可以缩短循环中的这部分时间。

短分类或路由请求则是另一种情况。若响应只有几个词，启动延迟和网络开销可能占主导。此时为更高的输出吞吐量付费，实际价值可能有限。

流式接口让这一改进更容易被感知。用户会看到代码、解释或智能体进度以更高速度出现。在非流式系统中，应用只有在完成后才接收整个响应，因此主观差异并不那么即时。

Anthropic 的 Opus 模型概览将 Opus 5.5 定位于编码、专业工作和长时间运行的智能体。这些用例通常包含重复的模型调用，使小幅延迟降低能够在整个会话中累积。

单次响应节省几秒钟，未必会改变工作流。但数十个智能体步骤可以将这些秒数转化为有意义的实际耗时缩减。价值来自缩短重复的推理环节，而不是加速无关工作。

这也解释了为何取消候补名单对智能体构建者最重要。他们现在能够在真实的编排循环中测试快速推理，而不必根据 playground 的响应推断效果。

该公司的速度承诺仍需谨慎归因。Anthropic 将改进描述为“最高可达”2.5 倍，目前尚无获得广泛认可的独立基准测试证明所有工作负载都存在固定倍数。

输出长度、负载、区域、速率限制和应用架构都会影响实际观测到的性能。评估 fast mode 的团队应衡量完成的任务，而不只是流式文本的动画速度。

一项有用的评估至少应记录四个数值：首 token 时间、输出吞吐量、总请求时长和总工作流时长。最后一项衡量决定了该功能是否真正改善用户体验到的产品。

更快的推理让延迟成为预算决策

核心竞争并不是 Opus 与另一种模型之争，而是更快迭代与为每个 token 提供服务所增加成本之间的权衡。

Fast mode 相比标准 Opus 5.5 带有溢价。共享发布规则不允许在此列出具体价格，但 Anthropic 的官方文档提供了当前商业条款。

这一溢价适用于整个上下文窗口，包括输入较大的请求。根据组织配置工作负载的方式，提示词缓存和数据驻留调整也可能额外适用。

最直接的做法，是将速度倍数与价格倍数进行比较。这个计算有用，但并不完整。模型请求只是应用成本和延迟的一个组成部分。

对于交互式编码助手，更快的响应可以让开发者保持专注并减少空闲时间。当昂贵的工程时间是限制性资源时，其经济收益可能超过额外的推理账单。

对于夜间代码库迁移，延迟的重要性可能低得多。标准速度可以提供相同的模型行为，同时让任务在无人看守的情况下完成。支付溢价能缩短运行时间，却未必改变其业务价值。

客户支持系统则介于两者之间。更快输出可以提升感知响应速度，但许多支持回复都很短。团队必须确定真正造成延迟的是输出生成，还是检索和工具执行。

同样的问题也适用于研究智能体。一个智能体可能将大部分时间花在等待网页、数据库或文档解析器上。更快的模型输出只会在受推理控制的部分发挥作用。

开发者还需考虑提示词缓存。缓存让重复请求复用先前处理过的提示词前缀，从而减少长对话和智能体会话中的工作量。

Anthropic 表示，fast 和标准请求不会共享缓存前缀。在两种配置之间切换会使这种复用失效。因此，回退机制在运营上可能正确，却可能在经济上令人意外。

假设一个较长的智能体会话以 fast 速度构建了缓存上下文。如果容量耗尽，应用以标准速度重试，标准请求无法复用 fast 缓存。它必须在另一速度设置下重新处理相关前缀。

反过来也一样。应用无法预热标准速度缓存，然后期待 fast 请求继承该缓存。团队应将速度视为缓存身份的一部分，而不只是展示偏好。

这使得简单的每 token 成本比较，对于持续运行的智能体而言不那么可靠。缓存行为、重试率、响应长度及每项完成任务所需调用次数，都会影响最终成本。

更好的部署策略，是仅将对延迟敏感的工作路由至 fast mode。交互式编辑、实时结对编程、同步研究和面向用户的智能体循环，都是比队列、批量摘要或计划维护更有力的候选场景。

Anthropic 不支持通过 Batch API 使用 fast mode。根据当前文档，它也无法与 Priority Tier 承诺同时使用。这些限制进一步表明，它面向的是选择启用的交互式吞吐量。

因此，最佳比较单位不是每次请求的成本，而是在可接受延迟下每项成功任务的成本。这一框架涵盖重试、工具调用、缓存上下文以及用户时间的价值。

已经在工程知识库中记录 AI 工作流的团队，也可以在这里采用同样的纪律。在改变默认设置前，记录工作负载、服务等级、失败路径和测量结果。

Microsoft Foundry 扩大访问范围，Google Cloud 仍值得关注

Fast mode 正在成为一项云分发功能，但可用性仍取决于托管路径。

Anthropic 的文档列出了 Claude API 上的 Opus 5.5 fast mode，包括 Claude Managed Agents。文档也列出了部署托管于 Azure 时，Microsoft Foundry 中的 Claude。

Microsoft 的托管配置对比确认，Opus 5.5 Fast 可在 Azure 托管配置中使用。Anthropic 托管的 Foundry 配置则未列出该加速版本。

这一差异很容易被忽视，因为两种配置都出现在 Microsoft Foundry 中。它们在基础设施、端点、身份验证选项、部署行为和功能可用性方面有所不同。

因此，客户应核实托管类型，而非假定每个 Foundry 部署都支持快速模式。在 Microsoft 的目录中选择 Claude，本身并不代表可以使用加速配置。

Azure 托管选项为企业团队提供了另一种采购和部署路径。对于已经通过 Microsoft 平台管理云支出、身份体系和区域架构的组织而言，这一点可能尤为重要。

不过，Microsoft 指出，Anthropic 仍然是 Foundry 中 Claude 模型的销售方和运营方。这些模型被视为非 Microsoft 产品，其使用仍受 Anthropic 适用条款约束。

根据 Anthropic 的文档，Amazon Bedrock 和 AWS 上的 Claude Platform 目前均不支持快速模式。这为希望将模型流量保留在既有云合作关系内的团队带来了不均衡的能力版图。

Google Cloud 的情况则更为复杂。标准版 Claude Opus 5.5 已在该平台提供，并已明确其上下文窗口，同时支持计算机使用、函数调用和提示词缓存等能力。

10 月的公告称，Google Cloud 对快速模式的支持即将推出。Anthropic 尚未公布上线日期，其当前功能文档仍将快速模式标记为不支持 Google Cloud。

Google 的Opus 文档描述的是标准模型，而非快速版本。在相关文档和模型目录发生变更之前，买方应将未来的推出视为既定计划，而不是既成事实。

这种错峰可用性对云团队形成了压力，而非直接针对另一家模型供应商。开发者可能因治理要求偏好某个云平台，却需要通过另一条路径获得特定推理功能。

大型组织很少仅为一个速度开关迁移生产工作负载。它们还会考量数据处理、区域覆盖、支持服务、承诺消费、采购、身份体系和既有可观测性。

不过，功能缺口仍会影响新部署。如今正在设计交互式编程代理的团队，可能会选择原生 Claude API 或 Azure 托管的 Foundry，因为快速模式可立即在那里进行测试。

云支持也改变了 Anthropic 争取企业采用的方式。仅通过直接 API 提供的能力能够触达开发者；出现在大型云目录中的能力，则可以进入既有采购和治理流程。

因此，Google Cloud 支持并不只是可用性页面上多了一个标志。它将检验 Anthropic 能否在基础设施合作伙伴之间提供一致的服务特性，而不会造成令人困惑的产品差异。

“2.5 倍”说法未能证明什么

开放访问消除了管理层面的障碍，但它无法回答有关持续性能和生产可靠性的最棘手问题。

第一个不确定性是独立验证。Anthropic 表示输出吞吐量最高可提升至 2.5 倍，但团队不应将这一上限视为有保障的生产结果。

一套有价值的测试方案必须包含真实的提示词、工具、上下文规模、输出长度和并发量。简短的合成提示词可能会夸大收益，因为它们排除了真实代理所执行的周边工作。

第二个不确定性涉及容量。快速模式设有专属速率限制，但 Anthropic 并未公布适用于每一家符合条件组织的统一额度。

这意味着移除候补名单并不等同于无限可用。团队可以获得该功能访问权限，却仍可能在突发流量或持续并发使用期间遭遇速率限制。

应用需要对 429 速率限制响应和 529 容量错误进行明确处理。Anthropic 的软件开发工具包会自动重试某些失败请求，但重试会增加延迟，也可能掩盖真实的用户体验。

回退至标准速度可以维持可用性，但也可能需要重建提示词上下文，因为缓存无法在不同速度设置之间迁移。应用必须决定连续性、延迟还是缓存效率何者最重要。

第三个不确定性是实际工作流中的质量。Anthropic 表示快速模式使用相同的权重和行为，因此客户不应预期存在刻意的智能水平取舍。

即便如此，相同的权重也无法保证每次运行都产生相同的应用结果。生成式系统仍具有变动性，而基于工具的工作流可能会因中间响应中的微小差异而发生分歧。

团队应将任务成功率与速度一并比较。如果代理需要更多修正、生成更长回复，或触发额外工具调用，那么更快的输出流价值有限。

第四个不确定性是总体基础设施延迟。更快的推理无法消除向量数据库、权限检查、浏览器自动化、编译或外部 API 带来的延迟。

尚未对工作流进行性能分析的产品团队，可能会优化错误的组件。它们可能为更快的生成付费，而用户仍在等待检索或工具执行。

第五个不确定性是采用情况。移除候补名单带来的是可用性，而非需求。Anthropic 尚未披露有多少组织使用快速模式、多少 Opus 流量选择该模式，或哪些工作负载会在测试后继续保留它。

缺失的采用数据之所以重要，是因为高端推理必须创造足够价值，才能成为稳定的生产配置。否则，它仍会只是团队为演示或特别紧急的任务启用的一个开关。

Claude Code 也提供了另一项警示。其快速模式仍然独立存在，并使用额外的使用额度，因此无法根据桌面端采用情况直接推断 API 的可用性。

因此，最有力的解读应当是有限但有意义的。Anthropic 对其平台上的 Opus 5.5 有足够信心，因而移除了研究预览阶段的门槛。但它尚未证明快速模式是每一种 Opus 工作负载的正确默认选择。

开发者应围绕一个可证伪的问题展开评估：更快的输出是否足以缩短完成任务的延迟，并证明额外成本和运营复杂性是合理的？

这个问题比询问该模式“感觉是否很快”更有价值。它迫使团队在同一次衡量中纳入速率限制、缓存未命中、重试和工具延迟。

三个信号将显示快速模式是否会成为生产标准

下一阶段取决于云端扩展、可量化的工作负载收益，以及专属容量能否在真实需求下保持可靠的证据。

第一个信号是 Google Cloud 的可用性。Anthropic 的开发者公告称支持即将推出，而当前文档仍将该平台排除在外。

一项有文档支持的 Google Cloud 发布，将强化这样一种判断：快速推理正在成为标准部署选项，而不是直接 API 的专属功能。持续延期则会保留当前的云端碎片化局面。

细节与发布本身同样重要。买方应关注 Google 是否提供单独的模型标识符、哪些区域支持该功能，以及配额如何与现有 Claude 容量相互作用。

他们还应检视功能行为是否与原生 API 一致。在团队能够公平比较不同部署之前，提示词缓存、速率限制报告、工具使用和回退处理都需要具备一致的文档说明。

第二个信号是独立性能数据。开发者需要获得涵盖编程代理、长篇生成、研究系统和面向客户助手的测量结果。

有价值的报告应将首个 token 的时间、输出吞吐量和整个工作流时长区分开来。它们还应说明上下文长度、输出长度、并发量、区域和重试行为。

若在重复的代理循环中出现显著的端到端收益，将支持 Anthropic 的定位；若在长时间流式任务之外只有小幅改进，则会将快速模式限定为更专业化的角色。

第三个信号是运营稳定性。团队应关注快速请求遇到专属速率限制的频率、容量恢复速度，以及应用回退至标准速度的频率。

一项服务单独测试时可能很快，却会在流量高峰期间不可靠。对于具有响应时间承诺的生产系统而言，可预测的吞吐量比峰值数字更重要。

Anthropic 可以通过提供更清晰的容量指引和更好的组织级遥测数据来增强信心。客户需要知道，较慢的结果究竟源于其应用、其配额，还是全服务范围的需求。

这些信号也将表明推理速度是否正在成为独立的产品类别。模型供应商历来通过能力、上下文长度、基准测试结果和 token 经济性展开竞争。

可选择的速度引入了不同的市场结构。同一模型可以服务于多个延迟等级，让客户根据自己对答案时效性的迫切程度付费。

这种结构类似于其他云服务，其中容量、优先级和响应时间成为独立的采购决策。它为供应商提供了另一种细分需求的方式，无需为每个等级训练新模型。

对开发者而言，立即可采取的行动很直接。选择一个具有代表性的工作流，以标准速度和快速速度分别运行，并衡量整个任务，而非仅衡量 token 流。

纳入缓存复用、工具延迟、重试、输出长度和人工等待时间。应在真实并发条件下重复测试，而不是依赖一次成功请求。

随后决定 Claude Opus 5.5 快速模式应处于何种位置：默认路径、用户可控选项，还是面向延迟敏感请求的定向路径。候补名单已取消，但部署决策仍需要证据。