Ratenbegrenzungen
Um Missbrauch zu verhindern und die Kapazität unserer API zu verwalten, haben wir Begrenzungen dafür eingeführt, wie viel eine Organisation die Claude API nutzen kann.
Wir haben zwei Arten von Begrenzungen:
- Ausgabenlimits legen einen maximalen monatlichen Betrag fest, den eine Organisation für die API-Nutzung aufwenden kann.
- Ratenbegrenzungen legen die maximale Anzahl von API-Anfragen fest, die eine Organisation über einen definierten Zeitraum stellen kann.
Wir setzen dienstlich konfigurierte Limits auf Organisationsebene durch, aber Sie können auch benutzerkonfigurierbare Limits für die Workspaces Ihrer Organisation festlegen.
Diese Limits gelten sowohl für die Standard- als auch für die Priority-Tier-Nutzung. Weitere Informationen über Priority Tier, das verbesserte Servicelevel im Austausch für zugesicherte Ausgaben bietet, finden Sie unter Service Tiers.
Über unsere Begrenzungen
- Die Limits sind so konzipiert, dass sie API-Missbrauch verhindern und gleichzeitig die Auswirkungen auf übliche Kundennutzungsmuster minimieren.
- Die Limits werden durch Nutzungsstufen definiert, wobei jede Stufe mit unterschiedlichen Ausgaben- und Ratenlimits verbunden ist.
- Ihre Organisation steigt automatisch in höhere Stufen auf, wenn Sie bei der Nutzung der API bestimmte Schwellenwerte erreichen. Die Limits werden auf Organisationsebene festgelegt. Sie können die Limits Ihrer Organisation auf der Limits-Seite in der Anthropic Console einsehen.
- Sie können Ratenbegrenzungen über kürzere Zeitintervalle erreichen. Beispielsweise kann eine Rate von 60 Anfragen pro Minute (RPM) als 1 Anfrage pro Sekunde durchgesetzt werden. Kurze Bursts von Anfragen mit hohem Volumen können die Ratenbegrenzung überschreiten und zu Ratenbegrenzungsfehlern führen.
- Die unten beschriebenen Limits sind unsere Standard-Tier-Limits. Wenn Sie höhere, individuelle Limits oder Priority Tier für verbesserte Servicelevel suchen, kontaktieren Sie den Vertrieb über die Anthropic Console.
- Wir verwenden den Token-Bucket-Algorithmus für die Ratenbegrenzung. Das bedeutet, dass Ihre Kapazität kontinuierlich bis zu Ihrem maximalen Limit aufgefüllt wird, anstatt in festen Intervallen zurückgesetzt zu werden.
- Alle hier beschriebenen Limits stellen die maximal zulässige Nutzung dar, nicht garantierte Mindestwerte. Diese Limits sollen unbeabsichtigte Überausgaben reduzieren und eine faire Verteilung der Ressourcen unter den Nutzern sicherstellen.
Ausgabenlimits
Jede Nutzungsstufe hat ein Limit dafür, wie viel Sie jeden Kalendermonat für die API ausgeben können. Sobald Sie das Ausgabenlimit Ihrer Stufe erreicht haben, müssen Sie bis zum nächsten Monat warten, um die API wieder nutzen zu können, es sei denn, Sie qualifizieren sich für die nächste Stufe.
Um sich für die nächste Stufe zu qualifizieren, müssen Sie eine Einzahlungsanforderung erfüllen. Um das Risiko einer Überfinanzierung Ihres Kontos zu minimieren, können Sie nicht mehr als Ihr monatliches Ausgabenlimit einzahlen.
Anforderungen für den Stufenaufstieg
Nutzungsstufe | Kreditkauf | Max. Nutzung pro Monat |
---|---|---|
Stufe 1 | $5 | $100 |
Stufe 2 | $40 | $500 |
Stufe 3 | $200 | $1.000 |
Stufe 4 | $400 | $5.000 |
Monatliche Rechnungsstellung | N/A | N/A |
Ratenbegrenzungen
Unsere Ratenbegrenzungen für die Messages API werden in Anfragen pro Minute (RPM), Eingabe-Tokens pro Minute (ITPM) und Ausgabe-Tokens pro Minute (OTPM) für jede Modellklasse gemessen.
Wenn Sie eine der Ratenbegrenzungen überschreiten, erhalten Sie einen 429-Fehler, der beschreibt, welche Ratenbegrenzung überschritten wurde, zusammen mit einem retry-after
-Header, der angibt, wie lange Sie warten sollten.
ITPM-Ratenbegrenzungen werden zu Beginn jeder Anfrage geschätzt, und die Schätzung wird während der Anfrage angepasst, um die tatsächliche Anzahl der verwendeten Eingabe-Tokens widerzuspiegeln.
Die endgültige Anpassung zählt input_tokens
und cache_creation_input_tokens
zu den ITPM-Ratenbegrenzungen, während cache_read_input_tokens
nicht gezählt werden (obwohl sie trotzdem in Rechnung gestellt werden).
In einigen Fällen werden cache_read_input_tokens
zu den ITPM-Ratenbegrenzungen gezählt.
OTPM-Ratenbegrenzungen werden zu Beginn jeder Anfrage basierend auf max_tokens
geschätzt, und die Schätzung wird am Ende der Anfrage angepasst, um die tatsächliche Anzahl der verwendeten Ausgabe-Tokens widerzuspiegeln.
Wenn Sie früher als erwartet auf OTPM-Limits stoßen, versuchen Sie, max_tokens
zu reduzieren, um die Größe Ihrer Vervollständigungen besser abzuschätzen.
Ratenbegrenzungen werden für jedes Modell separat angewendet; daher können Sie verschiedene Modelle bis zu ihren jeweiligen Limits gleichzeitig verwenden. Sie können Ihre aktuellen Ratenbegrenzungen und Verhalten in der Anthropic Console überprüfen.
Modell | Maximale Anfragen pro Minute (RPM) | Maximale Eingabe-Tokens pro Minute (ITPM) | Maximale Ausgabe-Tokens pro Minute (OTPM) |
---|---|---|---|
Claude Opus 4 | 50 | 20.000 | 8.000 |
Claude Sonnet 4 | 50 | 20.000 | 8.000 |
Claude Sonnet 3.7 | 50 | 20.000 | 8.000 |
Claude Sonnet 3.5 2024-10-22 | 50 | 40.000* | 8.000 |
Claude Sonnet 3.5 2024-06-20 | 50 | 40.000* | 8.000 |
Claude Haiku 3.5 | 50 | 50.000* | 10.000 |
Claude Opus 3 | 50 | 20.000* | 4.000 |
Claude Sonnet 3 | 50 | 40.000* | 8.000 |
Claude Haiku 3 | 50 | 50.000* | 10.000 |
Limits mit Sternchen (*) zählen cache_read_input_tokens
zur ITPM-Nutzung.
Modell | Maximale Anfragen pro Minute (RPM) | Maximale Eingabe-Tokens pro Minute (ITPM) | Maximale Ausgabe-Tokens pro Minute (OTPM) |
---|---|---|---|
Claude Opus 4 | 50 | 20.000 | 8.000 |
Claude Sonnet 4 | 50 | 20.000 | 8.000 |
Claude Sonnet 3.7 | 50 | 20.000 | 8.000 |
Claude Sonnet 3.5 2024-10-22 | 50 | 40.000* | 8.000 |
Claude Sonnet 3.5 2024-06-20 | 50 | 40.000* | 8.000 |
Claude Haiku 3.5 | 50 | 50.000* | 10.000 |
Claude Opus 3 | 50 | 20.000* | 4.000 |
Claude Sonnet 3 | 50 | 40.000* | 8.000 |
Claude Haiku 3 | 50 | 50.000* | 10.000 |
Limits mit Sternchen (*) zählen cache_read_input_tokens
zur ITPM-Nutzung.
Modell | Maximale Anfragen pro Minute (RPM) | Maximale Eingabe-Tokens pro Minute (ITPM) | Maximale Ausgabe-Tokens pro Minute (OTPM) |
---|---|---|---|
Claude Opus 4 | 1.000 | 40.000 | 16.000 |
Claude Sonnet 4 | 1.000 | 40.000 | 16.000 |
Claude Sonnet 3.7 | 1.000 | 40.000 | 16.000 |
Claude Sonnet 3.5 2024-10-22 | 1.000 | 80.000* | 16.000 |
Claude Sonnet 3.5 2024-06-20 | 1.000 | 80.000* | 16.000 |
Claude Haiku 3.5 | 1.000 | 100.000* | 20.000 |
Claude Opus 3 | 1.000 | 40.000* | 8.000 |
Claude Sonnet 3 | 1.000 | 80.000* | 16.000 |
Claude Haiku 3 | 1.000 | 100.000* | 20.000 |
Limits mit Sternchen (*) zählen cache_read_input_tokens
zur ITPM-Nutzung.
Modell | Maximale Anfragen pro Minute (RPM) | Maximale Eingabe-Tokens pro Minute (ITPM) | Maximale Ausgabe-Tokens pro Minute (OTPM) |
---|---|---|---|
Claude Opus 4 | 2.000 | 80.000 | 32.000 |
Claude Sonnet 4 | 2.000 | 80.000 | 32.000 |
Claude Sonnet 3.7 | 2.000 | 80.000 | 32.000 |
Claude Sonnet 3.5 2024-10-22 | 2.000 | 160.000* | 32.000 |
Claude Sonnet 3.5 2024-06-20 | 2.000 | 160.000* | 32.000 |
Claude Haiku 3.5 | 2.000 | 200.000* | 40.000 |
Claude Opus 3 | 2.000 | 80.000* | 16.000 |
Claude Sonnet 3 | 2.000 | 160.000* | 32.000 |
Claude Haiku 3 | 2.000 | 200.000* | 40.000 |
Limits mit Sternchen (*) zählen cache_read_input_tokens
zur ITPM-Nutzung.
Modell | Maximale Anfragen pro Minute (RPM) | Maximale Eingabe-Tokens pro Minute (ITPM) | Maximale Ausgabe-Tokens pro Minute (OTPM) |
---|---|---|---|
Claude Opus 4 | 4.000 | 200.000 | 80.000 |
Claude Sonnet 4 | 4.000 | 200.000 | 80.000 |
Claude Sonnet 3.7 | 4.000 | 200.000 | 80.000 |
Claude Sonnet 3.5 2024-10-22 | 4.000 | 400.000* | 80.000 |
Claude Sonnet 3.5 2024-06-20 | 4.000 | 400.000* | 80.000 |
Claude Haiku 3.5 | 4.000 | 400.000* | 80.000 |
Claude Opus 3 | 4.000 | 400.000* | 80.000 |
Claude Sonnet 3 | 4.000 | 400.000* | 80.000 |
Claude Haiku 3 | 4.000 | 400.000* | 80.000 |
Limits mit Sternchen (*) zählen cache_read_input_tokens
zur ITPM-Nutzung.
Wenn Sie höhere Limits für einen Enterprise-Anwendungsfall suchen, kontaktieren Sie den Vertrieb über die Anthropic Console.
Message Batches API
Die Message Batches API hat ihre eigenen Ratenbegrenzungen, die über alle Modelle hinweg geteilt werden. Dazu gehören eine Begrenzung der Anfragen pro Minute (RPM) für alle API-Endpunkte und eine Begrenzung der Anzahl von Batch-Anfragen, die gleichzeitig in der Verarbeitungswarteschlange sein können. Eine “Batch-Anfrage” bezieht sich hier auf einen Teil eines Message Batch. Sie können einen Message Batch erstellen, der Tausende von Batch-Anfragen enthält, von denen jede zu diesem Limit zählt. Eine Batch-Anfrage gilt als Teil der Verarbeitungswarteschlange, wenn sie noch nicht erfolgreich vom Modell verarbeitet wurde.
Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
---|---|---|
50 | 100.000 | 100.000 |
Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
---|---|---|
50 | 100.000 | 100.000 |
Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
---|---|---|
1.000 | 200.000 | 100.000 |
Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
---|---|---|
2.000 | 300.000 | 100.000 |
Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
---|---|---|
4.000 | 500.000 | 100.000 |
Wenn Sie höhere Limits für einen Enterprise-Anwendungsfall suchen, kontaktieren Sie den Vertrieb über die Anthropic Console.
Festlegen niedrigerer Limits für Workspaces
Um Workspaces in Ihrer Organisation vor potenzieller Übernutzung zu schützen, können Sie benutzerdefinierte Ausgaben- und Ratenlimits pro Workspace festlegen.
Beispiel: Wenn das Limit Ihrer Organisation 40.000 Eingabe-Tokens pro Minute und 8.000 Ausgabe-Tokens pro Minute beträgt, könnten Sie einen Workspace auf insgesamt 30.000 Tokens pro Minute begrenzen. Dies schützt andere Workspaces vor potenzieller Übernutzung und sorgt für eine gerechtere Verteilung der Ressourcen in Ihrer Organisation. Die verbleibenden ungenutzten Tokens pro Minute (oder mehr, wenn dieser Workspace das Limit nicht ausschöpft) stehen dann anderen Workspaces zur Verfügung.
Hinweis:
- Sie können keine Limits für den Standard-Workspace festlegen.
- Wenn nicht festgelegt, entsprechen die Workspace-Limits dem Limit der Organisation.
- Organisationsweite Limits gelten immer, auch wenn die Summe der Workspace-Limits höher ist.
- Die Unterstützung für Eingabe- und Ausgabe-Token-Limits wird in Zukunft zu Workspaces hinzugefügt.
Antwort-Header
Die API-Antwort enthält Header, die Ihnen die durchgesetzte Ratenbegrenzung, die aktuelle Nutzung und den Zeitpunkt der Zurücksetzung des Limits anzeigen.
Die folgenden Header werden zurückgegeben:
Header | Beschreibung |
---|---|
retry-after | Die Anzahl der Sekunden, die Sie warten müssen, bis Sie die Anfrage wiederholen können. Frühere Wiederholungen werden fehlschlagen. |
anthropic-ratelimit-requests-limit | Die maximale Anzahl von Anfragen, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. |
anthropic-ratelimit-requests-remaining | Die Anzahl der verbleibenden Anfragen, bevor die Ratenbegrenzung greift. |
anthropic-ratelimit-requests-reset | Der Zeitpunkt, zu dem die Anfrage-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-tokens-limit | Die maximale Anzahl von Tokens, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. |
anthropic-ratelimit-tokens-remaining | Die Anzahl der verbleibenden Tokens (auf das nächste Tausend gerundet), bevor die Ratenbegrenzung greift. |
anthropic-ratelimit-tokens-reset | Der Zeitpunkt, zu dem die Token-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-input-tokens-limit | Die maximale Anzahl von Eingabe-Tokens, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. |
anthropic-ratelimit-input-tokens-remaining | Die Anzahl der verbleibenden Eingabe-Tokens (auf das nächste Tausend gerundet), bevor die Ratenbegrenzung greift. |
anthropic-ratelimit-input-tokens-reset | Der Zeitpunkt, zu dem die Eingabe-Token-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-output-tokens-limit | Die maximale Anzahl von Ausgabe-Tokens, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. |
anthropic-ratelimit-output-tokens-remaining | Die Anzahl der verbleibenden Ausgabe-Tokens (auf das nächste Tausend gerundet), bevor die Ratenbegrenzung greift. |
anthropic-ratelimit-output-tokens-reset | Der Zeitpunkt, zu dem die Ausgabe-Token-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-priority-input-tokens-limit | Die maximale Anzahl von Priority-Tier-Eingabe-Tokens, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. (Nur Priority Tier) |
anthropic-priority-input-tokens-remaining | Die Anzahl der verbleibenden Priority-Tier-Eingabe-Tokens (auf das nächste Tausend gerundet), bevor die Ratenbegrenzung greift. (Nur Priority Tier) |
anthropic-priority-input-tokens-reset | Der Zeitpunkt, zu dem die Priority-Tier-Eingabe-Token-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. (Nur Priority Tier) |
anthropic-priority-output-tokens-limit | Die maximale Anzahl von Priority-Tier-Ausgabe-Tokens, die innerhalb eines Ratenbegrenzungszeitraums erlaubt sind. (Nur Priority Tier) |
anthropic-priority-output-tokens-remaining | Die Anzahl der verbleibenden Priority-Tier-Ausgabe-Tokens (auf das nächste Tausend gerundet), bevor die Ratenbegrenzung greift. (Nur Priority Tier) |
anthropic-priority-output-tokens-reset | Der Zeitpunkt, zu dem die Priority-Tier-Ausgabe-Token-Ratenbegrenzung vollständig aufgefüllt wird, im RFC 3339-Format. (Nur Priority Tier) |
Die anthropic-ratelimit-tokens-*
-Header zeigen die Werte für das derzeit geltende restriktivste Limit an. Wenn Sie beispielsweise das Token-Limit pro Minute für den Workspace überschritten haben, enthalten die Header die Werte für das Token-Ratenlimit pro Minute für den Workspace. Wenn Workspace-Limits nicht gelten, geben die Header die verbleibenden Tokens insgesamt zurück, wobei die Gesamtzahl die Summe aus Eingabe- und Ausgabe-Tokens ist. Dieser Ansatz stellt sicher, dass Sie Einblick in die relevanteste Einschränkung Ihrer aktuellen API-Nutzung haben.