9月3日13点26分(UTC),Anthropic的状态页挂出一条通告:Claude Mythos 5.1、Claude Fable 5.1、Claude Opus 5三款模型出现"错误率升高",状态标成"调查中"。没写原因,没写恢复时间,四个产品面——claude.ai、API、Claude Code、Claude Cowork——全部被列为受影响。

这种通告本来见得多了,大模型公司几乎每周都在和自己的推理集群打架。但把这条通告拿去对照Anthropic自己过去十天的记录,会发现一件更值得说的事:名字对不上

型号对不上,时间也对不上

官方状态页显示,9月3日真正对应的正式事故名是"Elevated errors for Claude Sonnet 5",12点37分到12点56分,持续19分钟。而"Mythos 5.1/Fable 5.1/Opus 5"这组名字,其实对应的是8月24日凌晨04点50分开始的另一起独立事故,持续3小时40分才解决,涉及的型号还是没有".1"后缀的Mythos 5、Fable 5、Opus 5、Opus 4.8。

一个是19分钟的小波动,一个是近4小时的大故障,被拼在了同一句描述里。Reddit上有用户把9月3日这次事故和Mythos 5.1、Fable 5.1挂钩讨论,但官方记录写的明明是Sonnet 5——连围观的用户和官方口径都没对齐。

  • 风险.模型代号越滚越多,状态页记录反而越含糊,用户想核实到底哪个模型出了问题,只能靠猜。

这不是一次故障,是连续十天没消停

从8月24日到9月3日,Anthropic状态页至少记录了5起相关事故:8月24日的多模型错误(3小时40分)、9月1日platform.claude.com性能下降(约1小时,官方说推理和API未受影响)、9月2日Sonnet 5错误率升高(14分钟)、9月2日积分购买延迟导致部分API请求被误判"余额不足"(持续数小时)、再到9月3日这次。

十天五起:状态页记录一览 8/24 多模型错误 3小时40分 9/1 控制台降级 约1小时 9/2 Sonnet5错误+积分延迟 两起叠加 9/3 本次通告 型号名对不上

单看每一条都不算严重,连起来看,过去十天Anthropic的基础设施没有真正安稳过一天。

横向对比:Claude不是唯一在出事的一家

同期OpenAI的状态页也记录了多起独立事故:Responses API延迟升高、免费和Go套餐对话错误升高、新建账户错误、ChatGPT Work Mode高错误率。第三方独立探针在41天监测窗口里,9月1到2日抓到Google Gemini出现多起可归因于服务商侧的失败,同期没把Claude或OpenAI列进同一份失败名单。

Anthropic官方公布的Claude API过去90天可用率是99.54%,但这个数字不区分模型、不区分错误类型,近期这一串事故是否已经计入统计,官方没说。也就是说,错误率升高这件事本身,在整个行业里更像是背景噪音,不是Anthropic独有的短板。

一条通告,两种说法 原文/社区说法 Mythos 5.1 / Fable 5.1 / Opus 5 9月3日 13:26 UTC 调查中,无恢复时间 型号未见于同期官方记录 官方状态页记录 Claude Sonnet 5 12:37–12:56 UTC 持续19分钟,已解决 同一时间段的正式记录

我更在意的是记账,不是这次错误率

错误率升高本身不是新闻。用户端靠重试和降级兜底,这套惯性整个行业都懂,也都在用。我更在意的是:Anthropic现在同时维护Sonnet、Opus、Mythos、Fable四条代号线,还叠加全量发布和"受信任机构"限定发布两套权限。型号一多,口径一乱,连状态页自己都开始记混。

铁路刚普及那几年,各条线路轨距不统一,货物到了枢纽站得现场倒运——不是运力不够,是标准没统一。Anthropic现在的模型代号,有点像那批还没统一轨距的铁路:产品跑得快,记账跟不上。这个类比不完全成立,毕竟铁路轨距是物理约束,模型命名是内部管理问题,后者本该更容易解决。

状态页可以简单,不能连型号名字都对不上。

对用Claude Code、Claude Cowork做生产流程的开发者和企业客户来说,现实影响是具体的:多起事故叠加,意味着重试和降级不再是偶尔用一次的保险,得变成日常架构里的标配。目前只面向受信任机构开放的Mythos 5.1,访问权限管理本身是不是故障点之一,官方也没说清楚。

  • 结论.Anthropic如果真想把这类反复出现的模型级错误讲清楚,该做的不是再发一条"investigating",而是一份写明根因、写清影响范围的事后报告——先把自己的账本理顺,再谈可靠性。