Opus 5.5 Fast Mode 正式转正：双倍价格与缓存陷阱

Anthropic 在 10 月 15 日把 Claude Opus 5.5 的 Fast Mode 从研究预览中放了出来。开发者不再需要联系客户经理或排队等待审批,每个用量等级都有默认的 fast 模式速率限制。代价是价格翻倍,而且有一个容易踩的缓存坑。

Fast Mode 到底改了什么

Fast Mode 曾经是一扇需要钥匙的门。据 Claude Code 的官方文档描述,Console 组织必须通过客户经理或 waitlist 申请开通,fast 请求才会成功。 10 月 15 日的 release notes 把这扇门拆掉了——但仅限 Opus 5.5 这一个模型。

具体变化有三点:Opus 5.5 的请求不再需要 fast-mode-2026-02-01 beta header(仍然带上它的请求也照常工作);每个 usage tier 都有默认的 fast mode 速率限制,无需申请;Fast Mode 现在支持部署在 Azure 上的 Claude in Microsoft Foundry。

没有变的是:Opus 5 和 Opus 4.8 的 Fast Mode "仍处于研究预览阶段",那些请求依旧需要 beta header。切换开关就是一个字段——在请求里加 "speed": "fast" 即可,响应的 usage 对象会返回 speed 字段(值为 "fast" 或 "standard"),可以用来确认实际按哪个速度计费。

快在哪里,不快在哪里

官方文档说得很明确:速度收益集中在输出 token 每秒(OTPS),而不是首 token 延迟(TTFT)。同一个模型权重、同样的行为,只是更快的推理配置,而且增益在流式输出时"最明显"。

这直接决定了它值不值。写长 diff、做数据库迁移或者跨文件重构的请求,大部分时间花在吐 token 上,提高输出速度能明显缩短等待。而一个只返回十个 token 的短分类调用,时间几乎都花在第一个 token 出现之前——Fast Mode 根本不针对那一段。

价格方面,Opus 5.5 标准版输入 $4、输出 $20 每百万 token;Fast 版是 $8 和 $40。缓存命中的折扣是基础输入价的 0.05 倍,文档说明提示缓存乘数叠加在 fast 定价之上,所以 fast 的缓存命中价是 $0.40 每百万 token。Fast 定价在整个上下文窗口内是平的,超过 200k 输入 token 的请求也一样,数据驻留乘数同样会叠加。

Opus 5.5(每百万 token)	标准	Fast
输入	$4	$8
输出	$20	$40
缓存命中(0.05x 输入)	$0.20	$0.40

OTPS 与 TTFT 的差别为什么决定体验。 TTFT（Time To First Token，首 token 延迟）衡量的是从发出请求到收到第一个输出 token 的时间，它主要由排队、预填充（prefill）和网络往返决定。对长上下文请求来说，预填充要处理的输入 token 越多，TTFT 就越长。OTPS（Output Tokens Per Second，输出 token 每秒）衡量的则是首 token 之后模型的持续吐字速度，也就是解码（decode）阶段的吞吐。两者优化的资源不同：TTFT 卡在预填充和排队，OTPS 卡在解码带宽和批处理策略。Fast Mode 只动 OTPS，说明它优化的是解码路径，而非等待路径。这解释了一个反直觉的现象——同样的模型权重、几乎相同的行为，却能在长输出任务上快出一大截。对于需要流式吐出大量 token 的 Agent 类工作负载，OTPS 才是真正的瓶颈所在。

切换速度会重建缓存

这一条可能比双倍价格更贵。API 文档在"注意事项"里写着:在 fast 和 standard 速度之间切换会使提示缓存失效,不同速度的请求不共享缓存前缀。

也就是说,一段在标准速度下已经缓存的长对话,它的第一个 fast 请求拿不到任何缓存命中,整段历史都要按 fast 费率重新读取一遍,如果你再缓存一次还要付 fast 的缓存写入溢价。

Claude Code 的处理略有不同。它的提示缓存文档解释:打开 fast 模式会添加一个请求 header,而这个 header 是缓存 key 的一部分,因此第一个 fast 请求"读取整个对话历史且无缓存命中"。之后 Claude Code 会保留该 header、只改变速度设置,所以把 fast 模式关掉再打开不会丢失缓存——这个成本每次对话只付一次。

拿一段 15 万 token 的 Claude Code 对话算笔账:在进行到一半时打开 fast 模式,这 15 万 token 按 $8 的 fast 输入价计费是 $1.20;如果重建的前缀进入 5 分钟缓存,1.25 倍的缓存写入乘数让价格变成 $10 每百万,即 $1.50。而同样这一轮在标准速度下、缓存是热的,读取价是 $0.20 每百万,只要 $0.03。差距在两个数量级。这就是 Claude Code 文档建议"在会话开始时启用 fast 模式,而不是对话中途切换"的原因。

提示缓存为什么对速度敏感。 提示缓存的原理是把一段稳定的前缀（通常是 system prompt、工具定义和历史对话）预先计算好 KV 缓存并存储，后续请求命中时直接复用，省去重复的预填充。它的命中判定基于「前缀 + 缓存 key」的精确匹配，而缓存 key 包含部分请求元数据。如果不同请求的缓存 key 不一致，即使文本前缀完全相同，也会被判为未命中，触发整段前缀的重新计算和缓存写入。Fast Mode 的速度设置正好进入了这个 key，因此 fast 与 standard 天然属于两个互不相通的缓存空间。缓存写入通常按基础输入价的 1.25 倍计费，这就是为什么「切换一次」不只是重新读一遍历史，还会额外付一笔写入溢价——15 万 token 的对话，这个代价就足以拉开两个数量级的差距。

API 上的 429 不会自动降级

Fast Mode 有"独立于标准 Opus 速率限制的专用限流池"。超限会返回带 retry-after header 的 429,而 API 不会自行降级到标准速度。SDK 默认对这类请求重试最多 2 次,文档称延迟"通常很短"。

Claude Code 的行为不同:碰到 fast 模式限流时,它会降级到标准速度和标准定价,冷却结束后再自动切回 fast。

有六个响应 header 用于追踪这个池子,从 anthropic-fast-input-tokens-limit 到 anthropic-fast-output-tokens-reset。如果你自己调 API 并且宁愿跑慢点也不愿等,官方文档给出了一个客户端降级的写法:捕获 RateLimitError 后改发标准速度请求。需要注意,设置 maxRetries: 0 会跳过自动重试,但同时也跳过了过载和服务器错误的重试——完整示例会把这些错误重新抛出并重试。降级请求同样会开启一个新的缓存,文档对此也有说明。

为什么 API 选择不自动降级。 429 Too Many Requests 表示已触发速率限制，retry-after header 则告诉客户端应该等多久再试。Fast Mode 拥有独立于标准的限流池，意味着 fast 配额耗尽时，standard 配额可能仍然充裕，理论上存在降级空间。但 API 层面不会替客户端做这个决定，原因在于速度是一种计费属性——如果服务端悄悄把 fast 请求按 standard 处理，调用方会在不知情的情况下拿到更慢的响应，却仍以为自己买的是 fast。因此降级必须由客户端显式发起，并在降级请求上承担新开缓存的后果。这与 SDK 的默认重试策略是两回事：SDK 的重试是「同速重试」，重试次数用尽后才轮到调用方决定是否降级。设置 maxRetries: 0 会一并关掉过载和 5xx 的重试，所以官方示例选择重新抛出错误再统一处理。

哪些地方还用不了

官方 fast mode 页面列出了目前的能力缺口:

• 不支持 Amazon Bedrock、AWS 上的 Claude Platform,以及 Google Cloud;
• 在 Microsoft Foundry 上仅限 Azure 托管的部署,"不支持 Anthropic 托管的部署";
• 不支持 Batch API;
• 不支持 Priority Tier 承诺用量。

在 Pro、Max、Team 或 Enterprise 计划的 Claude Code 中,/fast 只能通过 usage credits 计费,不包含在订阅的速率限制内;Team 和 Enterprise 还需要 Owner 先启用。

值得留意的是文档之间的不同步:10 月 15 日当天,Claude Code 的 fast mode 页面仍称该功能为研究预览,并把 Microsoft Foundry 列为不支持——Claude Code 的文档还没跟上 API 的 release notes。如果你的团队在 API key 上跑 Claude Code,与其信任任何一页文档,不如直接试一下 /fast。

无论用哪个入口,记住两条:在会话开始时打开 fast 模式,而不是中途;用 usage.speed 确认实际计费的速度。

Fast Mode 本质上是一场用钱换延迟的交易,它有自己独立的限流池,也有自己独立的缓存。