Claude API 限額上調：Start、Build、Scale 新分層該怎麼看

Mon, 29 Jun 2026 05:04:40 +0800

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 也更好懂了。對開發者來說，真正的動作不是「放心猛衝」，而是趁著限額變寬，把自己的呼叫鏈、監控和重試策略整理清楚。這樣限額上調帶來的餘量，才會變成穩定性，而不是更快撞到下一堵牆。

速率限制 on KnightLi的博客