Claude too many requests 錯誤（429）：是 Anthropic 的節流，不是方案上限，依序 6 個修復方法

Claude 出現 too many requests 錯誤該怎麼修復？

請依序執行這六個步驟。沒有任何一步會動到你的對話或方案。

1. 等一分鐘，再重試一次。 Anthropic 的 Claude Code 錯誤參考文件寫的是「Wait briefly and try again」。一直狂按重試只會送出更多請求。
2. 用 claude update 更新 Claude Code。 2.1.199 以後的版本會在你看到錯誤之前，先用退避機制重試這些節流。目前最新版本是 2.1.316，發布於 2026 年 10 月 31 日。
3. 執行 /status，確認目前使用的憑證。Anthropic 警告：「A stray ANTHROPIC_API_KEY in your environment can route requests through a low-tier key instead of your subscription.」
4. 關閉多餘的工作階段和 subagent。 對於 API 金鑰上的 429，文件建議「avoid running many parallel subagents」。在一位 Max 訂閱者的紀錄中，出現 429 的 122 分鐘裡有 114 分鐘同時開著六個以上的桌面版工作階段。
5. 用 /model 切換模型。 在 API 上，每個模型各有自己的每分鐘請求數與 token 數，所以改用較小的模型可以讓腳本繼續跑。
6. 查看 status.claude.com，然後回報。如果沒有公告，而錯誤持續數小時，請附上完整的訊息和 request ID 送出回報。

以下是 Claude Code 印出的原文：「API Error: Server is temporarily limiting requests (not your usage limit)」。Anthropic 的說明只有一行：「The API applied a short-lived throttle that is unrelated to your plan quota.」Claude Code 判斷它不是真正的上限，依據是「by the absence of the unified quota headers a real limit response carries」。在 Claude 桌面版 App 的 Code 分頁，一份 2026 年 5 月 30 日的錯誤回報顯示同樣的節流，會在寫著「Too many requests right now」的那行上方出現「Server is temporarily limiting requests」。這就是大家搜尋的「claude too many requests right now」。

我們在 2026 年 11 月 2 日搜尋了 Anthropic 公開的 Claude Code issue 追蹤區，找出 2026 年所有標題或內文含有「temporarily limiting requests」的 issue，共 410 筆。其中有一個帳號提報了 275 筆，而且它在 7 月下旬的回報全都寫著 Claude Code 2.1.114，那是 4 月的版本。我們把這個帳號排除。其餘 135 筆來自 125 位不同的人，其中 129 筆是在 7 月之前開的。2.1.199 的 changelog 條目寫道：「Transient server rate-limit errors (429s unrelated to your usage limit) are now retried automatically with backoff for subscribers instead of failing the turn」。節流並沒有消失。9 月有一份回報統計到單日 195 次被重試的 429。這個下降應解讀為失敗的回合變少，而不是 429 變少。

你看到的是哪一種 Claude too many requests 訊息？

訊息的措辭會告訴你，撞到的是誰的上限。下表涵蓋 Claude Code、Claude 桌面版 App 和 Claude API，內容以 2026 年 11 月 2 日讀到的為準。

Anthropic 給 Claude 各 App 的錯誤訊息指南完全沒有列出「too many requests」訊息。它列的上限已達訊息都會標明重置時間，只有「接近上限」的警告沒有。所以，如果你的訊息有寫出時間，你撞到的是方案上限，請看 Claude usage limit reached 的修復方法。如果訊息寫的是 overloaded 或 529，那是容量問題，請看 Claude overloaded。

用量很低，為什麼 Claude 還是說 too many requests？

用量低時 Claude 仍說 too many requests，是因為節流計算的是請求到達的速度，而不是你用掉多少方案額度。Anthropic 的速率限制頁面說明，限制可能在很短的時間內生效：「a rate of 60 requests per minute (RPM) might be enforced as 1 request per second.」所以一陣突發的呼叫可能失敗，即使你這一分鐘的平均看起來完全正常。

錯誤回報把這點說得很清楚。一位 Max 訂閱者在 2026 年 5 月 30 日遇到節流，而那天正好是他們的額度剛重置。一份 8 月 18 日的回報在用量 1% 時持續遇到 429。一份 9 月 24 日的回報在方案用量 26% 到 27% 時，開著六個以上的桌面版工作階段，有 14% 的工作階段分鐘出現 429；開五個以下時則不到 1%。

用量突然暴增也會觸發。Anthropic 的 API 錯誤頁面說：「if your organization has a sharp increase in usage, you might see 429 errors because of acceleration limits on the API.」它的建議是「increase your traffic gradually and maintain consistent usage patterns.」一個同時展開許多 subagent 的 Claude Code 工作流程，正好就會送出這種尖峰。對於使用 claude.ai 方案的人，Anthropic 並未公布節流背後的數字。

Claude 的 too many requests 錯誤會持續多久？

Claude 的節流通常在幾秒到幾分鐘內解除。Claude Code 會以指數退避重試暫時性的 429，最多 10 次，等待期間會顯示 Retrying in Ns · attempt x/y。只有這些重試都用完，你才會看到錯誤。

有些回報持續得久得多。5 月 30 日的提報者說這持續了「two days」，而且開新的工作階段後，只能工作「3 hours at least」它就又回來了。一份 6 月 15 日的回報說，在 Opus 4.8 上節流已持續「for the last 24 hours」。在 5 月的討論串裡，開新的工作階段並換一個模型，讓大家又能繼續工作。如果只開一個工作階段，一小時後仍然存在，那就不是你能修的問題。

對於你不在時仍要執行的工作，Claude Code 有一個開關。設定 CLAUDE_CODE_RETRY_WATCHDOG=1，它會無限期重試 429 和 529 錯誤。可以用 CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS 限制等待時間，例如 3600000 代表一小時。如果腳本應該快速失敗，則改設 CLAUDE_CODE_MAX_RETRIES=2。

付費升級 Claude Max 就不會再 too many requests 嗎？

不會。這個節流「unrelated to your plan quota」，而上面的回報都來自 Pro 和 Max 訂閱者。依 Anthropic 的價格頁面，截至 2026 年 11 月，Claude 的 Pro 是每月 $20，Max 是 $100，Ultra 是 $200。Max 列有「Priority access at high traffic times」。Anthropic 沒有說明這是否涵蓋這種節流。

發布這篇文章的 Whizi 也有同類的防護，而且把數字公開：每位使用者每分鐘 10 則聊天訊息、每小時 60 則，所有方案一樣。它的每分鐘錯誤訊息是「Too many requests. Please wait and try again.」，被拒絕的請求不會消耗你的額度（Whizi 速率限制）。Whizi 輸的地方是：每小時 60 則是硬性上限，而 Claude Max 完全沒有公布每小時的數字。

Claude API 的 429 rate_limit_error 該怎麼修復？

重試之前，請先讀錯誤內容，因為 Claude API 會為不只一種問題送出 429 rate_limit_error。Anthropic 的錯誤頁面說你的組織「has hit a rate limit, reached its usage tier's monthly spend cap, or reached a spend limit on the Claude Code workspace.」其中只有部分會隨時間解除。

有兩個細節容易讓人踩雷。第一，你自己設定的支出上限不是 429，而是 400 invalid_request_error，開頭是「You have reached your specified API usage limits」。第二，支出上限為 Start 每月 $500、Build $1,000、Scale $200,000。到達上限時，「API usage pauses until 00:00 UTC on the first day of the next month」，連 SDK 的自動重試也會一直失敗到那時候。

這些限制屬於你的整個組織，而不是單一金鑰。截至 2026 年 11 月，在 Start 層級上，Claude Opus 5.5、Sonnet 5.5 和 Haiku 5.5 各有每分鐘 4,000 次請求和每分鐘 2,000,000 個輸入 token。新的組織可能從更低的 Evaluation 層級起步。在大多數模型上，從快取讀取的 token 不計入每分鐘輸入 token，所以提示快取（prompt caching）會拉高你實際的上限。官方 SDK 預設會重試 429 兩次，並遵守 retry-after。請留意每個回應中的 anthropic-ratelimit-requests-remaining 標頭，在它歸零之前就放慢速度。