Claude一天3崩,API、App、Cowork全挂,打工人集体抓瞎

marsbit發佈於 2026-08-26更新於 2026-08-26

文章摘要

8月24日,Anthropic公司旗下AI助手Claude在一天内发生三次严重服务中断,API、App及Claude Code、Cowork等全线服务崩溃,主要报错为“529 Overloaded”,持续近三小时,导致大量用户工作流程受阻,有用户自动化任务运行九小时后因此失败。 这已是Claude在8月份第13个发生故障的日子,故障频率极高。尽管官方状态页多次显示恢复,但用户实际体验仍频繁出现登录失败、页面白屏等问题,服务状态反复“仰卧起坐”。 据第三方监测,自2026年1月以来,Claude已累计发生184次故障。用户普遍抱怨近期模型性能(如Opus 5)出现明显退化,响应变慢,甚至出现“智力下降”的感知。有开发者指出,这可能与“算力耗尽”或“容量约束”有关。 官方公布的90天可用率数据显示,claude.ai、API等服务可用性约99.3%左右,但未达到企业级服务99.9%的标准。对于依赖长时间运行AI Agent的用户而言,服务中断带来的损失远不止停机时间,还包括已消耗的算力与任务进度。截至报道时,Anthropic仍未详细说明8月24日故障的具体技术原因。

哎,这谁顶得住啊。

8月24日这一天,Claude连着崩了三次。

Anthropic的状态页当天接连亮起三次刺眼的红灯,官方也三次跳出来宣布服务已经全面恢复。

可每一次页面刚变绿,X上依然哀嚎一片,一大批用户还在喊自己这边根本打不开。

这是Anthropic在8月里第13个留下事故记录的日子。

好家伙,这个月总共才过去24天。

结果你告诉我Claude有一多半的日子,都是躺在病床上的。

有位Reddit老哥更是吐槽,自己有个自动化流程辛辛苦苦跑了九个小时,硬生生断在这次大宕机里,直接全部白干。

529,后厨直接着火了

故障全面爆发的时候,用户屏幕上齐刷刷跳出来的是529 Overloaded。

用过API的人都熟悉429,也就是限流,相当于餐厅告诉你点得太快请稍等。

而529代表整个系统彻底超载,相当于餐厅直接跑出来通知你,对不起,咱们后厨着火了。

按状态页的记录,这把火从北京时间8月24日中午12点50分一路烧到下午3点36分,前后折腾了将近三个小时。

警报拉响21分钟后,官方还挺自信,说已经定位到根因。

然后呢。然后就没有然后了。Anthropic既没有披露技术原因,也没给出完全恢复的时间。

受牵连的受害者名单拉得老长。

Mythos 5、Fable 5、Opus 5和Opus 4.8一起趴窝,claude.ai、API、Claude Code和Cowork全线告急。

最后只有Console和Claude for Government这两处据点勉强躲过一劫。

整个Claude技术栈,这波基本算是被打穿了。

反复仰卧起坐,红了又绿了又红

更荒诞的剧情还在后头。每次官方刚宣布抢修好了,它转头就能再死给你看一遍。

模型那波全线报错持续了将近三个小时,恢复。

结果撑到25日刚过零点,登录系统又双叒叕挂了,claude.ai和Claude Code订阅全部惨遭波及,折腾六分钟才缓过劲来。

还没消停几个小时,凌晨4点整又挂了一次,这回硬卡了八分钟。

有个专门死盯Claude登录状态的监测机器人isclaudedownbot,在4点11分发了条推,全文没有任何废话,只有一个词。

Yes。

你还真别说,这个毫无感情的播报精准到了极点。

Anthropic的官方通稿写得一如既往地体面,说服务已经在Claude.ai、Claude Code和Claude API全面恢复,公司知道大家有多依赖Claude,感谢各位在团队排查期间的耐心。

话虽如此,但状态页翻绿,绝不等于你的账号就能用。

网友elstar当天发的那条推,字里行间已经听不出吐槽了,更像在求救。

而实际情况是,官方状态此刻确实显示一切正常,但残留的认证和前端故障,正在让一部分倒霉用户的settings、usage和skills页面直接变成一片刺眼的白屏。

一切正常和页面白屏,这两件互相矛盾的事情,就在这一刻同时成立了。

直到深夜,依然有倒霉蛋在网上怒吼Claude down again。

故障正在疯狂打卡

而这一天,其实一点都不孤单。

第三方监测服务StatusGator显示,从2026年1月算到现在,Claude已经累计了184次故障记录。

要知道,现在可仅仅才8月。

而顺着状态页一路往回翻,整个8月的故障清更是单密密麻麻得就像日程表。

20日一天爆了两起,19日到16日每天雷打不动各一起,15日Fable 5直接崩了约四个小时,到了14日更是彻底放飞,一天连发三起,13日和12日又毫无悬念地各有一起。

这其中最惨烈的要数8月5日那次,一崩就是暗无天日的7.5个小时。

用户当时在屏幕上看到的报错原文是Due to unexpected capacity constraints,翻译过来就是意外的容量约束。

算力枯竭,谁动了我的推理智商

capacity constraints这个词,这个月在报错里出现了不止一次。

而在X上,被反复提起的是另一个词组,ran out of compute,算力耗尽。

有开发者把话挑明了说,Opus 4.6曾经聪明得让人头皮发麻,后来他们好像就是彻底耗尽了算力,然后把所有东西都给削弱了。

网友Eason也感觉,Claude遭遇了史无前例的最严重智力退化,Opus 5根本没法用,自己甚至已经退回去用Opus 4.8了。

主动往回倒版本,这种操作在卷上天的AI圈属实少见。

当然,这些顶多只能算是用户的玄学体感,拿不出铁证。

于是有人把两家拉到一起跑了一把。

同一个棘手任务,Opus 5的xHigh档足足要熬一个小时,而换上另一家的同档模型,15分钟就搞定了。

整整4倍的差距,让人倒吸一口凉气。

甚至,就连AMD的AI总监Stella Laurenzo都亲自下场,把自己团队多达6852个Claude Code会话全翻了出来。

结果拉出来一看,曲线上赫然是一条断崖。

1月底的时候,模型思考深度还有大约2200个字符,到了3月上旬只剩下可怜的560个,暴跌75%。

更让人细思极恐的巧合是,就在同一段时期,Claude Code的思考内容开始悄悄对用户隐藏,仅仅一周之内,隐藏比例就从1.5%一路推到了100%。

换句话说,在模型肉眼可见变笨的同时,你连它究竟是怎么变笨的,都彻底看不见了。

Agent熬了九小时,状态页记了几分钟

Anthropic自己挂在官网上的90天可用率是这么写的,claude.ai 99.33%,API 99.43%,Claude Code 99.35%。

乍一看是妥妥的满分答卷。可企业级服务的及格线,是99.9%。

更何况,在可用率这把尺子诞生的那个古典互联网年代,服务中断只意味着网页打不开,你随手刷新一下就能接着干活,损失的就是刷新的那几秒。

然而,对于一个Agent来说,长任务一旦被打断,赔进去的从来就不止中断的那几分钟,还有它此前已经烧掉的所有时间、上下文和算力。这笔账,状态页根本记不了,也没法记。

如今,Anthropic依然没有说明8月24日那三个小时到底发生了什么。

而红了13天的这个8月,还剩七天。

参考资料:

https://x.com/ns123abc/status/2091784366519193852

本文来自微信公众号“新智元”,作者:ASI启示录,编辑:摩西

相關問答

Q根据文章描述,2026年8月24日Claude服务中断了几次?

A根据文章描述,2026年8月24日,Claude服务接连中断了三次。

Q文章中提到,用户遇到‘529 Overloaded’错误代码意味着什么?

A文章中提到,‘529 Overloaded’意味着整个系统彻底超载。这不同于表示限流的‘429’错误,它相当于整个服务后端无法处理请求,被比喻为‘后厨直接着火了’。

QAMD的AI总监Stella Laurenzo分析Claude Code会话数据,发现了什么问题?

AAMD的AI总监Stella Laurenzo分析其团队6852个Claude Code会话数据发现,模型思考深度(字符数)从1月底的约2200个暴跌至3月上旬的约560个,下降了约75%。同时,Claude Code的思考内容开始对用户隐藏,隐藏比例在一周内从1.5%升至100%。

Q文章列举了Anthropic官方公布的90天可用率数据,其与企业级服务及格线的差距说明了什么?

A文章指出,Anthropic官方公布的claude.ai、API和Claude Code的90天可用率分别为99.33%、99.43%和99.35%。而企业级服务的及格线是99.9%。这个差距说明Claude服务的稳定性尚未达到企业级应用的要求标准。

Q文章中提到,8月5日的长时间故障,用户看到的报错信息是什么?这个月报错中反复出现的核心词是什么?

A8月5日长时间故障中,用户看到的报错信息是‘Due to unexpected capacity constraints’。此外,文章指出‘capacity constraints’(容量约束)和用户社区提到的‘ran out of compute’(算力耗尽)是这个月故障讨论中反复出现的核心词。

你可能也喜歡

a16z 深度分享:别再抓 AI 味了,这是一份与AI写作共舞的实操指南

a16z 深度分享:别再纠结于识别“AI味”,而应学习如何与AI协作进行有效写作。本文认为,单纯识别AI写作的“破绽”并不可靠,且这些特征在人类写作中也长期存在。文章从四个维度分析了AI辅助写作的常见特征,并提供了实用的编辑与协作指南: 1. **修辞特征**:警惕“洞察形状”的写作,如语义空洞的“公司腔”、过度对仗、总结式短语等。这些表达听着好听但缺乏实质,应通过“转述测试”进行编辑,追求具体和直白。 2. **嗓音特征**:避免千篇一律的“Alexa嗓音”,如泛泛的温情、可循环套用的句式、抽象名词和低摩擦词汇。写作应保留个人特色和具体表达,仅在需要标准化沟通(如支持文档)时使用中性语调。 3. **结构特征**:注意“结构过剩”问题,如过度使用子标题、清单、路标和套路化开头。结构应为内容服务,根据不同体裁(如叙事、指南、评论)选择合适格式,避免生硬套用模板。 4. **标点特征**:无需过度回避破折号等所谓“AI标点”,关键在于使用得当、不影响阅读流畅。应避免标点使用过于密集或单一,并通过朗读来检验其自然度。 核心建议是:利用AI辅助构思、组织和初稿撰写,但务必注入个人思考与风格。重点不应是“是否由AI生成”,而是最终内容能否清晰、有效地达成沟通目的。好的写作是工具与创作者意图的共同成果。

marsbit29 分鐘前

a16z 深度分享:别再抓 AI 味了,这是一份与AI写作共舞的实操指南

marsbit29 分鐘前

交易

現貨
活动图片