三款最常被使用的 AI 服務，在同一個時段一起沒了回應。日本時間 2026 年 9 月 3 日深夜到 4 日凌晨，OpenAI 的 ChatGPT、Anthropic 的 Claude，以及 Grok 陸續發生障礙，三者都在各自的狀態頁面上確認了異常。從最初的異常到最後一則恢復通知，整起事件大約歷時四個小時。三家同時停擺並不常見，但原因看來未必只有一個。
三項服務相隔數十分鐘先後停擺
最先出狀況的是 Claude 與 Grok，日本時間 3 日晚間 10 點 30 分左右開始出現難以連線的回報。ChatGPT 則稍晚一些，在 4 日凌晨零時前後浮現異常。
以使用者的感受來說，這次比較接近「連不上」而不是「變慢」。障礙回報網站 Downdetector 上累積了超過 3 萬 5000 則回報，其中絕大多數與 ChatGPT 有關。雖然在日本正值深夜，但在美國是平日上午，因此有不少人的工作被迫中斷。
Anthropic 在日本時間 4 日凌晨 1 點 16 分表示問題已解決，並將狀態恢復正常；OpenAI 於 1 點 55 分、Grok 一方於 2 點 7 分先後回報恢復。三家大致在一個小時之內陸續收斂。
影響範圍不只是聊天畫面
這次障礙比較值得注意的一點，是影響遠遠超出了對話介面。
OpenAI 在狀態頁面上列出 ChatGPT 側 15 個元件，以及面向開發者的 Codex 側 4 個元件受到影響。對話、登入、搜尋、檔案上傳、語音模式、影像生成、Deep Research 以及代理功能幾乎同時劣化。官方也提醒，恢復之後部分 Codex 使用者可能需要重新與行動裝置配對。
Anthropic 的情況也類似。最初回報 Mythos 5.1、Fable 5.1 與 Opus 5 的錯誤率上升，之後範圍擴大到包含 Opus 4.8 與 4.6 在內的多個世代。受影響的不只是 Claude 應用程式，還包括 API、Claude Code 與 Claude Cowork，也就是說，建構在 Claude 之上的內部工具與自動化流程同時停了下來。
連鎖反應還往外擴散。AI 程式輔助工具 Cursor 公告指出，自家服務的異常源自 Grok 與 Claude 的障礙。依賴特定模型供應商的服務，上游一停就跟著停。道理並不複雜，只是這一天同時發生在兩家供應商身上。
是共同原因，還是巧合
三家在同一時段停擺，難免讓人懷疑底層存在共同因素。不過就目前公開的說明來看，還無法收斂到單一原因。
OpenAI 方面被描述為太平洋時間 3 日上午 7 點 43 分左右開始的路由問題。這屬於該公司自身的流量控制層面，並不是與其他公司直接共用的部分。至於 Anthropic 與 Grok 一方，則尚未公布詳細的技術拆解。
障礙期間，某大型雲端平台的異常回報也在相近時段增加，因而出現了共用基礎設施可能牽涉其中的看法。不過這並未獲得各家證實，僅止於從狀況推導出的推測。
更耐人尋味的是，Google 的 Gemini 始終沒有正式承認發生障礙。Downdetector 上同一時段 Gemini 的回報確實增加，但這也可能是其他服務停擺後使用者湧入所造成的壅塞與誤報。自建資料中心與晶片的 Google 得以倖免，在思考基礎設施該如何持有時頗具啟發性。
以「會停」為前提來設計
這次事件顯示，AI 服務的可用性已經不再是單一公司的問題。當開發現場把 Claude Code 或 Codex 這類代理當成日常工具使用時，它們一停，工作本身就推不動。與試算表或電子郵件不同，本機並沒有可替代的手段。
比較務實的準備包括：保留在多家供應商的模型之間切換的能力、把重要處理放進佇列以便重試，以及把各家的狀態頁面加入通知管道。最該避免的，是透過使用者的詢問才第一次得知障礙。
話雖如此，這次是三家同時停擺。即使準備了切換目標，該目標在同一時段也停擺的可能性並非為零。多重化本身並非萬能，這一點同樣值得記在心裡。
總結
日本時間 2026 年 9 月 3 日深夜到 4 日凌晨，ChatGPT、Claude、Grok 三項服務在同一時段發生障礙，並在約一小時之內先後恢復。影響不只於聊天畫面，還波及 API、代理功能，以及 Cursor 這類外部服務。OpenAI 提到了路由問題，但三家共同的原因並未公布，Gemini 也沒有承認障礙。AI 愈是被放在業務的核心，停擺時的代價就愈大。以多重化與重試為前提的設計，正在慢慢成為常識。
