Claude Opus 5.5 正式发布：832 分成社区热议

我们推出 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 System Card 中找到。

由于 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 和按席位计费的企业计划的五小时使用限制。我们还为订阅用户提供速率限制重置，现在你可以保存并在任何需要时使用。

沟通。 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 之间的差距比这些分数显示的要小。

	Opus 5.5	Fable 5.1	Opus 5	GPT-6 Astra	GPT-5.6 Sol
智能体编码
Terminal-Bench 4.0	66.4%	55.8%	52.3%	57.9%	37.3%
FrontierCode v1.1 (Main)	54.4%	50.3%	48.0%	53.3%	47.5%
CursorBench 4.0	57.8%	51.8%	46.6%	—	41.7%
知识工作
GDPval-AA v2.1	1846	1735	1708	1542	1588
业务工作流
AutomationBench²	40.0%	31.4%	26.9%	41.4%	28.8%
多学科推理
Humanity's Last Exam	67.7%（带工具）	65.6%（带工具）	63.6%（带工具）	57.2%（带工具）	—
智能体科学研究
Terminal-Bench-Science 0.1³	58.7%	52.6%	29.0%	64.6%	22.4%
计算机使用
OSWorld 2.0	81.8%（部分）	80.7%（部分）	74.0%（部分）	—	—
视觉图表识别
Chartography	89.0%（带工具）	88.4%（带工具）	83.4%（带工具）	—	—

除非另有说明，所有 Claude Opus 5.5 结果均使用最大努力的 adaptive thinking。Terminal-Bench 4.0 的结果分别来自 Claude Opus 5.5（xhigh effort）和 GPT-6 Astra（high effort），数据来源为 OpenAI；这些分数代表各模型的最高分。Claude Opus 5.5 在启用生产护栏的情况下进行评估。当护栏介入时，网络安全任务由 Claude Opus 4.8 完成，生物学和前沿 LLM 开发任务由 Claude Opus 5 完成。这可能会降低 Claude Opus 5.5 在这些基准测试上的表现。

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

² AutomationBench：AutomationBench 结果由 Zapier 运行和报告。这些运行在没有 fallback 模型的情况下进行，因此护栏介入被视为失败——这导致分数低于 Claude Opus 5.5 在实际中能达到的水平。Claude Opus 5.5 的结果来自 Zapier 在早期访问期间自己的评估。Opus 5、GPT-5.6 Sol 和 GPT-6 Astra 的结果来自 Zapier 的公开排行榜。

³ Terminal-Bench-Science 0.1：每个模型的标准误差为 ±3.5–5 分。公开排行榜（每任务 3 次试验，Claude Code harness）报告 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 万行代码的代码库进行了审计和修复，耗时不到 3 小时，而 Opus 5 花费了 超过 20 小时，且消耗了 2.5 倍的 token。在一项内部测试中，我们让 Opus 5.5 和 Fable 5.1 将广泛使用的负载均衡软件 HAProxy 从 C 语言重写为 Rust。两种重写都通过了 HAProxy 自身几乎所有的回归测试，但 Opus 5.5 在 9.5 小时内完成，而 Fable 5.1 用了 12 小时，且 Opus 5.5 的成本降低了 51%。

Opus 5.5 以极低的成本在 AI 智能体编程领域达到了前沿水平。在 FrontierCode 默认努力等级下，它的性能优于 GPT-6 Astra，而每个任务的成本约为后者的 20%。在 Terminal Bench 4.0 上，它与 Astra 性能持平，成本约为后者的 40%，而在 CursorBench 上它以 约三分之一的价格领先 GPT-5.6 Sol 11 个百分点。

Terminal-Bench 4.0	Accuracy vs Cost
Opus 5.5	Fable 5.1

Terminal-Bench 4.0 衡量模型在命令行界面中完成复杂多步骤专业任务的能力。Opus 5.5 以默认努力等级（medium）击败了 Opus 5 以最大努力等级（max）达成的成绩，且成本仅 为后者的五分之一。它以约 40% 的成本与 GPT-6 Astra 性能持平。

FrontierCode v1.1, main set	Accuracy vs Cost
Opus 5.5	Fable 5.1

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

CursorBench 4.0	Accuracy vs Cost
Opus 5.5	Fable 5.1

CursorBench 评估 AI 智能体在来自真实 Cursor 会话的模糊多文件任务上的表现。在默认 努力等级（medium）下，Opus 5.5 得分为 52.5%，而 Fable 5.1（max）为 51.8%， Opus 5（max）为 46.6%。它以约三分之一的价格领先 GPT-5.6 Sol 的最高分（41.7%） 11 个百分点。

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

"开发者需要能够承担真实软件工作并完成它的 AI 智能体。在我们对 GitHub Copilot CLI 和 VS Code 的测试中，Claude Opus 5.5 是我们测量中使用 token 和步骤最少的 模型之一。在 VS Code 中，它以不到一半的步骤解决了比 Opus 5 更多的终端任务。 不仅仅是让单个任务更高效，它还在让开发者的大型项目更容易实现。"

"我给 Claude Opus 5.5 一个横跨六个代码库的大型工程任务，让它通宵运行，无人值守。 它在超过 18 小时内始终保持任务方向，定义了我们的服务之间如何通信，以及每个服务 如何应用这些通信规则。与 Opus 5 相比，它更快地达成里程碑，需要的返工也最少。 它的代码注释简短实用，而不是冗长且像散文一样。我找不到什么负面评价。"

"对于 Lovable 的构建者来说，Opus 5.5 意味着更快的构建速度且质量不变，无论你是从零开始 还是在一个运行中的应用上工作。它一次性收集上下文，做的修改更少但更完整，不会陷入 重试循环，完成的步骤减少到三分之一到二分之一，同时使用的 token 也显著减少。"

"我们在 Chat、Cowowork 和 Claude Code 中测试了 Claude Opus 5.5，覆盖了我们团队工作 的全部方式。一个以前需要 38 次提示、耗时 4 天的复杂编码任务，在 3 小时内用 11 次提示就完成了，输出更接近生产就绪，返工更少。对于我们的团队在快速节奏中 解决复杂问题，这意味着更少的迭代时间、更多用于质疑的时间：测试假设、压力测试输出、 最终找到最适合客户的解决方案。"

"使用 Claude Opus 5.5，我们在内部评估中看到了 token 效率的明显改善，因为我们能够以 更低的成本、更快的速度完成相同的任务。"

"我们用真实的工程和交易台工作来测试模型。在我们的 AI 智能体编程任务上，Claude Opus 5.5 以大约一半的轮次、时间和输出 token 匹配了 Opus 5 的质量，将该工作负载的成本 降低了 40% 到 50%。它在某个交易台的交易支持套件上创下了我们记录过的最高分， 通过了之前 Claude 模型失败的任务，并在我们的分析任务上超越了全部八个模型。"

"Claude Opus 5.5 更有效地向子 AI 智能体委托任务，并以创造性的方式检查自己的工作。 自我验证循环感觉更容易设置。它在我们云账单中发现了之前模型错过的节省机会， 而且在代码审查中，它通过检查第三方集成的外部文档发现了一个 bug——那个集成在 之前的多次提交中都被错误建模了。"

"AI 智能体所做的每一次调用都是开发者感受到的时间和成本。在一个真实命令行任务的公开 基准测试中，Claude Opus 5.5 解决了比 Opus 5 更多的问题，同时减少了约 40% 的 调用次数并使用了一半的 token。对于使用 Kiro 构建应用的开发者来说，这意味着无论是 常规任务还是复杂挑战，都能获得更快、更经济实惠的 AI 智能体会话。Opus 5.5 即将在 Kiro 中可用。"

最安全的 AI 智能体编程模型

在系统中使用 AI 智能体的企业需要确保这些 AI 智能体按预期运行，尤其是在它们自主运行数小时的情况下。 Opus 5.5 有一个分类器在每次操作运行前对其进行筛查，有一个安全团队可以审计的开源沙箱， 以及在代码合并前捕获漏洞的代码审查功能。

模型本身的防御能力也更强。在提示词注入攻击方面，在我们测试的所有场景（包括编程、 工具使用、计算机使用和网络浏览）中，它与 Opus 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 分析两家虚构 HR 软件公司之间的拟议并购。 两者都构建了 Excel 财务模型，然后将其转化为关于该价格下交易是否有意义的执行层演示文稿。 两个模型对交易的结论相同，但 Opus 5.5 的模型更详尽，其演示文稿更易于阅读， 而 Opus 5 的模型有轻微错误。Opus 5.5 在 63 分钟内完成，而 Opus 5 用了 93 分钟， 成本降低了 50%。

在知识工作评估中，Opus 5.5 以更少的 token 超越了其他模型。在 GDPval-AA v2.1 （一项跨 44 个职业的真实世界工作测试）中，Opus 5.5 得分为 1846 Elo，领先于 Fable 5.1 和 Opus 5。在默认努力等级（medium）下，Opus 5.5 以每个任务约五分之一 的成本击败了 GPT-6 Astra 以最大努力等级（max）达成的成绩。在衡量业务流程和大规模 数据收集的基准测试中，它同样超越了其他模型。

GDPval-AA v2.1	Elo vs Cost
Opus 5.5	Fable 5.1

Artificial Analysis 的 GDPval-AA v2.1 在 44 个职业的真实专业工作上评估 AI 智能体。 在最大努力等级（max）下，Opus 5.5 得分为 1846 Elo，其中 Fable 5.1 为 1735， Opus 5 为 1708。在默认努力等级（medium）下，Opus 5.5 以每个任务约五分之一的 成本击败了 GPT-6 Astra 以最大努力等级（max）达成的成绩。

Artificial Analysis 的 GDPval-AA v2.1 在 44 个职业的真实专业工作上评估 AI 智能体。在最大 effort 下，Opus 5.5 得分为 1846 Elo，Fable 5.1 为 1735，Opus 5 为 1708。在默认 effort（中档）下，Opus 5.5 以约五分之一的单任务成本击败了最大 effort 下的 GPT-6 Astra。

Zapier 构建的 AutomationBench 测试 AI 智能体能否在多个互联应用间执行真实业务工作流。Opus 5.5 在每个 effort 级别上均超越 Opus 5 和 GPT-5.6 Sol。

Perplexity 的 WANDR 基准衡量 AI 智能体在大规模数据采集任务上的表现。Opus 5.5 以更低的单任务成本超越 Fable 5.1 和 Opus 5。

4.Perplexity 的 WANDR 基准衡量 AI 智能体在大规模数据采集任务上的表现。Opus 5.5 以更低的单任务成本超越 Fable 5.1 和 Opus 5。

4.WANDR：Claude 模型使用离线版本的网页搜索和网页获取工具、编程化工具调用、代码执行以及 98 万 token 的任务预算运行。这与 Perplexity 发布的设置不同，因此分数不能直接跨两者比较，我们仅展示在同一条件下评分的模型。

我们的客户报告了类似的结果。以下是他们使用该模型的反馈：

"即使在其最低 effort 设置下，Claude Opus 5.5 也在代码审查中捕获了 72% 的已知 bug，而 Opus 5 在高 effort 下仅为 56%，同时误报更少、输出也少得多。在美国咨询分析中，低思考 effort 与其更高思考设置输出一致，且通过我们的质量检查。当在生产环境中部署更多低思考 effort 时，这是高效交付的客户级可交付成果。"

"金融机构需要始终正确的输出。在最低 effort 设置下，Claude Opus 5.5 在我们的 BigFinance Bench 上以约少 60% 的输出 token 击败了高 effort 下的 Opus 5。它的答案更简短、结构更好，幻灯片也更密集，更符合行业标准。"

"评估新模型是我们多模型方法的核心，LexisNexis Legal Intelligence Engine 正是基于此构建。在我们的初步评估中，Claude Opus 5.5 一致地识别出高度相关的引用，在法规方面表现出色，并围绕核心法律框架和关键问题组织答案。这些正是我们寻找的能力，以帮助我们的客户通过 Lexis+ 和 Protégé 完成更多工作。"

"在量化研究中，一个错误的假设就能颠覆结果。在最低 effort 设置下，Claude Opus 5.5 在很大程度上解决了我们的评估任务。在更高设置下，它走得更远：它发现我们自身指令中的分钟索引偏差了一，并进行了修正，同时指出这会在评分中扣分。它是正确的，而我们测试过的模型中还没有任何模型能够发现并主动修正这一点。"

"随着模型在数据工作上越来越好，我们看到更多听起来令人信服但数据并不支持的结论。Claude Opus 5.5 会持续挖掘，超越第一个看似合理的答案。我们的 DataBench 基准中有一个任务要求判断包裹是延误了还是仅仅追踪变慢。Opus 5 检查了发货确认并判定追踪正常。Opus 5.5 则发现包裹确实延误了，而且追踪也坏了。我们正将它引入 Hex 智能体来做这项工作。"

"CoCounsel 将多个模型与我们的内容和专业知识结合，用于复杂的法律工作。使用 Claude Opus 5.5，我们在专家评估和内部基准测试中看到了更好的结果，同时在速度和 token 效率上也有提升。我们很高兴客户能够在与 CoCounsel 作为思维伙伴的反向讨论中体验到这种差异，权衡证据、完善思维，而这些是基准测试无法完全捕捉的。"

"在对照专家评分标准进行的端到端金融工作流上，Claude Opus 5.5 覆盖了我们所寻找的 86.6%，而 Opus 5 仅为 60.3%。在检索评估中，它以比 Opus 5 更好的 token 效率实现了我们史上最佳的引用召回率，这使我们每次研究任务的成本保持在可控范围内。"

"Viktor 是一个生活在 Slack 和 Microsoft Teams 中的 AI 员工，因此他采取的每一步都会反映在我们的成本中。在相同的 effort 下，Claude Opus 5.5 每个任务需要的步骤和工具调用比 Opus 5 更少，成本约为一半，同时在我们最难的任务上正确率是其两倍。"

我们对 Opus 5.5 的写作和沟通方式进行了重大改进，这是我们对 Opus 5 最常收到的反馈领域之一。它的消息一目了然，测试者表示这在长时间工作时非常有帮助。它将最重要的信息放在前面，更少使用术语或特殊短语，并遵循你给它的写作规则。我们发现这使 Opus 5.5 成为明显更好的协作伙伴。以下是两个模型的并排对比：

Claude Opus 5

Please explain the issue to me.

Claude Opus 5.5

Please explain the issue to me.

Claude Opus 5

What I found

The extra drop isn't the free tier — it's a regression in 0552feb 
("extract billing period boundaries into periods.py", labelled 
"No behaviour change").

The bug

aggregate.monthly_usage used to do a half-open interval:
    start, end = month_start(year, month), next_month_start(year, month)
    if start <= e.ts < end:

It now does:

    if period.contains(e.ts)

and in 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 is a datetime at midnight, not a whole day. Subtracting one 
day from Sep 1 00:00 gives Aug 31 00:00, and the comparison is 
inclusive, so the period effectively ends at the first instant of 
the 31st. Every event timestamped after midnight on the last day of 
the month is silently dropped — roughly one day of usage per account, 
per month.

The new test_periods.py doesn't catch it because it only checks 
last_day.date() (which is correctly 2026-08-31) and tests contains 
at Aug 1 00:00, Aug 15 12:00, Jul 31 23:59 and Sep 1 00:00 — it 
never probes anywhere inside the 31st.

Claude Opus 5.5

Please explain the issue to me.

The extra drop isn't the free tier — it's a regression in 0552feb 
("extract billing period boundaries into periods.py").

aggregate.monthly_usage used to check a half-open interval 
[start, end). Now it uses period.contains(ts), which checks 
first_day <= ts <= last_day.

last_day is next_month_start - 1 day, giving Aug 31 00:00. Because 
the comparison is inclusive, the period ends at the first instant 
of the 31st. Events after midnight on the last day are dropped — 
roughly one day of usage per account per month.

test_periods.py doesn't catch this because it tests contains at 
Jul 31 23:59, Aug 1 00:00, Aug 15 12:00, and Sep 1 00:00 — it never 
checks any time on the 31st.