Anthropic 在 2026 年 6 月 26 日更新了 Claude Platform release notes：Claude API 的 rate limits 上調，Claude Sonnet 和 Claude Haiku 的限額現在會在各個 usage tier 上對齊 Claude Opus；原來的 usage tiers 也被合併成三個更簡單的層級：Start、Build、Scale。
官方說法是：大多數組織會進入更高層級，沒有組織會拿到比以前更低的限額，也不需要開發者手動操作。你可以在 Claude Console 裡查看自己的 tier 和目前 limits。
發布說明：
https://platform.claude.com/docs/en/release-notes/overview
Rate limits 文件：
https://platform.claude.com/docs/en/api/rate-limits
Rate Limits API 文件：
https://platform.claude.com/docs/en/api/rate-limits-api
這次更新最重要的點
如果你只是日常用 Claude API 寫腳本、做小工具，可能一時感覺不到變化。但如果你在跑 Claude Code、AI Agent、批次摘要、RAG 問答或後端佇列，這次更新值得看一眼。
變化可以拆成三句話：
- Claude API 的整體限額上調了。
- Sonnet 和 Haiku 的限額，在每個 usage tier 上對齊 Opus。
- usage tiers 簡化為
Start、Build、Scale。
這代表什麼？過去一些開發者可能會覺得 Opus、Sonnet、Haiku 的限額口徑不太一樣，做模型切換時要額外檢查。現在分層和模型限額更容易理解，對多模型應用、Agent 產品和內部平台會友好一些。
但這不等於可以隨便開並發。Claude API 仍然會按請求數、輸入 token、輸出 token 和流量成長速度限制請求。
為什麼這條新聞對開發者有用
很多人接 Claude API，真正卡住的不是「模型會不會回答」，而是上線後突然遇到 429。
典型場景包括：
- 本地腳本一次性丟幾百個檔案給 Claude 摘要。
- Agent 應用同時開很多工具呼叫和長上下文請求。
- RAG 系統把檢索結果、歷史對話和系統提示詞一起塞進 prompt。
- 後端佇列消費太快，幾分鐘內把 token 打滿。
- 失敗後自動重試，越重試越壅塞。
這次 Anthropic 上調限額，確實能讓一部分任務跑得更順。但只要你的應用會放大請求，還是要認真處理 rate limit。限額提高是好消息，限流、排隊和重試策略仍然不能省。
Start、Build、Scale 怎麼理解
新的 usage tiers 變成三個層級：
| 層級 | 更像適合誰 |
|---|---|
Start |
個人開發者、小腳本、早期原型 |
Build |
已經有穩定呼叫量的應用、團隊內部工具 |
Scale |
生產業務、高並發 Agent、批次處理和企業級整合 |
具體額度不要照搬文章裡的數字，應該以 Claude Console 和官方文件為準。Anthropic 的限額會根據帳戶、組織、workspace、模型和產品策略變化。
更接地氣地說：如果你只是偶爾寫腳本，重點是別把並發開太大；如果你在做一個真實產品，重點是把 Claude 當成一個需要容量規劃的外部服務，而不是普通函式呼叫。
還是要看 RPM、ITPM、OTPM
Claude API 的 rate limits 不是只有「每分鐘多少次請求」。文件裡最常見的是三個指標：
| 指標 | 含義 | 容易踩坑的場景 |
|---|---|---|
RPM |
requests per minute，每分鐘請求數 | 小請求太密、並發太高、自動重試太多 |
ITPM |
input tokens per minute，每分鐘輸入 token | prompt 太長、上下文太大、RAG 結果塞太多 |
OTPM |
output tokens per minute，每分鐘輸出 token | max_tokens 給太大、批量生成長文或程式碼 |
很多 429 不是因為請求次數多，而是 token 多。比如每分鐘只發 10 個請求，但每個請求都帶幾十萬 token 的上下文，就可能先撞到 ITPM。反過來，如果 prompt 很短，卻讓模型批量輸出長報告，就可能先撞到 OTPM。
所以排查時不要只看 API 呼叫次數。至少要記錄模型名、workspace、輸入 token、輸出 token、回應狀態和重試次數。
Agent 和批次處理更容易吃到紅利
這次限額上調，對普通聊天請求當然有幫助，但更明顯的受益者應該是 Agent 和批次處理任務。
因為 Agent 的一次「使用者請求」背後，可能不是一次 Claude API 呼叫，而是一串呼叫：
- 讀檔案。
- 摘要上下文。
- 呼叫工具。
- 看工具結果。
- 再規劃下一步。
- 最後輸出結果。
如果多個使用者同時使用，或者後端還在跑批次任務，token 很快就會上去。限額上調後，這類任務的餘量會更大，模型切換也更順。但生產環境仍然建議分通道：線上請求走低延遲通道，批次處理走佇列，長任務單獨限並發。
429 不要只怪模型
遇到 429，先別急著換模型，也別直接把重試次數拉滿。更實用的排查順序是：
- 看錯誤訊息，確認是 rate limit、quota 還是其他限制。
- 看回應標頭裡的 limit、remaining、reset 等欄位。
- 統計最近一分鐘的
RPM、ITPM、OTPM。 - 看是否有前端、後端、佇列、SDK 同時重試。
- 看後端任務是否和使用者請求共用同一個組織或 workspace。
- 看最近是否突然放量，觸發了 acceleration limits。
Anthropic 文件裡也提到，短時間流量突然上升可能觸發 acceleration limits。也就是說，即使平均請求量看起來沒那麼誇張，只要成長太猛，也可能被限。
上線新功能時，最好逐步放量。比如先給 5% 使用者開，再看 429、延遲、token 消耗和成本曲線，而不是一次性把所有流量打到 Claude API。
Rate Limits API 可以接到監控裡
Anthropic 還提供 Rate Limits API，用來查詢組織和 workspace 的限額配置。這個接口適合接到內部監控、管理後台或維運腳本裡。
它的用處主要有幾個：
- 部署前確認目前 workspace 的限額。
- 給不同業務線展示可用容量。
- 解釋為什麼測試環境能跑、生產環境會
429。 - 根據目前限制調整佇列並發。
- 做容量告警，而不是等使用者報錯。
但它不應該替代應用自己的限流。業務程式碼裡仍然要有佇列、並發上限、指數退避和最大重試次數。
現在應該怎麼改自己的程式碼
如果你已經在用 Claude API，可以先做幾件很實際的事：
- 去 Claude Console 看自己的 tier 是否已經變成
Start、Build或Scale。 - 確認常用模型的目前 rate limits，不要靠舊截圖或舊文件記憶。
- 把並發數、每分鐘請求數和最大輸出 token 做成配置項。
- 給批次處理任務加佇列，不要直接
for迴圈猛打 API。 - 對
429做指數退避，並限制最大重試次數。 - 記錄輸入 token、輸出 token、模型名、workspace 和請求耗時。
- 如果有長上下文重複使用，評估 prompt caching，但別把快取當成完全不占限額。
這次更新是一個明確利好：Claude API 的容量更寬了，usage tier 也更好懂了。對開發者來說，真正的動作不是「放心猛衝」，而是趁著限額變寬，把自己的呼叫鏈、監控和重試策略整理清楚。這樣限額上調帶來的餘量，才會變成穩定性，而不是更快撞到下一堵牆。