Ratenlimits

Es gibt zwei Arten von Limits:

1. Ausgabenlimits legen die maximalen monatlichen Kosten fest, die einer Organisation für die API-Nutzung entstehen können.
2. Ratenlimits legen die maximale Anzahl von API-Anfragen fest, die eine Organisation innerhalb eines definierten Zeitraums stellen kann.

Die API setzt dienstseitig konfigurierte Limits auf Organisationsebene durch, aber du kannst auch benutzerkonfigurierbare Limits für die Workspaces deiner Organisation festlegen.



Über Ratenlimits

• Limits sind so konzipiert, dass sie API-Missbrauch verhindern und gleichzeitig die Auswirkungen auf gängige Nutzungsmuster von Kunden minimieren.
• Limits werden durch die Nutzungsstufe (usage tier) definiert. Deine Organisation wird automatisch einer Stufe zugeordnet und kann im Laufe der Zeit in eine höhere Stufe wechseln, wenn du die API nutzt.
• Limits werden auf Organisationsebene festgelegt. Du kannst die Stufe und die aktuellen Limits deiner Organisation auf der Seite Limits in der Claude Console einsehen.
• Du könntest Ratenlimits auch über kürzere Zeitintervalle erreichen. Beispielsweise könnte eine Rate von 60 Anfragen pro Minute (RPM) als 1 Anfrage pro Sekunde durchgesetzt werden. Kurze Anfragespitzen können das Limit überschreiten und Ratenlimit-Fehler auslösen.
• Die folgenden Limits sind die Standardlimits für jede Stufe. Wenn du höhere Limits benötigst, siehe Höhere Limits anfordern.
• Die API verwendet den Token-Bucket-Algorithmus für das Rate Limiting. Das bedeutet, dass deine Kapazität kontinuierlich bis zu deinem 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 Mehrausgaben reduzieren und eine faire Verteilung der Ressourcen unter den Nutzern sicherstellen.



Ausgabenlimits

Jede der Stufen Start, Build und Scale hat eine monatliche Ausgabenobergrenze, also den Höchstbetrag, den deine Organisation pro Kalendermonat für die API ausgeben kann. Sobald du die Ausgabenobergrenze deiner Stufe erreichst, wird die API-Nutzung bis zum nächsten Monat pausiert, es sei denn, du forderst ein höheres Limit an. Du kannst die monatliche Ausgabenobergrenze deiner Organisation auf der Seite Limits einsehen.

Organisationen auf der Custom-Stufe haben keine monatliche Ausgabenobergrenze; die Limits werden mit ihrem Account-Team vereinbart.

Du kannst auch dein eigenes Ausgabenlimit unterhalb der Obergrenze deiner Stufe festlegen, um die Kosten zu kontrollieren:



Ratenlimits

Die Ratenlimits für die Messages API werden in „requests per minute" (Anfragen pro Minute), oder RPM, „input tokens per minute" (Input-Token pro Minute), oder ITPM, und „output tokens per minute" (Output-Token pro Minute), oder OTPM, für jede Modellklasse gemessen. Wenn du eines der Ratenlimits überschreitest, erhältst du einen 429-Fehler, der beschreibt, welches Ratenlimit überschritten wurde, zusammen mit einem retry-after-Header, der angibt, wie lange du warten musst.



Cache-bewusstes ITPM

Viele API-Anbieter verwenden ein kombiniertes „tokens per minute" (Token pro Minute), oder TPM, Limit, das alle Token umfassen kann – sowohl gecachte als auch nicht gecachte, Input und Output. Bei den meisten Claude-Modellen zählen nur nicht gecachte Input-Token für deine ITPM-Ratenlimits. Dies ist ein entscheidender Vorteil, der die Ratenlimits effektiv höher macht, als sie zunächst erscheinen mögen.

ITPM-Ratenlimits werden zu Beginn jeder Anfrage geschätzt, und die Schätzung wird während der Anfrage angepasst, um die tatsächliche Anzahl der verwendeten Input-Token widerzuspiegeln.

Folgendes zählt für ITPM:

• input_tokens (Token nach dem letzten Cache-Breakpoint) ✓ Zählen für ITPM
• cache_creation_input_tokens (Token, die in den Cache geschrieben werden) ✓ Zählen für ITPM
• cache_read_input_tokens (Token, die aus dem Cache gelesen werden) ✗ Zählen NICHT für ITPM bei den meisten Modellen

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Beispiel: Mit einem ITPM-Limit von 2.000.000 und einer Cache-Trefferrate von 80 % könntest du effektiv 10.000.000 Input-Token pro Minute insgesamt verarbeiten (2 Mio. nicht gecacht + 8 Mio. gecacht), da gecachte Token nicht für dein Ratenlimit zählen.

OTPM-Ratenlimits werden in Echtzeit ausgewertet, während Output-Token erzeugt werden, und zählen nur die tatsächlich generierten Token. Der Parameter max_tokens fließt nicht in die Berechnung der OTPM-Ratenlimits ein, daher gibt es keinen Ratenlimit-Nachteil, wenn du einen höheren max_tokens-Wert festlegst.

Ratenlimits werden für jedes Modell separat angewendet; daher kannst du verschiedene Modelle gleichzeitig bis zu ihren jeweiligen Limits nutzen. Du kannst deine aktuellen Ratenlimits und deren Verhalten in der Claude Console überprüfen oder die konfigurierten Limits programmatisch mit der Rate Limits API auslesen.

^{* – Das Opus-Ratenlimit ist ein Gesamtlimit, das für den kombinierten Traffic über Claude Opus 4.8, Opus 4.7, Opus 4.6 und Opus 4.5 gilt.}

^{** – Das Sonnet 4.x-Ratenlimit ist ein Gesamtlimit, das für den kombinierten Traffic über Sonnet 4.6 und Sonnet 4.5 gilt. Claude Sonnet 5 hat ein separates Ratenlimit und ist nicht Teil dieses kombinierten Buckets.}

^{† – 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 geteilt werden. Dazu gehören ein Limit für Anfragen pro Minute (RPM) für alle API-Endpunkte und ein Limit für die Anzahl der Batch-Anfragen, die sich gleichzeitig in der Verarbeitungswarteschlange befinden können. Eine „Batch-Anfrage" bezieht sich hier auf einen Teil eines Message Batch. Du kannst einen Message Batch erstellen, der Tausende von Batch-Anfragen enthält, von denen jede für dieses Limit zählt. Eine Batch-Anfrage gilt als Teil der Verarbeitungswarteschlange, wenn sie noch nicht erfolgreich vom Modell verarbeitet wurde.



Managed Agents

Die Endpunkte von Claude Managed Agents sind pro Organisation ratenlimitiert. Diese Limits sind getrennt von den oben genannten Ratenlimits der Messages API.



Ratenlimits für den Fast-Modus

Bei Verwendung des Fast-Modus (Research Preview) mit speed: "fast" auf Claude Opus 4.8 oder Opus 4.7 gelten dedizierte Ratenlimits, die von den Standard-Opus-Ratenlimits getrennt sind. Wenn die Ratenlimits des Fast-Modus überschritten werden, gibt die API einen 429-Fehler mit einem retry-after-Header zurück. Der Fast-Modus ist auf Claude Opus 4.6 nicht verfügbar: Anfragen an claude-opus-4-6 mit speed: "fast" werden mit Standardgeschwindigkeit ausgeführt. Siehe Fast-Modus.

Die Antwort enthält anthropic-fast-*-Header, die den Status deines Fast-Modus-Ratenlimits anzeigen. Siehe Fast-Modus für Details zu diesen Headern.



Überwachung deiner Ratenlimits in der Console

Du kannst deine Ratenlimit-Nutzung auf der Seite Usage der Claude Console überwachen.

Zusätzlich zu Token- und Anfrage-Diagrammen bietet die Usage-Seite zwei separate Ratenlimit-Diagramme. Verwende diese Diagramme, um zu sehen, wie viel Spielraum du zum Wachsen hast, wann du möglicherweise Spitzennutzung erreichst, besser zu verstehen, welche Ratenlimits du anfordern solltest, oder wie du deine Caching-Raten verbessern kannst. Die Diagramme visualisieren eine Reihe von Metriken für ein bestimmtes Ratenlimit (zum Beispiel pro Modell):

• Das Diagramm Rate Limit - Input Tokens enthält:
  • Stündliches Maximum nicht gecachter Input-Token pro Minute
  • Dein aktuelles Ratenlimit für Input-Token pro Minute
  • Die Cache-Rate für deine Input-Token (das heißt, der Prozentsatz der Input-Token, die aus dem Cache gelesen wurden)
• Das Diagramm Rate Limit - Output Tokens enthält:
  • Stündliches Maximum der Output-Token pro Minute
  • Dein aktuelles Ratenlimit für Output-Token pro Minute



Höhere Limits anfordern

Um höhere Ratenlimits oder eine höhere monatliche Ausgabenobergrenze anzufordern, verwende Request rate limit increase auf der Seite Limits.



Niedrigere Limits für Workspaces festlegen

Weitere Informationen zu Workspaces findest du unter Workspaces.

Um Workspaces in deiner Organisation vor potenzieller Übernutzung zu schützen, kannst du benutzerdefinierte Ausgaben- und Ratenlimits pro Workspace festlegen.

Beispiel: Wenn das Limit deiner Organisation 40.000 Input-Token pro Minute und 8.000 Output-Token pro Minute beträgt, könntest du einen Workspace auf 30.000 Input-Token pro Minute begrenzen. Dies schützt andere Workspaces vor potenzieller Übernutzung und gewährleistet eine gerechtere Verteilung der Ressourcen in deiner Organisation. Die verbleibenden ungenutzten Token pro Minute (oder mehr, wenn dieser Workspace das Limit nicht ausschöpft) stehen dann anderen Workspaces zur Verfügung.

Hinweis:

• Du kannst keine Limits für den Standard-Workspace festlegen.
• Wenn nicht festgelegt, entsprechen die Workspace-Limits dem Limit der Organisation.
• Workspace-Limits werden pro Limiter-Typ festgelegt (wie Anfragen pro Minute, Input-Token pro Minute oder Output-Token pro Minute).
• Organisationsweite Limits gelten immer, auch wenn die Summe der Workspace-Limits höher ist.

Um deine aktuellen Organisations- und Workspace-Ratenlimits programmatisch auszulesen, verwende die Rate Limits API.



Response-Header

Die API-Antwort enthält Header, die dir das durchgesetzte Ratenlimit, die aktuelle Nutzung und den Zeitpunkt der Zurücksetzung des Limits anzeigen.

Die folgenden Header werden zurückgegeben:

Die anthropic-ratelimit-tokens-*-Header zeigen die Werte für das derzeit restriktivste geltende Limit an. Wenn du beispielsweise das Workspace-Token-Limit pro Minute überschritten hast, enthalten die Header die Werte des Workspace-Token-Ratenlimits pro Minute. Wenn keine Workspace-Limits gelten, geben die Header die insgesamt verbleibenden Token zurück, wobei die Gesamtsumme die Summe aus Input- und Output-Token ist. Dieser Ansatz stellt sicher, dass du Einblick in die relevanteste Einschränkung deiner aktuellen API-Nutzung hast.