分析 Claude API 中斷：錯誤率與基礎設施壓力

大型語言模型 (LLM) API 的可靠性是現代軟體開發的關鍵支柱，特別是當像 Claude Code 這樣的工具將這些模型直接整合到工程工作流程中時。當這些服務出現故障時，其連鎖反應會立即影響數千個自動化系統和開發者環境。

2026 年 5 月 15 日，Anthropic 經歷了一段錯誤率升高的時期，影響了其多個旗艦模型。雖然事件已相對快速地解決，但它凸顯了模型能力與基礎設施穩定性之間持續存在的緊張關係。

事件時間線

此次中斷主要影響了 Claude API (api.anthropic.com) 和 Claude Code。根據官方狀態更新，事件經歷了識別與解決的幾個階段：

• 調查階段： 問題最初被標記為針對錯誤率升高的調查。
• 識別階段： Anthropic 識別出 Claude Opus 和 Sonnet 4.6 的請求都受到了影響。
• 恢復階段： 恢復分階段進行。Opus 4.7 和 Sonnet 4.6 首先恢復正常成功率，隨後 Claude Opus 4.6 完成最終解決。

技術影響："過載" 錯誤

在中斷期間，用戶報告收到 overloaded_error 訊息。這種特定的錯誤通常表示系統無法處理目前的請求量，指向容量或排程瓶頸，而非模型本身的邏輯錯誤。

一位開發者在其遙測數據中注意到了一個特定模式，暗示供應商可能試圖透過快取來緩解負載：

我可以看到在幾分鐘前，我的快取命中率出現了奇怪的激增，所以這實際上可能是他們額外加入的快取。

從系統工程的角度來看，這凸顯了「重試風暴」(retry storms) 的危險性。當 API 回傳過載錯誤時，用戶端系統通常會實施指數退避 (exponential backoff)。然而，如果大量用戶端同時進行重試，他們可能會在無意中造成第二波流量，使系統保持在過載狀態，阻礙其自然恢復。

開發者體驗與依賴風險

此次中斷引發了開發者社群對於極度依賴雲端 AI 服務風險的更廣泛討論。隨著越來越多的組織將其工程能力轉向依賴雲端的代理程式 (agents)，缺乏本地開發替代方案成為了一種負擔。

社群討論中出現了幾個關鍵爭議點：

1. 本地與雲端的權衡

對於在雲端服務故障時無法進行本地開發的不滿情緒日益增加。完全依賴遠端推論的轉向，意味著單一 API 中斷可能會使整個工程團隊的生產力陷入停滯。

2. 容量與擴展性

用戶表示希望新的基礎設施合作夥伴關係（例如提到的關於 xAI 容量的部分）能緩解這些瓶頸。文中提到了「增加車道悖論」(adding lanes paradox)——即增加容量有時反而會吸引更多需求，導致回到同樣的擁塞問題。

3. 溝通與開發者關係 (DevRel)

除了技術故障外，一些用戶也批評了 Anthropic 領導層與開發者關係 (DevRel) 的溝通風格，與競爭對手相比，建議更透明且積極的互動回饋機制可以緩解技術不穩定性帶來的挫折感。

結論

雖然 5 月 15 日的事件在幾小時內得到了解決，但它提醒了目前 AI 基礎設施的脆弱性。對於建立在這些模型之上的開發者來說，實施強健的錯誤處理、熔斷器 (circuit breakers) 以及探索混合本地/雲端策略，對於確保在面對不可避免的供應商中斷時的業務連續性至關重要。