Wir haben zwei Arten von Limits:
  1. Ausgabenlimits legen die maximalen monatlichen Kosten fest, die eine Organisation für die API-Nutzung anfallen können.
  2. Ratenlimits legen die maximale Anzahl von API-Anfragen fest, die eine Organisation über einen definierten Zeitraum hinweg stellen kann.
Wir erzwingen servicekonfigurierte Limits auf Organisationsebene, 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 zu Priority Tier, das verbesserte Servicelevel gegen vereinbarte Ausgaben bietet, finden Sie unter Service Tiers.

​
Über unsere Limits

  • Limits sind so konzipiert, dass sie API-Missbrauch verhindern und gleichzeitig die Auswirkungen auf gängige Kundenutzungsmuster minimieren.
  • Limits werden nach Nutzungsstufe definiert, wobei jede Stufe mit einem anderen Satz von Ausgaben- und Ratenlimits verbunden ist.
  • Ihre Organisation wird automatisch in höhere Stufen aufgestuft, wenn Sie bei der Verwendung der API bestimmte Schwellenwerte erreichen. Limits werden auf Organisationsebene festgelegt. Sie können die Limits Ihrer Organisation auf der Limits-Seite in der Claude Console einsehen.
  • Sie können Ratenlimits über kürzere Zeitintervalle erreichen. Beispielsweise kann eine Rate von 60 Anfragen pro Minute (RPM) als 1 Anfrage pro Sekunde erzwungen werden. Kurze Bursts von Anfragen mit hohem Volumen können das Ratenlimit überschreiten und zu Ratenlimit-Fehlern führen.
  • Die unten beschriebenen Limits sind unsere Standard-Tier-Limits. Wenn Sie höhere, benutzerdefinierte Limits oder Priority Tier für verbesserte Servicelevel anstreben, kontaktieren Sie den Vertrieb über die Claude Console.
  • Wir verwenden den Token-Bucket-Algorithmus für die Ratenbegrenzung. Dies 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, keine garantierten Mindestwerte. Diese Limits sollen unbeabsichtigte Überausgaben reduzieren und eine faire Verteilung der Ressourcen unter den Benutzern gewährleisten.

​
Ausgabenlimits

Jede Nutzungsstufe hat ein Limit für die Ausgaben in der API pro Kalendermonat. Sobald Sie das Ausgabenlimit Ihrer Stufe erreichen, müssen Sie bis zur nächsten Stufe warten, bis der nächste Monat beginnt, um die API erneut nutzen zu können. 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 zum Aufstieg in die nächste Stufe

NutzungsstufeKreditkaufMaximaler Kreditkauf
Stufe 1$5$100
Stufe 2$40$500
Stufe 3$200$1.000
Stufe 4$400$5.000
Monatliche RechnungsstellungN/AN/A
Kreditkauf zeigt die kumulativen Kreditkäufe (ohne Steuern) an, die erforderlich sind, um diese Stufe zu erreichen. Sie werden sofort aufgestuft, wenn Sie den Schwellenwert erreichen.Maximaler Kreditkauf begrenzt den maximalen Betrag, den Sie in einer einzelnen Transaktion zu Ihrem Konto hinzufügen können, um eine Kontoüberfinanzierung zu verhindern.

​
Ratenlimits

Unsere Ratenlimits für die Messages API werden in Anfragen pro Minute (RPM), Eingabe-Token pro Minute (ITPM) und Ausgabe-Token pro Minute (OTPM) für jede Modellklasse gemessen. Wenn Sie eines der Ratenlimits überschreiten, erhalten Sie einen 429-Fehler mit einer Beschreibung, welches Ratenlimit überschritten wurde, zusammen mit einem retry-after-Header, der angibt, wie lange Sie warten sollten.
Sie können auch auf 429-Fehler stoßen, die auf Beschleunigungslimits der API zurückzuführen sind, wenn Ihre Organisation einen starken Anstieg der Nutzung verzeichnet. Um Beschleunigungslimits zu vermeiden, erhöhen Sie Ihren Datenverkehr schrittweise und halten Sie konsistente Nutzungsmuster ein.

​
Cache-bewusste ITPM

Viele API-Anbieter verwenden ein kombiniertes “Token pro Minute” (TPM)-Limit, das alle Token einschließen kann, sowohl gecachte als auch ungecachte, Ein- und Ausgabe. Bei den meisten Claude-Modellen zählen nur ungecachte Eingabe-Token zu Ihren ITPM-Ratenlimits. Dies ist ein großer Vorteil, der unsere Ratenlimits effektiv höher macht, als sie zunächst erscheinen mögen. ITPM-Ratenlimits werden am Anfang jeder Anfrage geschätzt, und die Schätzung wird während der Anfrage angepasst, um die tatsächliche Anzahl der verwendeten Eingabe-Token widerzuspiegeln. Das zählt zu ITPM:
  • input_tokens (neue Eingabe-Token, die nicht gecacht sind) ✓ Zählen zu ITPM
  • cache_creation_input_tokens (Token, die in den Cache geschrieben werden) ✓ Zählen zu ITPM
  • cache_read_input_tokens (Token, die aus dem Cache gelesen werden) ✗ Zählen NICHT zu ITPM bei den meisten Modellen
Beispiel: Mit einem Limit von 2.000.000 ITPM und einer Cache-Hit-Rate von 80% könnten Sie effektiv 10.000.000 Eingabe-Token pro Minute verarbeiten (2 Mio. ungecacht + 8 Mio. gecacht), da gecachte Token nicht zu Ihrem Ratenlimit zählen.
Einige ältere Modelle (gekennzeichnet mit † in den Ratenlimit-Tabellen unten) zählen auch cache_read_input_tokens zu den ITPM-Ratenlimits.Bei allen Modellen ohne das †-Zeichen zählen gecachte Eingabe-Token nicht zu den Ratenlimits und werden zu einem reduzierten Satz abgerechnet (10% des Basis-Eingabe-Token-Preises). Dies bedeutet, dass Sie durch die Verwendung von Prompt Caching einen deutlich höheren effektiven Durchsatz erreichen können.
Maximieren Sie Ihre Ratenlimits mit Prompt CachingUm das Beste aus Ihren Ratenlimits herauszuholen, verwenden Sie Prompt Caching für wiederholte Inhalte wie:
  • Systeminstruktionen und Prompts
  • Große Kontextdokumente
  • Tool-Definitionen
  • Gesprächsverlauf
Mit effektivem Caching können Sie Ihren tatsächlichen Durchsatz dramatisch erhöhen, ohne Ihre Ratenlimits zu erhöhen. Überwachen Sie Ihre Cache-Hit-Rate auf der Nutzungsseite, um Ihre Caching-Strategie zu optimieren.
OTPM-Ratenlimits werden basierend auf max_tokens am Anfang jeder Anfrage geschätzt, und die Schätzung wird am Ende der Anfrage angepasst, um die tatsächliche Anzahl der generierten Ausgabe-Token widerzuspiegeln. Wenn Sie OTPM-Limits früher als erwartet erreichen, versuchen Sie, max_tokens zu reduzieren, um die Größe Ihrer Vervollständigungen besser zu approximieren. Ratenlimits werden separat für jedes Modell angewendet; daher können Sie verschiedene Modelle bis zu ihren jeweiligen Limits gleichzeitig verwenden. Sie können Ihre aktuellen Ratenlimits und das Verhalten in der Claude Console überprüfen.
Für Anfragen mit langem Kontext (>200K Token) bei Verwendung des context-1m-2025-08-07 Beta-Headers mit Claude Sonnet 4.x gelten separate Ratenlimits. Siehe Ratenlimits für langen Kontext unten.
ModellMaximale Anfragen pro Minute (RPM)Maximale Eingabe-Token pro Minute (ITPM)Maximale Ausgabe-Token pro Minute (OTPM)
Claude Sonnet 4.x**5030.0008.000
Claude Sonnet 3.7 (veraltet)5020.0008.000
Claude Haiku 4.55050.00010.000
Claude Haiku 3.55050.000†10.000
Claude Haiku 35050.000†10.000
Claude Opus 4.x*5030.0008.000
Claude Opus 3 (veraltet)5020.000†4.000
* - Das Opus 4.x-Ratenlimit ist ein Gesamtlimit, das für den kombinierten Datenverkehr über Opus 4 und Opus 4.1 gilt. ** - Das Sonnet 4.x-Ratenlimit ist ein Gesamtlimit, das für den kombinierten Datenverkehr über Sonnet 4 und Sonnet 4.5 gilt. † - Limit zählt cache_read_input_tokens zur ITPM-Nutzung.

​
Message Batches API

Die Message Batches API hat ihre eigenen Ratenlimits, die über alle Modelle hinweg gemeinsam genutzt werden. Diese umfassen ein Limit für Anfragen pro Minute (RPM) für alle API-Endpunkte und ein Limit für die Anzahl der Batch-Anfragen, die gleichzeitig in der Verarbeitungswarteschlange sein können. Ein “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 zu diesem Limit zählt. Eine Batch-Anfrage wird als Teil der Verarbeitungswarteschlange betrachtet, wenn sie noch nicht erfolgreich vom Modell verarbeitet wurde.
Maximale Anfragen pro Minute (RPM)Maximale Batch-Anfragen in der VerarbeitungswarteschlangeMaximale Batch-Anfragen pro Batch
50100.000100.000

​
Ratenlimits für langen Kontext

Bei Verwendung von Claude Sonnet 4 und Sonnet 4.5 mit aktiviertem 1M-Token-Kontextfenster gelten die folgenden dedizierten Ratenlimits für Anfragen, die 200K Token überschreiten.
Das 1M-Token-Kontextfenster befindet sich derzeit in der Beta-Phase für Organisationen in Nutzungsstufe 4 und Organisationen mit benutzerdefinierten Ratenlimits. Das 1M-Token-Kontextfenster ist nur für Claude Sonnet 4 und Sonnet 4.5 verfügbar.
Maximale Eingabe-Token pro Minute (ITPM)Maximale Ausgabe-Token pro Minute (OTPM)
1.000.000200.000
Um das Beste aus dem 1M-Token-Kontextfenster mit Ratenlimits herauszuholen, verwenden Sie Prompt Caching.

​
Überwachung Ihrer Ratenlimits in der Console

Sie können Ihre Ratenlimit-Nutzung auf der Nutzungsseite der Claude Console überwachen. Zusätzlich zu Token- und Anfrage-Diagrammen bietet die Nutzungsseite zwei separate Ratenlimit-Diagramme. Verwenden Sie diese Diagramme, um zu sehen, wie viel Spielraum Sie zum Wachsen haben, wann Sie möglicherweise Spitzenlast erreichen, um besser zu verstehen, welche Ratenlimits Sie anfordern sollten, oder wie Sie Ihre Caching-Raten verbessern können. Die Diagramme visualisieren eine Reihe von Metriken für ein bestimmtes Ratenlimit (z. B. pro Modell):
  • Das Diagramm Rate Limit - Eingabe-Token enthält:
    • Stündliches Maximum ungecachter Eingabe-Token pro Minute
    • Ihr aktuelles Ratenlimit für Eingabe-Token pro Minute
    • Die Cache-Rate für Ihre Eingabe-Token (d. h. der Prozentsatz der Eingabe-Token, die aus dem Cache gelesen werden)
  • Das Diagramm Rate Limit - Ausgabe-Token enthält:
    • Stündliches Maximum Ausgabe-Token pro Minute
    • Ihr aktuelles Ratenlimit für Ausgabe-Token pro Minute

​
Festlegen niedrigerer Limits für Workspaces

Um Workspaces in Ihrer Organisation vor möglicher Übernutzung zu schützen, können Sie benutzerdefinierte Ausgaben- und Ratenlimits pro Workspace festlegen. Beispiel: Wenn das Limit Ihrer Organisation 40.000 Eingabe-Token pro Minute und 8.000 Ausgabe-Token pro Minute beträgt, könnten Sie einen Workspace auf 30.000 Token pro Minute insgesamt begrenzen. Dies schützt andere Workspaces vor möglicher Übernutzung und gewährleistet eine gerechtere Verteilung der Ressourcen in Ihrer Organisation. Die verbleibenden ungenutzten Token pro Minute (oder mehr, wenn dieser Workspace das Limit nicht nutzt) stehen dann anderen Workspaces zur Verfügung. Hinweis:
  • Sie können keine Limits für den Standard-Workspace festlegen.
  • Falls nicht festgelegt, entsprechen Workspace-Limits dem Organisationslimit.
  • Organisationsweite Limits gelten immer, auch wenn Workspace-Limits zusammen mehr ergeben.
  • Unterstützung für Eingabe- und Ausgabe-Token-Limits wird in Zukunft zu Workspaces hinzugefügt.

​
Response-Header

Die API-Antwort enthält Header, die das erzwungene Ratenlimit, die aktuelle Nutzung und den Zeitpunkt des Limit-Zurücksetzen anzeigen. Die folgenden Header werden zurückgegeben:
HeaderBeschreibung
retry-afterDie Anzahl der Sekunden, die Sie warten sollten, bevor Sie die Anfrage erneut versuchen können. Frühere Versuche schlagen fehl.
anthropic-ratelimit-requests-limitDie maximale Anzahl von Anfragen, die innerhalb eines Ratenlimit-Zeitraums zulässig sind.
anthropic-ratelimit-requests-remainingDie Anzahl der verbleibenden Anfragen, bevor eine Ratenbegrenzung erfolgt.
anthropic-ratelimit-requests-resetDer Zeitpunkt, zu dem das Anfrage-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format.
anthropic-ratelimit-tokens-limitDie maximale Anzahl von Token, die innerhalb eines Ratenlimit-Zeitraums zulässig sind.
anthropic-ratelimit-tokens-remainingDie Anzahl der verbleibenden Token (auf das nächste Tausend gerundet), bevor eine Ratenbegrenzung erfolgt.
anthropic-ratelimit-tokens-resetDer Zeitpunkt, zu dem das Token-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format.
anthropic-ratelimit-input-tokens-limitDie maximale Anzahl von Eingabe-Token, die innerhalb eines Ratenlimit-Zeitraums zulässig sind.
anthropic-ratelimit-input-tokens-remainingDie Anzahl der verbleibenden Eingabe-Token (auf das nächste Tausend gerundet), bevor eine Ratenbegrenzung erfolgt.
anthropic-ratelimit-input-tokens-resetDer Zeitpunkt, zu dem das Eingabe-Token-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format.
anthropic-ratelimit-output-tokens-limitDie maximale Anzahl von Ausgabe-Token, die innerhalb eines Ratenlimit-Zeitraums zulässig sind.
anthropic-ratelimit-output-tokens-remainingDie Anzahl der verbleibenden Ausgabe-Token (auf das nächste Tausend gerundet), bevor eine Ratenbegrenzung erfolgt.
anthropic-ratelimit-output-tokens-resetDer Zeitpunkt, zu dem das Ausgabe-Token-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format.
anthropic-priority-input-tokens-limitDie maximale Anzahl von Priority Tier-Eingabe-Token, die innerhalb eines Ratenlimit-Zeitraums zulässig sind. (Nur Priority Tier)
anthropic-priority-input-tokens-remainingDie Anzahl der verbleibenden Priority Tier-Eingabe-Token (auf das nächste Tausend gerundet), bevor eine Ratenbegrenzung erfolgt. (Nur Priority Tier)
anthropic-priority-input-tokens-resetDer Zeitpunkt, zu dem das Priority Tier-Eingabe-Token-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format. (Nur Priority Tier)
anthropic-priority-output-tokens-limitDie maximale Anzahl von Priority Tier-Ausgabe-Token, die innerhalb eines Ratenlimit-Zeitraums zulässig sind. (Nur Priority Tier)
anthropic-priority-output-tokens-remainingDie Anzahl der verbleibenden Priority Tier-Ausgabe-Token (auf das nächste Tausend gerundet), bevor eine Ratenbegrenzung erfolgt. (Nur Priority Tier)
anthropic-priority-output-tokens-resetDer Zeitpunkt, zu dem das Priority Tier-Ausgabe-Token-Ratenlimit vollständig aufgefüllt wird, im RFC 3339-Format. (Nur Priority Tier)
Die Header anthropic-ratelimit-tokens-* zeigen die Werte für das derzeit gültige restriktivste Limit an. Wenn Sie beispielsweise das Workspace-Pro-Minute-Token-Limit überschritten haben, enthalten die Header die Workspace-Pro-Minute-Token-Ratenlimit-Werte. Wenn Workspace-Limits nicht gelten, geben die Header die verbleibenden Gesamttoken zurück, wobei Gesamt die Summe der Eingabe- und Ausgabe-Token ist. Dieser Ansatz stellt sicher, dass Sie Sichtbarkeit in die relevanteste Einschränkung Ihrer aktuellen API-Nutzung haben.