Nutzungsbeschränkungen
Um Missbrauch zu verhindern und die Kapazität unserer API zu verwalten, haben wir Beschränkungen für die Nutzung der Claude API durch Organisationen eingeführt.
Wir haben zwei Arten von Beschränkungen:
- Ausgabenlimits legen die maximalen monatlichen Kosten fest, die einer Organisation für die API-Nutzung entstehen können.
- Nutzungslimits legen die maximale Anzahl von API-Anfragen fest, die eine Organisation über einen definierten Zeitraum stellen kann.
Wir setzen dienstbasierte Beschränkungen auf Organisationsebene durch, aber Sie können auch benutzerdefinierte Beschränkungen für die Workspaces Ihrer Organisation festlegen.
Über unsere Beschränkungen
- Die Beschränkungen sind so konzipiert, dass sie API-Missbrauch verhindern und gleichzeitig die Auswirkungen auf übliche Kundennutzungsmuster minimieren.
- Die Beschränkungen werden durch Nutzungsstufen definiert, wobei jede Stufe mit unterschiedlichen Ausgaben- und Nutzungslimits verbunden ist.
- Ihre Organisation steigt automatisch in höhere Stufen auf, wenn Sie bestimmte Schwellenwerte bei der API-Nutzung erreichen. Die Beschränkungen werden auf Organisationsebene festgelegt. Sie können die Beschränkungen Ihrer Organisation auf der Limits-Seite in der Anthropic Console einsehen.
- Sie können bei kürzeren Zeitintervallen an Nutzungslimits stoßen. Beispielsweise können 60 Anfragen pro Minute (RPM) als 1 Anfrage pro Sekunde durchgesetzt werden. Kurze Bursts von Anfragen mit hohem Volumen können das Nutzungslimit überschreiten und zu Fehlermeldungen führen.
- Die unten aufgeführten Beschränkungen sind unsere Standardlimits. Wenn Sie höhere, individuelle Limits benötigen, kontaktieren Sie den Vertrieb über die Anthropic Console.
- Wir verwenden den Token-Bucket-Algorithmus für die Nutzungsbeschränkung. 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 Beschränkungen stellen maximale erlaubte Nutzungen dar, keine garantierten Mindestwerte. Diese Beschränkungen sollen Übernutzung verhindern und eine faire Verteilung der Ressourcen unter den Nutzern gewährleisten.
Ausgabenlimits
Jede Nutzungsstufe hat eine Beschränkung für die Höhe der Ausgaben für die API pro Kalendermonat. Sobald Sie das Ausgabenlimit Ihrer Stufe erreichen, 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 und eine obligatorische Wartezeit einhalten. Höhere Stufen erfordern längere Wartezeiten. Beachten Sie, dass Sie zur Minimierung des Risikos einer Überfinanzierung Ihres Kontos nicht mehr als Ihr monatliches Ausgabenlimit einzahlen können.
Anforderungen für den Stufenaufstieg
| Nutzungsstufe | Kreditkauf | Wartezeit nach erstem Kauf | Max. Nutzung pro Monat |
|---|---|---|---|
| Stufe 1 | $5 | 0 Tage | $100 |
| Stufe 2 | $40 | 7 Tage | $500 |
| Stufe 3 | $200 | 7 Tage | $1.000 |
| Stufe 4 | $400 | 14 Tage | $5.000 |
| Monatliche Abrechnung | N/A | N/A | N/A |
Nutzungslimits
Unsere Nutzungslimits 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 eines der Nutzungslimits überschreiten, erhalten Sie einen 429-Fehler, der beschreibt, welches Limit überschritten wurde, zusammen mit einem retry-after-Header, der angibt, wie lange Sie warten müssen.
ITPM-Nutzungslimits 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-Nutzungslimits, während cache_read_input_tokens nicht gezählt werden (obwohl sie trotzdem berechnet werden).
In einigen Fällen werden cache_read_input_tokens zu den ITPM-Nutzungslimits gezählt.
OTPM-Nutzungslimits werden zu Beginn jeder Anfrage basierend auf max_tokens geschätzt und 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.
Nutzungslimits werden für jedes Modell separat angewendet; daher können Sie verschiedene Modelle bis zu ihren jeweiligen Limits gleichzeitig nutzen. Sie können Ihre aktuellen Nutzungslimits und das 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 3.7 Sonnet | 50 | 20.000 | 8.000 |
| Claude 3.5 Sonnet 2024-10-22 | 50 | 40.000* | 8.000 |
| Claude 3.5 Sonnet 2024-06-20 | 50 | 40.000* | 8.000 |
| Claude 3.5 Haiku | 50 | 50.000* | 10.000 |
| Claude 3 Opus | 50 | 20.000* | 4.000 |
| Claude 3 Sonnet | 50 | 40.000* | 8.000 |
| Claude 3 Haiku | 50 | 50.000* | 10.000 |
Mit Sternchen (*) markierte Limits zählen cache_read_input_tokens zur ITPM-Nutzung.
Message Batches API
Die Message Batches API hat ihre eigenen Nutzungslimits, die über alle Modelle hinweg geteilt werden. Diese umfassen ein Limit für Anfragen pro Minute (RPM) für alle API-Endpunkte und eine Beschränkung 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 mit Tausenden von Batch-Anfragen erstellen, von denen jede auf dieses Limit angerechnet wird. 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 Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
|---|---|---|
| 50 | 100.000 | 100.000 |
Niedrigere Limits für Workspaces festlegen
Um Workspaces in Ihrer Organisation vor potenzieller Übernutzung zu schützen, können Sie benutzerdefinierte Ausgaben- und Nutzungslimits 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 30.000 Tokens pro Minute insgesamt beschränken. Dies schützt andere Workspaces vor potenzieller Übernutzung und gewährleistet 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 das durchgesetzte Nutzungslimit, die aktuelle Nutzung und den Zeitpunkt der Limit-Zurücksetzung 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 erlaubter Anfragen innerhalb einer Nutzungslimit-Periode. |
anthropic-ratelimit-requests-remaining | Die Anzahl der verbleibenden Anfragen vor der Nutzungsbeschränkung. |
anthropic-ratelimit-requests-reset | Der Zeitpunkt, zu dem das Anfragen-Nutzungslimit vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-tokens-limit | Die maximale Anzahl erlaubter Tokens innerhalb einer Nutzungslimit-Periode. |
anthropic-ratelimit-tokens-remaining | Die Anzahl der verbleibenden Tokens (auf Tausend gerundet) vor der Nutzungsbeschränkung. |
anthropic-ratelimit-tokens-reset | Der Zeitpunkt, zu dem das Token-Nutzungslimit vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-input-tokens-limit | Die maximale Anzahl erlaubter Eingabe-Tokens innerhalb einer Nutzungslimit-Periode. |
anthropic-ratelimit-input-tokens-remaining | Die Anzahl der verbleibenden Eingabe-Tokens (auf Tausend gerundet) vor der Nutzungsbeschränkung. |
anthropic-ratelimit-input-tokens-reset | Der Zeitpunkt, zu dem das Eingabe-Token-Nutzungslimit vollständig aufgefüllt wird, im RFC 3339-Format. |
anthropic-ratelimit-output-tokens-limit | Die maximale Anzahl erlaubter Ausgabe-Tokens innerhalb einer Nutzungslimit-Periode. |
anthropic-ratelimit-output-tokens-remaining | Die Anzahl der verbleibenden Ausgabe-Tokens (auf Tausend gerundet) vor der Nutzungsbeschränkung. |
anthropic-ratelimit-output-tokens-reset | Der Zeitpunkt, zu dem das Ausgabe-Token-Nutzungslimit vollständig aufgefüllt wird, im RFC 3339-Format. |
Die anthropic-ratelimit-tokens-* Header zeigen die Werte für das aktuell restriktivste Limit an. Wenn Sie beispielsweise das Workspace-Token-Limit pro Minute überschritten haben, enthalten die Header die Werte des Workspace-Token-Nutzungslimits pro Minute. Wenn keine Workspace-Limits gelten, geben die Header die Gesamtzahl der verbleibenden Tokens 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.
Was this page helpful?