三家 AI 紅燈重疊的 85 分鐘

本文有英文版，發表在 dvdmaru：The Three AI Outages Overlapped for 85 Minutes（英文）

9 月 3 日晚上 11 點多，三個分頁停在同一個地方。Claude 先報錯，接著是 Grok，然後是 ChatGPT。手上的活本來就刻意分散在三家跑，圖的就是一家出事還有另外兩家頂著，結果那段時間裡一件也推不動。

隔天社群上的說法是「三家 AI 同時掛了」。把四份官方狀態頁攤開對時間，這句話是壓縮過的。開始時間彼此錯開，三盞紅燈真正重疊的區間是 85 分鐘。而把窗口拉到過去 31 天，兩家同時亮紅燈發生過 4 天，9 月 3 日是第 4 天。

帳號開了幾個，跟手上有幾份保險，是兩件不同的事。

四起事故的開始時間，前後差了 2 小時 21 分

時間全部換算為台北時間。Claude 與 ChatGPT 的資料取自兩家 statuspage 的事故 JSON，Grok 的兩條取自 status.x.ai 的事故頁（該頁原生就以 GMT+8 顯示，未經換算）。表格五列、四起事故：Grok 那一次同時登記在 Grok（Web）與 Grok in X 兩個服務頁上，起點都是 21:30。

開始時間依序是 20:37、21:26、21:30、22:58，前後拉開 2 小時 21 分。三家同時掛著未結事故的交集，起點取最晚的 22:58、終點取最早的 00:23，共 85 分鐘。這裡取的是各家狀態頁登記的事故起訖；若改用 Anthropic 在更新裡寫的影響結束時間 00:16，交集是 78 分鐘。

Claude 當晚有兩起。第一起只影響 Claude Sonnet 5，19 分鐘就結束。第二起範圍大得多，官方在 21:50 的更新裡逐字列出受影響的模型：「An exhaustive list of affected models: Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, Opus 4.6.」。受影響的元件包含 claude.ai、Claude API、Claude Code 與 Claude Cowork，影響等級標為 major。23:25 的更新則寫著「The only affected models right now are Opus 4.8 and Opus 5. The rest of the models have recovered to baseline error rate.」。結案更新寫明影響結束於 16:16 UTC，也就是台北時間 9 月 4 日 00:16。換句話說，其餘模型在 23:25 之前就回到了基準錯誤率，Opus 4.8 與 Opus 5 的影響直到 00:16 才結束，至少相差 51 分鐘。同一起事故、同一個帳號，選哪個模型決定了那段時間能不能做事。

Grok 兩條線的時長是當晚最長的，頁面自己寫的是 3 小時 37 分與 3 小時 35 分。事故頁上的說法很短：「Grok is experiencing issues. We are working on restoring service as quickly as possible.」，結案時是「We have resolved the situation, and traffic is healthy again.」。

OpenAI 的狀態頁把開始時間登記在 22:58，事故附註提醒部分 Codex 遠端控制的使用者事後可能要重新配對行動裝置。

Engadget 在 9 月 3 日的報導裡也記了各家的時間：Grok 中斷三個半小時、從美西時間 6:30am 起算；ChatGPT 的使用者回報約 7:30am 開始、9:55am 恢復；Claude 的結案時間是 9:16am。換算成台北時間，結案時間對得上。起點則有兩處出入：Claude 的起點 Engadget 寫「大約 6:30am PT」，Anthropic 狀態頁登記的是 6:26am PT，也就是台北 21:26；ChatGPT 的 7:30am 是使用者回報湧入的時間，不是狀態頁登記的 22:58。本文一律以狀態頁為準。

兩家同時亮紅燈，過去 31 天裡發生過 4 天

抓 Anthropic 與 OpenAI 兩份 statuspage 的事故 JSON（抓取時間 9 月 4 日 17:22），把各家的事故區間先做聯集、再取兩家的交集，會看到另一組數字。

兩份資料共同涵蓋的窗口是 8 月 4 日 20:43 到 9 月 4 日 17:22，約 30.9 天。窗內 Claude 有 27 起事故、OpenAI 有 25 起。「任一事故未結」的時間佔比，Claude 是 5.7%、OpenAI 是 11.0%。

兩家同時有未結事故的時段，窗內共 6 段、合計 6.0 小時，分布在 4 個不同的日子（以起始日計，其中兩段跨過午夜）：

• 8 月 13 日 22:33 至 00:08（95 分鐘）
• 9 月 1 日 01:23 至 01:52（29 分鐘）
• 9 月 1 日 03:21 至 04:28（67 分鐘）
• 9 月 2 日 00:02 至 00:22（20 分鐘）
• 9 月 2 日 01:05 至 02:07（62 分鐘）
• 9 月 3 日 22:58 至 00:23（85 分鐘）

9 月 3 日的 85 分鐘是 6 段裡第二長的一段，最長的是 8 月 13 日那 95 分鐘。兩家一起亮燈，一個月內出現 4 天；9 月 3 日少見的部分是第三家也進來，而且剛好被很多人同時看見。

兩條限制要跟數字一起讀。第一，statuspage 的 JSON 一次只吐最近的 50 筆與 25 筆，窗口就只有 31 天，這個比例不能外推成全年的可用性。第二，「未結事故」不等於「服務不可用」——多數事故只影響部分模型或部分區域，狀態頁上亮著紅燈，手邊的請求未必會失敗。

Memphis 這條線，目前沒有任何一方回答過

Grok 恢復之後，SpaceXAI 在 X 上發了一則道歉貼文，全文內嵌在 Engadget 9 月 3 日的報導裡：

We are sorry for the issues you may have experienced with Grok following an outage at our Memphis compute center this morning. We'd also like to apologize to our impacted compute partners.

All systems have now been restored and are functioning nominally.

裡面有兩個詞值得停一下：Memphis compute center，以及 impacted compute partners。Musk 隨後回應公司正在「taking corrective action to ensure this does not happen again」，但 Memphis 那邊到底壞在哪，SpaceXAI 沒有公布，截至 9 月 4 日發稿仍未公布。

另一邊，Anthropic 在 2026 年 5 月 6 日發過一則公告，逐字是「We've signed an agreement with SpaceX to use all of the compute capacity at their Colossus 1 data center. This gives us access to more than 300 megawatts of new capacity (over 220,000 NVIDIA GPUs) within the month. This additional capacity will directly improve capacity for Claude Pro and Claude Max subscribers.」。CNBC 同日的報導寫明 Colossus 1 位於田納西州 Memphis，是 xAI 至今最大的設施；同一篇也提到 Musk 宣布 xAI 將不再作為獨立公司存在，改名 SpaceXAI——status.x.ai 現在的頁面標題確實已經是 SpaceXAI Status。TechCrunch 5 月 20 日引 SpaceX 遞交 SEC 的 S-1 補上金額：Anthropic 每月付 12.5 億美元，付到 2029 年 5 月，總額可能超過 400 億美元，任一方可提前 90 天終止。S-1 自己的說法是「allows us to monetize unused compute capacity in our infrastructure」。

時間上，Claude 的多模型事故開始於 21:26，Grok 的兩條登記都開始於 21:30，相差 4 分鐘。兩個時間各自取自兩家的官方狀態頁，而沒有任何來源把這 4 分鐘連起來。

把這幾件事放在同一條時間軸上，會讓人想問一個問題。而這個問題目前沒有任何一方回答過：

• SpaceXAI 說的是「our Memphis compute center」，沒有指名是哪一座。Memphis 一帶不只一座：最早的 Colossus 蓋在市內 Boxtown 一間舊 Electrolux 工廠裡，2025 年 3 月 xAI 又在 Whitehaven 的 Tulane Road 買下 100 萬平方英尺的地蓋第二座（DataCenterDynamics 依產權紀錄與孟菲斯商會的公告報導，金額 8,000 萬美元）。「出事的是 Colossus 1」找不到任何來源。
• 道歉貼文裡的「compute partners」沒有點名任何公司。查不到任何一手或二手來源寫出這份名單裡有誰。
• Anthropic 的狀態頁從第一則更新寫到結案，講的都是哪些模型錯誤率升高、哪些已經回到基準，沒有寫成因，也沒有提到任何第三方。Engadget 當天的報導寫明 Anthropic 與 OpenAI 都沒有立即回覆置評請求。
• Engadget 把兩件事並置報導，並且自己先把話說死了：「It's also not entirely clear which of SpaceXAI's "compute partners" may have been affected.」、「The company hasn't said if the unspecified issue was related to SpaceXAI's data center. The two companies signed a deal earlier this year for the Claude maker to lease compute from Musk's AI firm.」

還有一個常被略過的背景：Anthropic 那篇公告同時寫著「We train and run Claude on a range of AI hardware—AWS Trainium, Google TPUs, and NVIDIA GPUs—and continue to explore opportunities to bring additional capacity online.」，並列出其他幾份算力合約，包含 Amazon 最高 5GW、Google 與 Broadcom 的 5GW（2027 上線）、Microsoft 與 NVIDIA 的策略合作含 300 億美元 Azure 產能，以及與 Fluidstack 的 500 億美元美國基建投資。Colossus 1 是其中一份合約，不是全部的算力來源。

在任何一方開口以前，這條線只能停在問句上。

Google 官方沒有登記 9 月 3 日晚上的 Gemini 異常

當晚 Gemini 的情況，取決於問誰。

三個 Google 官方入口在該時窗都查不到事故。Google AI Studio 與 Gemini API 的官方狀態頁，歷史一路列到 2024 年 12 月，9 月 3 日沒有任何條目，最近一筆停在 2026 年 7 月 15 日的 AI Studio Build。Google Cloud 的事故 feed 在該時窗是 0 筆——不過整份 feed 只有 6 筆，本來就不能當完整歷史用。Google Workspace 狀態儀表板查得到的頁面，在 8 月 28 日到 9 月 4 日之間顯示 No incidents。

第三方監測與使用者回報是另一回事。StatusGator 記錄了 9 月 3 日的兩起 Gemini 異常，並且在條目上自己註明「Never officially acknowledged by Google」。Downdetector 的回報則經媒體轉述，從美東時間 8:44am（台北 20:44）起湧入。這些是第三方的說法，不是官方紀錄。

落差怎麼來的，Google 自己的狀態頁上就寫著。那個頁面有一個依付費層過濾的開關，說明逐字是：「Free-tier requests use sheddable capacity, while billed-tier requests are protected by critical priority.」。頁尾另有一句：「Individual customer availability may vary depending on billing status and surface used: free tier, billed tier, as well as the chosen model and API features in use.」。

這句話講的是容量類型與優先級：免費層用的是可以被丟掉的容量，付費層受關鍵優先級保護。它說明兩者的可用性可能不同，但沒有交代這種落差會不會登記成事故，也不足以單獨證明當晚的回報就是丟棄造成的。使用者覺得掛了，跟狀態頁維持綠燈，可以同時為真。

所以 9 月 3 日晚上的 Gemini，準確的寫法是：Google 官方沒有登記這幾個小時。使用者實際上有沒有被影響，狀態頁本來就不負責回答。

2025 年 11 月 18 日，別家的狀態頁上寫著 Cloudflare 的名字

真正的單點故障長什麼樣子，2025 年 11 月 18 日留下過一份範本。依 Cloudflare 事後公布的檢討報告，那天的成因是資料庫權限的一次調整，讓 Bot Management 用的特徵檔多出重複資料、筆數翻倍並超過系統上限；影響從 11:28 UTC 開始，到 17:06 UTC 全部恢復。

痕跡留在別人家。Google AI Studio 官方狀態頁的歷史裡至今有一條：「Apps in Build may not load due to global Cloudflare outage. Mitigations are underway.」，偵測時間 2025 年 11 月 18 日 20:35、解決 23:09，換算後正好落在 Cloudflare 官方公布的影響區間內。在這次 Cloudflare 事故裡，AI Studio 的狀態頁直接點名了 Cloudflare。

9 月 3 日晚上，四份狀態頁裡沒有任何一份提到共同的第三方。核對 Cloudflare 的事故 feed，9 月 3 日 21:00 到 9 月 4 日 01:30 的台北時窗內沒有全球性事故，當天只有香港的 5xx（17:21 至 17:36）與西雅圖的 522 之類區域性小事件。下游一起寫下同一個名字的痕跡，9 月 3 日晚上沒有留下。

共同第三方的候選從 Cloudflare 換成了 Azure，兩個都沒有官方說法

事件過後隔天，社群上流傳的成因換了一個名字：Microsoft Azure 的某一座機房，比較具體的版本指向 East US 區域。

先看微軟自己的紀錄。Azure 的狀態歷史頁依時間新到舊排列，最新一筆是 2026 年 7 月 23 日的「Post Incident Review (PIR) – Network connectivity – Issues accessing resources in West US」，9 月 3 日沒有任何條目。但這一頁自己寫了適用範圍：「From June 1, 2022, this includes PIRs for broad issues as described in our documentation.」——只有大範圍事故才會產出 PIR，區域性或只影響特定訂閱的問題走的是另一套個別通知，不會出現在這裡。所以這裡缺席的是紀錄，不是事件；跟 Gemini 那一節是同一個形狀。

再看這個猜想合不合理。它有合理的地方：Anthropic 5 月那篇公告裡就列著「A strategic partnership with Microsoft and NVIDIA that includes $30 billion of Azure capacity」，Anthropic 與 OpenAI 在 Azure 上有交集是查得到的事。

但「三家都靠 Azure」這個版本，被其中一家自己否掉了。SpaceXAI 的道歉貼文說得很清楚，事故出在「our Memphis compute center」——自家機房，不是雲端供應商。當晚唯一有官方具名說法的成因，指向的是 xAI 自己。

流傳的版本之間也對不上。有一篇的標題是「Gemini Survived When ChatGPT, Claude, and Grok Collapsed: Azure Is at Fault」，主張 Gemini 因為跑在 Google Cloud 才倖存；另一篇講 Azure East US 區域故障的，卻把 Gemini 也算成受害者。兩篇都沒有引用到微軟的任何說法。

值得記下來的是這個名字換過一次：9 月 3 日當天是 Cloudflare，隔天變成 Azure。兩次的共同點一樣——沒有任何一家廠商把自己的災情指向那個名字。

開三個帳號解決不了的兩件事

開三個帳號很快。難的是後面兩件事。

第一件是工作能不能換手。〈從 Claude 切到 Codex 要多久？〉那篇把摩擦拆成三層：憑證、記憶、工具。憑證那層通常最好解；記憶（脈絡在哪、前面談到哪、專案的慣例是什麼）與工具（MCP、外掛、腳本、輸出格式）才是真正卡住的地方。一份工作如果只有在某一家的環境裡才跑得動，它沒有備援，只有一個備用的登入頁面。

第二件是憑什麼知道現在該切去哪。狀態頁不替使用者回答這個問題。Google 那句 sheddable capacity 說明免費層與付費層用的是不同優先級的容量，但它沒有交代這種落差會不會登記成事故。Downdetector 的 Gemini 回報從台北時間 20:44 起就在湧入，Google 的三個官方入口至今沒有一條對應的紀錄。Claude 在 9 月 3 日的更新裡，其餘模型比 Opus 4.8 與 Opus 5 早了至少 51 分鐘回到基準錯誤率——同一個帳號、同一個時刻，換個模型就是不同的可用性。狀態頁回答的是「服務整體有沒有被判定為異常」，不是「你手上這個請求現在會不會成功」。

過去 31 天的數字擺在那裡：Claude 5.7%、OpenAI 11.0%，兩家同時亮燈 4 天。這些數字算不出「開幾個帳號才夠」，因為量的不是同一件事。（同一篇備援文以官方歷史頁重算過，Claude 在 2026 年 1 到 7 月共 326 起事件，是流傳的第三方數字的 2 倍以上——可用性數字本來就不能照抄。）

真正能拿來算的是另一個問題：手上哪幾件工作，禁得起那 85 分鐘裡三家都沒有把握？答案是哪幾件，備援就先做在哪幾件上。