ChatGPT、Claude、Grok 同日異常：不是「同一場大當機」，卻揭露 AI 可靠性風險

2026 年 9 月 3 日，OpenAI 的 ChatGPT 與 Codex、Anthropic 的 Claude，以及 xAI 的 Grok，在相近時段都傳出無法使用或錯誤率升高。對使用者而言，這看起來像「幾個主要 AI 同時掛掉」；但目前最重要的結論反而是：這是時間重疊的多起服務異常，並非已證實由單一原因引發的共同故障。

OpenAI 對自家事件的說明是路由錯誤；至於 Claude 與 Grok，公開報導及各供應商通知並未證實三者有共同技術根因。4041

當天發生了什麼？

OpenAI 表示，路由錯誤約從太平洋時間上午 7 時 43 分開始，使部分使用者在不同平台上無法使用 ChatGPT 與 Codex；約上午 8 時 17 分已部署解法，並持續監控恢復情況。40

OpenAI 的公開狀態事件於 14:58 UTC 建立，內容為 ChatGPT 與 Codex 出現「錯誤率升高」。17 後續對各家已解決通知的整理顯示，OpenAI 在 16:55 UTC 標示恢復。若以 7:43 a.m. PT（14:43 UTC）起算，這次事件約持續 2 小時 12 分鐘；但實際影響並不一致，並非每位使用者都全程無法使用。4041

同一較大時間範圍內，Claude 與 Grok 也有異常。依其狀態通知的報導整理，Anthropic 的模型錯誤事件於 16:16 UTC 解決；xAI 則在 17:07 UTC 表示 Grok 流量已恢復健康。41

用戶與狀態頁回報了哪些問題？

使用者回報的狀況包括登入失敗、對話出錯、沒有回應，以及網頁版與 App 無法正常存取。Downdetector 的資料顯示，ChatGPT 的回報量特別高：美國超過 35,000 筆，Claude 超過 1,400 筆，Grok 超過 1,200 筆；印度則有超過 2,800 筆 ChatGPT、約 170 筆 Claude、超過 70 筆 Grok 的問題回報。這些數字反映用戶主動回報，不等同所有受影響帳戶的完整統計，但可看出異常受到廣泛注意。42

OpenAI 狀態頁確認 ChatGPT 與 Codex 錯誤率升高，後續也將事件標記為已解決。1720 當時報導指出，ChatGPT 的網頁、行動裝置與桌面版都有用戶受影響，而不是只有單一介面故障。3950

Claude 方面，報導指向多個模型的錯誤率升高，包括 Mythos/Fable 5.1、Mythos/Fable 5、Opus 5、Opus 4.8 與 Opus 4.6。後續更新顯示，多數模型先回到基準錯誤率，但 Opus 4.8 與 Opus 5 受影響較久。364749

xAI 當時承認 Grok 正在發生問題，後續報導則稱流量已恢復正常。4941

Gemini 是當時「沒事的替代選項」嗎？

早期部分報導把 Google Gemini 描述為當時看似仍可使用的主要競品，但這個說法必須保留。另有報導顯示 Downdetector 也出現 Gemini 相關回報，然而提供的資料並沒有對應的 Google 官方確認事件。4448

實務上，同一服務可能對一部分用戶可用、對另一部分用戶卻持續報錯。故障追蹤網站很適合用來發現異常訊號，但不能取代供應商的事故報告或應用程式自身的監控資料。

為何這不只是「聊天不能問」？

對許多團隊來說，AI 服務中斷的損失不只是一時不能提問。程式助理或代理式工作流程失效時，開發工作可能停擺；API 回傳錯誤時，依賴它的產品功能與內部自動化可能排隊、失敗，或必須改由人工處理。使用搜尋、彙整或長時間任務的研究流程，同樣會受影響。

OpenAI 過往的狀態事件，也顯示 AI 平台故障的波及面很廣：Codex、搜尋、代理、Deep Research、連接器、檔案上傳、登入與依賴 GitHub 的工作流程，都曾分別出現異常通知。19242529

這不表示某一家供應商特別不可靠，而是說明：若關鍵流程只依賴單一供應商、單一模型或單一代理執行環境，營運上就會形成單點故障。

「Astra／GPT-6」傳聞不是故障證據

事件發生時間引發討論，因為有報導把它連結到 OpenAI 可能即將公布、被稱為「Astra」且可能與未來 GPT-6 世代模型相關的傳聞。不過，現有證據不支持兩者有因果關係。

OpenAI 對自家異常的說法是路由錯誤，沒有供應商公開把這些同步出現的問題歸因於 Astra、GPT-6 或模型發布。時間巧合可以成為吸睛敘事，但不能據此證明因果。403746

過往事故說明了什麼？

9 月 3 日不是這個市場首次出現服務中斷。xAI 的狀態紀錄顯示，Grok-2 曾在 2025 年 1 月 15 日發生逾時問題，持續 3 小時 10 分鐘；另一次 Grok-2 結構化輸出異常則持續 3 天 21 小時。23 OpenAI 的狀態紀錄也有 Codex 任務、ChatGPT 功能與 API 工作流程的不同事件。212732

不應利用這些紀錄替供應商排出可靠性名次：現有資料沒有提供一致的停機定義、影響範圍或受影響用戶數，無法進行公平比較。不過它們足以支持一個較窄但實用的結論：對把託管 AI 服務用於關鍵流程的團隊而言，服務中斷是必須納入規劃的正常風險。

降低單一 AI 供應商中斷衝擊的做法

• 盡量採用供應商中立的介面： 避免讓應用程式完全綁死在單一廠商的請求格式或工作流程。
• 預先定義備援： 重要任務可考慮第二家供應商、較小型的本機模型、功能降級流程，或人工處理方案。
• 讓非緊急 API 工作可安全排隊與重試： 同時設定上限，避免大量重試反而放大事故。
• 區分關鍵流程與便利功能： 聊天助理可以暫停；會卡住程式審查、客服或產品核心操作的流程，則未必能等。
• 演練切換與人工處置手冊： 從未實測的備援，不能算是可靠的持續營運方案。

9 月 3 日之所以罕見，在於多個知名 AI 服務看似同時出問題；它帶來的教訓卻很務實：與其試圖預測下一次故障何時發生，不如確保任何一家供應商的事故，都不會讓核心工作全面停止。41