Claude Opus 5.5 发布：性能比肩 Fable 5.1，成本降低 40%

我们推出 Claude Opus 5.5，这是我们全新 Claude 5.5 系列中的首个模型。它在大多数工作上的表现达到 Claude Fable 5.1 的水平，而运行成本比 Opus 5 低 40%。

Claude Opus 5.5 是我们自呼吁为前沿技术设定节奏以来发布的第一个版本。它在发布前经过了外部评估者的测试，包括 Frontier Design 和 METR。在我们运行的自动化行为审计——我们最全面的对齐测试——中，Opus 5.5 是我们迄今测试过的表现最强的模型。它还配备了我们为能力最强的模型所开发的各项防护措施。

以下是你可以从 Opus 5.5 中期待的一些改进：

性能。 Opus 5.5 相较 Opus 5 是一次重大升级。它是新的领先模型，早期测试者在其最复杂的工作上看到了性能的大幅跃升。一位测试者在不到一天内完成了一项 68 万行的代码迁移——这项工作原本需要一个工程团队花费数周。它擅长发现并修复软件中的低效问题：当我们要求它缩短一个 Web 应用每个页面的加载时间时，Opus 5.5 在 40 次中成功了 39 次，而 Opus 5 只做出了较小的改进，并且还改变了应用的行为。另一位测试者让多个 Claude 模型根据单条提示构建一个游戏；Opus 5.5 凭借其图形质量和精细度获得了高于其他任何模型的评分。

安全性。 Opus 5.5 在我们自动化行为审计——我们在数千个模拟场景中测试 Claude 的对齐测试套件——中取得了迄今所有模型中的最佳成绩。与近期模型相比，它采取难以逆转的行动或越出既定边界的可能性要低得多，并且比 Opus 5 更能抵御提示注入。我们还扩大了我们的对齐测试范围，以覆盖更长的任务、不可能完成的任务，以及以真实事件为蓝本的场景，尽管它仍有局限。我们评估的完整细节可在 Opus 5.5 系统卡中查阅。

由于 Opus 5.5 在生物学和网络安全方面与 Claude Mythos 5.1 相当，我们部署它时采用了与 Claude Fable 5.1 类似的防护措施。经过审核的组织今天即可申请我们的生命科学验证计划，以将 Opus 5.5 用于生物学研究。在未来几周内，我们还将扩大网络验证计划的访问范围，经过验证的网络安全从业者将能够使用 Opus 5.5 开展工作。

成本与速度。 Opus 5.5 提供服务所需的算力比 Opus 5 更少，其定价也反映了这一点。我们的测试显示，在默认设置下，它在典型工作负载上的成本将比 Opus 5 低 40%。输入和输出 token 分别为每百万 $4 和 $20，比 Opus 5 低 20%。缓存读取（占智能体与编程工作成本的大部分）为每百万 token $0.20，比 Opus 5 低 60%。Opus 5.5 生成输出的速度也比 Opus 5 快 30% 以上。

除了降价之外，我们还在提高 Pro、Max、Team 以及按席位计费的 Enterprise 套餐的五小时使用限额。我们还为订阅用户提供一次速率限制重置，你现在可以将其保存下来，并在你选择的任何时候使用。

沟通能力。 Opus 5.5 比之前的模型沟通更自然。早期测试者发现它的写作更清晰、更易理解，这解决了我们听到的关于 Opus 5 的一些常见反馈。它把最重要的信息放在前面，其风格使其在长时间会话中成为更好的工作伙伴。正如一位早期测试者所说：“它写作的方式就像我一样。”在我们自己的使用中，这使得 Opus 5.5 的工作更易于跟进和检查——这既是安全方面的好处，也是实用方面的好处。

Claude Sonnet 5.5 和 Claude Haiku 5.5 将在未来几周内跟进，带来许多相同的性能、效率和安全方面的改进。

性能与成本效益

在我们的基准测试中，Claude Opus 5.5 在智能体编程、计算机使用和知识工作方面领先。话虽如此，在这些能力水平上，我们发现基准测试的差距已不再是衡量现实世界差异的可靠指南。在我们自己的使用中，Opus 5.5 与 Claude Fable 5.1 之间的差距比这些分数所显示的要小。

除非另有说明，所有 Claude Opus 5.5 结果均使用最大努力下的自适应思考。Terminal-Bench 4.0 结果报告的是 Claude Opus 5.5 在 xhigh 努力下和 GPT-6 Astra 在 high 努力下的成绩，由 OpenAI 报告；这些代表每个模型的最高分。Claude Opus 5.5 在启用生产安全保障的情况下进行了评估。当保障措施介入时，网络安全任务由 Claude Opus 4.8 完成，生物学和前沿 LLM 开发任务由 Claude Opus 5 完成。这可能会降低 Claude Opus 5.5 在这些基准测试上的表现。

1** Terminal-Bench 4.0：** Claude Opus 5.5 的标准误差为 ±2.6 分，其他 Claude 模型为 ±1.6–2 分。公开排行榜（每任务 5 次试验，Claude Code 测试框架）报告 Claude Opus 5 为 51.8%；我们的设置复现为 52.3%，在噪声范围内。GPT-6 Astra 和 GPT-5.6 Sol 的数据由 OpenAI 报告。

2** AutomationBench：** AutomationBench 结果由 Zapier 运行并报告。这些运行未使用回退模型，因此保障措施的介入被视为失败——这导致分数低于 Claude Opus 5.5 在实际中会达到的水平。Claude Opus 5.5 的结果来自 Zapier 在早期访问期间自己的评估。Opus 5、GPT-5.6 Sol 和 GPT-6 Astra 的结果来自 Zapier 的公开排行榜。

3** Terminal-Bench-Science 0.1：** 每个模型的标准误差为 ±3.5–5 分。公开排行榜（每任务 3 次试验，Claude Code 测试框架）报告 Claude Opus 5 为 30.0%；我们的设置复现为 29.0%，在噪声范围内。GPT-6 Astra 的数据由 OpenAI 报告。

Opus 5.5 的优势非常明显的地方在于效率。它的每 token 成本低于 Opus 5，并且每个任务使用的 token 更少，最终使成本下降了 40%。

定价

Opus 5.5 的快速模式也可在 Claude Code 和 Claude Platform 中使用，速度最高可达 2.5 倍。其价格为每百万输入 token 8 美元，每百万输出 token 40 美元。

编码

Opus 5.5 特别擅长长时间、范围庞大的工作，例如代码库范围的迁移和审计。一位早期测试者用它审计并修复了一个 20 万行的代码库，用时不到三小时，而 Opus 5 花了超过 20 小时，并使用了 2.5 倍的 token。在一项内部测试中，我们要求 Opus 5.5 和 Fable 5.1 将 HAProxy（广泛用于在服务器之间平衡 Web 流量负载的软件）从 C 翻译为 Rust。两个重写版本几乎都通过了 HAProxy 自身的所有回归测试，但 Opus 5.5 在 9.5 小时内完成，而 Fable 5.1 用了 12 小时，并且成本低 51%。

Opus 5.5 以极低的成本在智能体编码方面提供了前沿结果。在 FrontierCode 上以其默认努力水平运行时，它以大约每个任务 20% 的成本击败了 GPT-6 Astra。在 Terminal Bench 4.0 上，它以约 40% 的成本与 Astra 持平，而在 CursorBench 上，它以约三分之一的成本比 GPT-5.6 Sol 高出 11 分。

Terminal-Bench 4.0 衡量模型在命令行界面内完成复杂、多步骤专业任务的能力。Opus 5.5 在默认努力水平下，以约五分之一的成本击败了最大努力水平下的 Opus 5。它以约 40% 的成本与 GPT-6 Astra 持平。

FrontierCode 衡量智能体的代码更改是否会被合并。在默认努力水平（中等）下，Opus 5.5 得分为 54.6%，高于所有其他模型，以约每个任务五分之一的成本击败了 GPT-6 Astra 的最高分（53.3%）。

CursorBench 在取自真实 Cursor 会话的模糊、多文件任务上评估编码智能体。在默认努力水平（中等）下，Opus 5.5 得分为 52.5%，而 Fable 5.1（最大）为 51.8%，Opus 5（最大）为 46.6%。它以约每个任务三分之一的成本，比 GPT-5.6 Sol 的最高分（41.7%）高出 11 分。

我们的早期测试者报告了类似的效率和智能提升：

最安全的编码智能体

在其系统内使用智能体的企业需要知道这些智能体正在按预期运行，尤其是当它们自主运行许多小时时。Opus 5.5 有一个分类器，会在每个操作运行前进行筛查；有一个开源沙箱，安全团队可以审计；还有代码审查，可以在漏洞合并前将其捕获。

该模型本身也具有更强的防御能力。在提示注入攻击方面，它在我们测试的每种设置中都达到或超过 Opus 5，包括编码、工具使用、计算机使用和网页浏览。在 AI 安全公司 Gray Swan 运行的一项基准测试中，Opus 5.5 与 Fable 5.1 并列，在所有测试模型中提示注入成功率最低。

知识工作

Opus 5.5 是一位可靠且娴熟的研究者。在一项内部测试中，我们要求 Opus 5.5、Fable 5.1 和 Opus 5 仅使用它们在一个难以找到财报的网页副本上所能找到的信息，撰写一份关于某公司季度业绩的报告。一个自动评分器将每一个数字和引文与来源进行了核对。在不同的努力程度设置下，Opus 5.5 的报告中，18 份里有 16 份达到了我们的质量标准，而任何编造的数字或引文都会导致不合格。Fable 5.1 和 Opus 5 在任何尝试中都未能达到该标准。

它在财务分析和商业工作方面也很强。投资公司 Walleye Capital 是早期测试者，他们报告称，Opus 5.5 在其最低设置下基本解决了他们的评估套件；在更高设置下，它表现更好，甚至注意到他们评估说明中的一个错误并加以纠正。此前没有任何其他模型发现过这个错误。

在另一项测试中，我们让 Opus 5.5 和 Opus 5 分析两家虚构人力资源软件公司之间的拟议合并。每个模型都在 Excel 中构建了一个财务模型，然后将其转化为一份关于该交易按其价格是否合理的高管演示文稿。两个模型对这笔交易得出了相同结论，但 Opus 5.5 的模型更全面，其演示文稿更易读，而 Opus 5 的模型则有轻微错误。Opus 5.5 在 63 分钟内完成，而 Opus 5 用了 93 分钟，且 Opus 5.5 的制作成本低 50%。

在知识工作评估中，Opus 5.5 表现优于其他模型，同时使用的 token 更少。在 GDPval-AA v2.1 这一覆盖 44 种职业的真实世界工作测试中，Opus 5.5 得分为 1846 Elo，领先于 Fable 5.1 和 Opus 5。在默认努力程度（中等）下，Opus 5.5 击败了处于最大努力程度的 GPT-6 Astra，而每项任务成本约为其五分之一。它在衡量业务工作流程和大规模数据收集的基准测试中同样优于其他模型。

Artificial Analysis 的 GDPval-AA v2.1 在 44 种职业中评估智能体在真实世界专业工作上的表现。在最大努力程度下，Opus 5.5 得分为 1846 Elo，而 Fable 5.1 得分为 1735，Opus 5 得分为 1708。在默认努力程度（中等）下，Opus 5.5 击败了处于最大努力程度的 GPT-6 Astra，而每项任务成本约为其五分之一。

由 Zapier 构建的 AutomationBench 测试智能体能否在许多相互连接的应用中执行真实业务工作流程。Opus 5.5 在每个努力程度级别上都得分高于 Opus 5 和 GPT-5.6 Sol。

Perplexity 的 WANDR 基准测试衡量智能体在大规模数据收集任务上的表现。Opus 5.5 以更低的每项任务成本优于 Fable 5.1 和 Opus 5。4

4WANDR： Claude 模型使用离线版本的网页搜索和网页抓取工具、程序化工具调用、代码执行以及 980k token 的任务预算运行。这与 Perplexity 公布的设置不同，两者的分数不能直接比较，我们只展示在相同条件下评分的模型。

我们的客户也报告了类似结果。以下是他们告诉我们的关于使用该模型的体验：

沟通

我们对 Opus 5.5 的写作和沟通方式进行了重大改进，这是关于 Opus 5 最常见的反馈领域之一。它的消息一眼看去就容易理解得多，测试者表示这在长时间工作会话中很有帮助。它把最重要的信息放在前面，不太可能使用行话或特殊措辞，并遵循你给它的写作规则。我们发现，这使 Opus 5.5 成为明显更好的协作者。以下是两个模型的并排比较：

请向我解释这个问题。

我的发现

多出来的扣减并不是免费额度——而是 0552feb 引入的回归

（“将计费周期边界提取到 periods.py”，标记为“无行为变更”）。

这个 bug

aggregate.monthly_usage

过去使用的是半开区间：

start, end = month_start(year, month), next_month_start(year, month)
if start <= e.ts < end:

现在它执行的是：

if period.contains(e.ts)

而在 periods.py 中

：

@property
def last_day(self) -> datetime:
return next_month_start(...) - timedelta(days=1) # 2026-08-31 00:00:00 UTC
def contains(self, ts):
return self.first_day <= ts <= self.last_day

last_day

是午夜的一个 datetime，而不是一整天。从 9 月 1 日 00:00 减去一天得到 8 月 31 日 00:00，而比较是包含边界的，因此该周期实际上在 31 日的第一个瞬间就结束了。所有时间戳在当月最后一天午夜之后的事件都会被静默丢弃——每个账户每月大约损失一天的使用量。

新的 test_periods.py

没有发现这个问题，因为它只检查了 last_day.date()

（正确地是 2026-08-31

），并在 8 月 1 日 00:00、8 月 15 日 12:00、7 月 31 日 23:59 和 9 月 1 日 00:00 测试了 contains

——它从未探测 31 日内部的任何时间点。

请向我解释这个问题。

额外的下降是计费重构中的一个 bug

免费层级的变更仅占 acme 8 月下降的 $1.50。另外的 $9.92 来自提交 0552feb

中的一个 bug。该提交被标记为“无行为变更”，但它停止统计当月最后一天的使用量。

变更内容

在合并之前，aggregate.py

使用半开区间：

start <= e.ts < next_month_start(year, month) # [Aug 1 00:00, Sep 1 00:00)

重构将其移入 Period.contains

，并使区间在错误的边界上闭合：

last_day = next_month_start(...) - timedelta(days=1) # = 2026-08-31T00:00:00Z
return self.first_day <= ts <= self.last_day

last_day

是一个午夜时间戳，而不是一整天。因此，2026-08-31T00:00:00Z 之后的每个事件

都被排除在外。九月周期从 9 月 1 日开始，所以它也不会把这些事件纳入。用量不会被移到另一个月；它根本就不会被计费。

用三个要点为我的经理总结这个 Slack 讨论串：[09:41] Dana Osei：我会告诉他们。我也会确认没有其他人读取周五的文件。[09:43] Marcus Webb：我可以调整时间表，这只是改一行 cron。但在 Dana 确认之前不行。[10:02] Dana Osei：财务说周五的文件只在周一使用。周日晚上没问题。

周五订单导出 — #data-platform，周二

问题：周五订单导出再次超时（本月第二次失败），此前仓库查询已运行 2 小时；自夏季促销以来订单量增长了约 40%。财务在周一上午 9 点审查时没有周末数据，而且两次失败都只在周一才暴露出来。当天已修复：周六运维仪表盘磁贴被重新指向读取实时表，而不是导出文件（Sam），财务确认周五文件只在周一使用（Dana），失败警报现在会呼叫值班频道（Priya），并且从下周起导出改为周日晚上 10 点，周五运行被取消（Marcus）。一次性约 300 美元的仓库升级作为权宜之计覆盖本周五。仍在进行中：Ji-woo 负责重写查询，使其增量运行（重新扫描最近 3 天以捕获迟到订单），预计将运行时间从数小时缩短到数分钟——设计文档周四完成，包括测试在内大约需要两周。在此期间，时间表变更争取了时间。

用三个要点为我的经理总结这个 Slack 讨论串：[09:41] Dana Osei：我会告诉他们。我也会确认没有其他人读取周五的文件。[09:43] Marcus Webb：我可以调整时间表，这只是改一行 cron。但在 Dana 确认之前不行。[10:02] Dana Osei：财务说周五的文件只在周一使用。周日晚上没问题。

问题：周五订单导出本月已失败两次。由于自夏季促销以来订单量增长了约 40%，仓库查询在 2 小时后超时。因此，财务在周一上午 9 点审查时缺少周末数据。即时修复：从下周起，导出将改为周日晚上 10 点，周五运行将被取消（Marcus）。财务已确认这对他们可行（Dana）。依赖周五文件的运维仪表盘磁贴现在从实时表读取（Sam，已完成）。失败警报现在会呼叫值班频道（Priya，已完成并测试）。仅本周五，Marcus 将增加仓库时段，作为约 300 美元的一次性权宜之计，Dana 已批准。长期修复：Ji-woo 将重写查询，只处理新订单，并重新扫描最近 3 天以捕获迟到订单。这应该会将运行时间从数小时缩短到数分钟。这项工作包括测试在内大约需要 2 周，设计文档需在周四前提交审查。

编写 Python 代码，读取国际象棋局面（FEN）并列出哪些棋子受到攻击。使用 TensorFlow 以提高速度。以下是我的设计：构建一个 8x8 张量棋盘，根据每种棋子的移动模式生成攻击图，并标记被攻击方格上的对方棋子。你认为有错的地方都可以修改，并在最终总结中解释你做出的每项修改及其原因。

tf.math.cumsum

取代了位扫描。几何结构被展开为 ray_targets[square, direction, step]

—— 一种有序的向外遍历。对步进轴做一次排他性累积求和，统计每一步之前严格存在的阻挡者，因此一条射线上的第一个阻挡者就是那个前面没有任何阻挡物的单一步进。这就是位棋盘引擎所用位扫描的向量化形式。我确实查看了 bitwise_ops

以了解真正的 64 位位棋盘——population_count 是存在的，但 hyperbola-quintessence 需要一个 TF 未暴露的字节反转原语，所以无论如何它都会退回到按方向循环。

编写 Python 代码，读取一个国际象棋局面（FEN）并列出哪些棋子正受到攻击。使用 TensorFlow 来提速。以下是我的设计：构建一个 8x8 的张量棋盘，根据每种棋子的移动模式为其生成攻击图，并标记被攻击方格上的对方棋子。你认为有错的地方都可以改，并在最终总结中解释你做的每一处改动及其原因。

被阻挡的线路（象、车、后）。固定掩码无法表达“在挡路的第一个棋子处停下”。我添加了第二组掩码，标记同一条线上每两个方格之间严格夹着的方格。用棋盘占用情况做一次矩阵乘法，就能一次性统计每条线上的阻挡者数量，只有当该数量为零时攻击才成立。马和单步移动之间没有任何夹着的方格，所以一条规则就覆盖了所有棋子。

我们客户的反馈支持这些发现：

安全

把控前沿的节奏

上周，我们的 CEO Dario Amodei 主张，AI 的进展应当把控节奏，以便安全实践始终领先于模型能力。把控节奏是一种方法，用以保持 AI 安全、与中国保持竞争力，并实现 AI 的益处，尤其是在生物学和医学等领域。

我们大体上了解当今模型所带来的风险，并且有充分能力加以管理。然而，随着能力提升，更严重的风险可能迅速出现，我们现在就需要为此做好准备。因此，我们的安全工作同时着眼于两个时间维度：

针对当前模型的安全实践。 当前这一代模型依赖一套既定的实践：广泛的对齐测试、由 METR 和 Frontier Design 等外部组织进行的发布前评估，以及针对每个模型在网络安全和生物学等高风险领域的能力所匹配的防护措施。我们在每次发布时都会完善这些实践。我们相信，它们适合当今模型所带来的最严重风险，并且能让我们对各类严重风险有一个广泛——尽管并不完美——的认识。

此外，我们会跟踪自己训练和评估对齐模型的能力，并在我们根据负责任扩展政策发布的风险报告中，报告我们的公开模型和内部模型。该政策是我们管理先进 AI 系统灾难性风险的自愿框架。

为未来模型做准备。 我们正在为更先进的模型预先准备训练和评估流程。我们正在收紧对强化学习所用环境的筛选，因为有缺陷的环境是导致失准行为的主要来源。此外，我们正在改进对齐奖励，并开发自动化流程，以生成用于安全训练的新的、多样化的场景。我们还在加强我们的安全与监控，包括一项专注于改进基于可解释性的监控与评估的工作。我们希望这类技术有助于减少我们对审计模型思维链（即模型在工作时写出的推理过程）的依赖。

能力更强的模型——例如那些能够完全自动化 AI 研究本身工作的模型——需要更高的安全标准。我们呼吁放缓的很大一部分原因，是我们预期这类模型可能很快就会得到训练。对于这些模型，我们并不假设上述措施本身就能达到那一安全标准。随着 AI 能力增强，公共政策应在确保人们所依赖的系统安全方面发挥更大作用。这种能力需要时间建设，而我们已开始搭建支持它的基础设施，正如“我们必须为前沿设定节奏”以及我们近期与埃森哲的公告中所述；我们预计很快会分享有关这些工作的更多细节。我们还将继续与政府和业界一起为政策讨论作出贡献，包括在监管方式和国际协调方面。

对齐

在我们的主要评估套件——一项在近 2,000 个场景中评估 Claude 的自动化行为审计——中，Opus 5.5 在几乎所有失准行为指标上的得分都优于近期任何 Claude 模型。在大多数诚实度指标上，它也是我们最强的模型。

特别是，Opus 5.5 在若干曾导致近期网络安全事件的行为上较此前模型有所改进，包括有偏见或有动机的推理、试图逃离沙箱，以及在断定自己处于模拟环境后采取有害行动。在一项旨在测试模型跨越遏制边界倾向的新评估中，Opus 5.5 试图绕过边界的频率比 Opus 5 或 Claude Mythos 5.1 低约 85%，而且它所做的每一次尝试都是低严重度且主动上报的。对于在代码库和系统中无人值守运行 Claude 的团队来说，这一点与原始能力同样重要。

然而，正如我们在最近的对齐评估中所描述的，构建能够在部署前可靠地捕捉每一次失败的评估，仍然是一个尚未解决的问题。我们发现有迹象表明，Opus 5.5 经常怀疑自己正在被评估，这挑战了我们评估它在各种真实世界部署环境中将如何行动的能力。随着这些环境的扩展和模型能力的提升，我们预计这一挑战将会加剧，除非我们在可解释性方面取得进展。尽管我们确信 Opus 5.5 在我们能够衡量的领域展现出广泛的改进，我们仍将自身的对齐工作与下文所述的保障措施相结合。

保障措施

随着我们的模型变得更加强大，更严格的保障措施是我们防止新能力沦为滥用工具的一种方式。Opus 5.5 是首个在网络安全、生物学和蒸馏方面采用与 Fable 5.1 类似类别保障措施而发布的 Opus 模型，所有这些都会透明地回退到另一个模型。

网络安全。 由于 Opus 5.5 具备极其强大的网络能力，我们正在对 Opus 5.5 施加与 Fable 5.1 类似的网络安全保障措施。用户将能够在常规软件开发生命周期中识别并修复其代码中的漏洞，但大多数网络安全任务将被重新路由至 Opus 4.8。

对于网络防御者，我们很快将把我们的网络验证计划扩展至涵盖 Opus 5.5。新计划将包含三个层级，提供越来越宽松的可信访问权限，包括对 Claude Mythos 模型的访问。Claude Security 已经可用，并可访问 Claude Mythos 5.1。

生物学。 Opus 5.5 在生物学方面能力极强，超越了 Opus 5，并在许多工作领域与 Claude Mythos 5.1 持平或更胜一筹。例如，Opus 5.5 在与 Dyno Therapeutics 合作开展的一项长时程分子预测与设计评估中取得了改进，专家红队成员将其科学新颖性评为与他们测试过的最佳模型相当。

因此，Opus 5.5 使用与 Fable 5.1 相同的生物学保障措施。若要使用 Opus 5.5 进行受这些保障措施阻碍的研发工作，用户可以申请我们的新生命科学验证计划，该计划为学术实验室、初创公司和制药公司等经过审查的组织提供针对全方位生物学相关工作设计的保障措施访问权限。感兴趣的组织可在此申请。

蒸馏

蒸馏攻击，即攻击者利用数千个虚假账户以工业规模提取模型能力，会带来安全和国家安全风险。蒸馏使恶意行为者能够在没有我们为 Claude 内置的保障措施的情况下创建能力极强的模型。我们的2026 年 9 月威胁情报报告详细介绍了我们迄今已检测并阻止的非法蒸馏活动。

Opus 5.5 发布时带有保留思考（preserved thinking）功能，这是我们随 Fable 5.1 引入的防蒸馏保护措施。它可阻止 API 用户编辑 Claude 的先前上下文，以试图提取 Claude 的推理过程。该措施适用于 2026 年 8 月 31 日或之后创建的 API 账户所使用的 Fable 5.1 和 Opus 5.5。我们的帮助中心文章解释了这一变更，我们的保留思考文档展示了如何测试和更新你的集成。

数据保留与合规

与之前的 Opus 模型一样，Opus 5.5 可提供零数据保留。

与 Fable 5.1 一样，Opus 5.5 附带我们的水印措施，以符合欧盟《人工智能法案》，此处有讨论。它也不再支持关闭“思考”模式，正如我们在此处所述。

可用性

Claude Opus 5.5 现已在所有平台上线，包括 Amazon Web Services、Google Cloud 和 Microsoft Azure。在 Claude Platform 上，开发者可以通过 claude-opus-5-5 开始使用

。