我們有兩種類型的限制:

  1. 消費限制設定組織在 API 使用上可能產生的最大月費用。
  2. 速率限制設定組織在特定時間段內可以發出的最大 API 請求數量。

我們在組織層級強制執行服務配置的限制,但您也可以為組織的工作區設定使用者可配置的限制。

這些限制適用於標準層級和優先層級的使用。有關優先層級的更多信息(該層級提供增強的服務水平以換取承諾消費),請參閱服務層級

關於我們的限制

  • 限制旨在防止 API 濫用,同時最小化對常見客戶使用模式的影響。
  • 限制由使用層級定義,每個層級都與一組不同的消費和速率限制相關聯。
  • 當您在使用 API 時達到某些閾值,您的組織將自動提升層級。 限制設定在組織層級。您可以在 Anthropic 控制台限制頁面中查看您組織的限制。
  • 您可能會在較短的時間間隔內達到速率限制。例如,每分鐘 60 個請求 (RPM) 的速率可能會被強制執行為每秒 1 個請求。短時間內大量的請求可能會超過速率限制並導致速率限制錯誤。
  • 下面概述的限制是我們的標準層級限制。如果您正在尋求更高的自定義限制或優先層級以獲得增強的服務水平,請通過 Anthropic 控制台聯繫銷售團隊。
  • 我們使用令牌桶算法進行速率限制。這意味著您的容量會持續補充到最大限制,而不是在固定間隔重置。
  • 這裡描述的所有限制代表最大允許使用量,而非保證的最低限制。這些限制旨在減少無意的超支並確保資源在用戶之間公平分配。

消費限制

每個使用層級對您每個日曆月在 API 上的消費有限制。一旦您達到您層級的消費限制,在您符合下一層級資格之前,您將需要等到下個月才能再次使用 API。

要符合下一層級的資格,您必須滿足存款要求。為了最小化超額資金的風險,您不能存入超過您每月消費限制的金額。

提升層級的要求

使用層級信用購買每月最大使用量
第 1 層$5$100
第 2 層$40$500
第 3 層$200$1,000
第 4 層$400$5,000
月度發票不適用不適用

速率限制

我們對 Messages API 的速率限制以每分鐘請求數 (RPM)、每分鐘輸入令牌數 (ITPM) 和每分鐘輸出令牌數 (OTPM) 來衡量,適用於每個模型類別。 如果您超過任何速率限制,您將收到一個描述超過了哪個速率限制的 429 錯誤,以及一個 retry-after 標頭,指示需要等待多長時間。

ITPM 速率限制在每個請求開始時進行估計,並在請求期間調整估計值以反映實際使用的輸入令牌數量。 最終調整將 input_tokenscache_creation_input_tokens 計入 ITPM 速率限制,而 cache_read_input_tokens 則不計入(儘管仍會計費)。 在某些情況下,cache_read_input_tokens 會計入 ITPM 速率限制。

OTPM 速率限制在每個請求開始時根據 max_tokens 進行估計,並在請求結束時調整估計值以反映實際使用的輸出令牌數量。 如果您比預期更早達到 OTPM 限制,請嘗試減少 max_tokens 以更好地近似您的完成大小。

速率限制分別應用於每個模型;因此,您可以同時使用不同的模型,每個模型都可以達到其各自的限制。 您可以在 Anthropic 控制台中檢查您當前的速率限制和行為。

模型每分鐘最大請求數 (RPM)每分鐘最大輸入令牌數 (ITPM)每分鐘最大輸出令牌數 (OTPM)
Claude Opus 45020,0008,000
Claude Sonnet 45020,0008,000
Claude Sonnet 3.75020,0008,000
Claude Sonnet 3.5
2024-10-22
5040,000*8,000
Claude Sonnet 3.5
2024-06-20
5040,000*8,000
Claude Haiku 3.55050,000*10,000
Claude Opus 35020,000*4,000
Claude Sonnet 35040,000*8,000
Claude Haiku 35050,000*10,000

標有星號 (*) 的限制將 cache_read_input_tokens 計入 ITPM 使用量。

Message Batches API

Message Batches API 有自己的一組速率限制,這些限制在所有模型之間共享。這些限制包括對所有 API 端點的每分鐘請求數 (RPM) 限制,以及同時在處理隊列中的批次請求數量限制。這裡的「批次請求」指的是 Message Batch 的一部分。您可以創建包含數千個批次請求的 Message Batch,每個批次請求都計入此限制。當批次請求尚未被模型成功處理時,它被視為處理隊列的一部分。

每分鐘最大請求數 (RPM)處理隊列中的最大批次請求數每批次的最大批次請求數
50100,000100,000

為工作區設置較低的限制

為了保護您組織中的工作區免受潛在過度使用的影響,您可以為每個工作區設置自定義消費和速率限制。

例如:如果您組織的限制是每分鐘 40,000 個輸入令牌和每分鐘 8,000 個輸出令牌,您可能會將一個工作區限制為每分鐘 30,000 個總令牌。這可以保護其他工作區免受潛在過度使用的影響,並確保資源在您的組織中更公平地分配。剩餘未使用的每分鐘令牌數(或更多,如果該工作區未使用限制)則可供其他工作區使用。

注意:

  • 您不能對默認工作區設置限制。
  • 如果未設置,工作區限制與組織的限制相匹配。
  • 即使工作區限制加起來更多,組織範圍的限制始終適用。
  • 未來將為工作區添加對輸入和輸出令牌限制的支持。

響應標頭

API 響應包括顯示強制執行的速率限制、當前使用情況以及何時重置限制的標頭。

返回以下標頭:

標頭描述
retry-after在您可以重試請求之前需要等待的秒數。更早的重試將失敗。
anthropic-ratelimit-requests-limit在任何速率限制期間內允許的最大請求數。
anthropic-ratelimit-requests-remaining在被速率限制之前剩餘的請求數。
anthropic-ratelimit-requests-reset請求速率限制將完全補充的時間,以 RFC 3339 格式提供。
anthropic-ratelimit-tokens-limit在任何速率限制期間內允許的最大令牌數。
anthropic-ratelimit-tokens-remaining在被速率限制之前剩餘的令牌數(四捨五入到最接近的千)。
anthropic-ratelimit-tokens-reset令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。
anthropic-ratelimit-input-tokens-limit在任何速率限制期間內允許的最大輸入令牌數。
anthropic-ratelimit-input-tokens-remaining在被速率限制之前剩餘的輸入令牌數(四捨五入到最接近的千)。
anthropic-ratelimit-input-tokens-reset輸入令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。
anthropic-ratelimit-output-tokens-limit在任何速率限制期間內允許的最大輸出令牌數。
anthropic-ratelimit-output-tokens-remaining在被速率限制之前剩餘的輸出令牌數(四捨五入到最接近的千)。
anthropic-ratelimit-output-tokens-reset輸出令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。
anthropic-priority-input-tokens-limit在任何速率限制期間內允許的最大優先層級輸入令牌數。(僅限優先層級)
anthropic-priority-input-tokens-remaining在被速率限制之前剩餘的優先層級輸入令牌數(四捨五入到最接近的千)。(僅限優先層級)
anthropic-priority-input-tokens-reset優先層級輸入令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。(僅限優先層級)
anthropic-priority-output-tokens-limit在任何速率限制期間內允許的最大優先層級輸出令牌數。(僅限優先層級)
anthropic-priority-output-tokens-remaining在被速率限制之前剩餘的優先層級輸出令牌數(四捨五入到最接近的千)。(僅限優先層級)
anthropic-priority-output-tokens-reset優先層級輸出令牌速率限制將完全補充的時間,以 RFC 3339 格式提供。(僅限優先層級)

anthropic-ratelimit-tokens-* 標頭顯示當前生效的最嚴格限制的值。例如,如果您已超過工作區每分鐘令牌限制,標頭將包含工作區每分鐘令牌速率限制值。如果工作區限制不適用,標頭將返回剩餘的總令牌數,其中總數是輸入和輸出令牌的總和。這種方法確保您能夠了解當前 API 使用的最相關限制。