Claude Platform auf AWS: Die Ratenlimits auf dieser Seite gelten für Claude Platform auf AWS. Abrechnungs- und Ausgabenlimits unterscheiden sich: Ausgabenlimits sind nicht verfügbar, und die Abrechnung erfolgt über den AWS Marketplace (nicht über Anthropic-Guthabenkäufe). Organisationen auf Claude Platform auf AWS werden in die Start-Stufe eingeordnet und wechseln nicht automatisch zwischen Nutzungsstufen. Um höhere Limits anzufordern, kontaktiere deinen Anthropic-Ansprechpartner. Die Konfiguration von Ratenlimits pro Workspace und der Fast Mode sind auf Claude Platform auf AWS nicht verfügbar.
Es gibt zwei Arten von Limits:
Die API erzwingt dienstseitig konfigurierte Limits auf Organisationsebene, aber du kannst auch benutzerkonfigurierbare Limits für die Workspaces deiner Organisation festlegen.
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.
| Nutzungsstufe | Monatliche Ausgabenobergrenze |
|---|---|
| Start | $500 |
| Build | $1.000 |
| Scale | $200.000 |
Organisationen auf der Custom-Stufe haben keine monatliche Ausgabenobergrenze; Limits werden mit ihrem Account-Team vereinbart.
Du kannst auch dein eigenes Ausgabenlimit unterhalb der Obergrenze deiner Stufe festlegen, um Kosten zu kontrollieren:
Navigiere zur Limits-Seite
Gehe zu Settings > Limits in der Claude Console.
Öffne den Ausgabenlimit-Editor
Klicke im Abschnitt Spend limits auf Change Limit (oder Set spend limit, falls derzeit kein Limit festgelegt ist).
Passe dein Ausgabenlimit an
Gib einen neuen Wert ein. Dein Ausgabenlimit darf die Obergrenze deiner aktuellen Stufe nicht überschreiten.
Die Ratenlimits für die Messages API werden in Anfragen pro Minute (RPM), Input-Token pro Minute (ITPM) und Output-Token pro Minute (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.
Du könntest auch 429-Fehler aufgrund von Beschleunigungslimits auf der API erhalten, wenn deine Organisation einen starken Anstieg der Nutzung verzeichnet. Um Beschleunigungslimits zu vermeiden, erhöhe deinen Traffic schrittweise und halte konsistente Nutzungsmuster ein.
Viele API-Anbieter verwenden ein kombiniertes „Token pro Minute"-Limit (TPM), 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 zu deinen 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 zu ITPM:
input_tokens (Token nach dem letzten Cache-Breakpoint) ✓ Zählen zu ITPMcache_creation_input_tokens (Token, die in den Cache geschrieben werden) ✓ Zählen zu ITPMcache_read_input_tokens (Token, die aus dem Cache gelesen werden) ✗ Zählen bei den meisten Modellen NICHT zu ITPMDas Feld input_tokens repräsentiert nur Token, die nach deinem letzten Cache-Breakpoint erscheinen, nicht alle Input-Token in deiner Anfrage. Um die gesamten Input-Token zu berechnen:
total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokensDas bedeutet, wenn du gecachte Inhalte hast, wird input_tokens typischerweise viel kleiner sein als dein gesamter Input. Zum Beispiel würdest du bei einem gecachten Dokument mit 200k Token und einer Nutzerfrage mit 50 Token input_tokens: 50 sehen, obwohl der gesamte Input 200.050 Token beträgt.
Für Ratenlimit-Zwecke zählen bei den meisten Modellen nur input_tokens + cache_creation_input_tokens zu deinem ITPM-Limit, was Prompt-Caching zu einer effektiven Möglichkeit macht, deinen effektiven Durchsatz zu erhöhen.
Beispiel: Mit einem ITPM-Limit von 2.000.000 und einer Cache-Trefferquote von 80 % könntest du effektiv 10.000.000 gesamte Input-Token pro Minute verarbeiten (2 Mio. nicht gecacht + 8 Mio. gecacht), weil gecachte Token nicht zu deinem Ratenlimit zählen.
Claude Haiku 3.5 (in den folgenden Ratenlimit-Tabellen mit † markiert) zählt auch cache_read_input_tokens zu den ITPM-Ratenlimits.
Für alle Modelle ohne die †-Markierung zählen gecachte Input-Token nicht zu den Ratenlimits und werden zu einem reduzierten Satz abgerechnet (10 % des Basispreises für Input-Token). Das bedeutet, dass du durch die Verwendung von Prompt-Caching einen deutlich höheren effektiven Durchsatz erreichen kannst.
Maximiere deine Ratenlimits mit Prompt-Caching
Um das Beste aus deinen Ratenlimits herauszuholen, verwende Prompt-Caching für wiederholte Inhalte wie:
Mit effektivem Caching kannst du deinen tatsächlichen Durchsatz drastisch erhöhen, ohne deine Ratenlimits zu erhöhen. Überwache deine Cache-Trefferquote auf der Usage-Seite, um deine Caching-Strategie zu optimieren.
OTPM-Ratenlimits werden in Echtzeit ausgewertet, während Output-Token erzeugt werden, wobei nur die tatsächlich generierten Token gezählt werden. 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 das Verhalten in der Claude Console überprüfen oder die konfigurierten Limits programmatisch mit der Rate Limits API auslesen.
Ratenlimits werden derzeit über alle inference_geo-Werte hinweg geteilt. Anfragen mit inference_geo: "us" und inference_geo: "global" greifen auf denselben Ratenlimit-Pool zu.
| Modell | Maximale Anfragen pro Minute (RPM) | Maximale Input-Token pro Minute (ITPM) | Maximale Output-Token pro Minute (OTPM) |
|---|---|---|---|
| Claude Fable 5 | 1.000 | 500.000 | 100.000 |
| Claude Opus 4.x* | 1.000 | 2.000.000 | 400.000 |
| Claude Sonnet 5 | 1.000 | 2.000.000 | 400.000 |
| Claude Sonnet 4.x** | 1.000 | 2.000.000 | 400.000 |
| Claude Haiku 4.5 | 1.000 | 2.000.000 | 400.000 |
| Claude Haiku 3.5 (eingestellt, außer auf Bedrock und Google Cloud) | 1.000 | 100.000† | 20.000 |
* - 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.
† - Das Limit zählt cache_read_input_tokens zur ITPM-Nutzung.
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 mit Tausenden von Batch-Anfragen erstellen, von denen jede zu diesem Limit zählt. Eine Batch-Anfrage gilt als Teil der Verarbeitungswarteschlange, solange sie noch nicht erfolgreich vom Modell verarbeitet wurde.
| Maximale Anfragen pro Minute (RPM) | Maximale Batch-Anfragen in der Verarbeitungswarteschlange | Maximale Batch-Anfragen pro Batch |
|---|---|---|
| 1.000 | 200.000 | 100.000 |
Die Endpunkte von Claude Managed Agents sind pro Organisation ratenbegrenzt. Diese Limits sind von den oben genannten Ratenlimits der Messages API getrennt.
| Operation | Limit |
|---|---|
| Erstellungs-Endpunkte (zum Beispiel Agents, Sessions und Environments) | 300 Anfragen pro Minute |
| Lese-Endpunkte (zum Beispiel Abrufen, Auflisten und Streamen) | 1.200 Anfragen pro Minute |
Bei der Verwendung des Fast Mode (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 Fast-Mode-Ratenlimits überschritten werden, gibt die API einen 429-Fehler mit einem retry-after-Header zurück. Der Fast Mode ist auf Claude Opus 4.6 nicht verfügbar: Anfragen an claude-opus-4-6 mit speed: "fast" laufen mit Standardgeschwindigkeit. Siehe Fast Mode.
Die Antwort enthält anthropic-fast-*-Header, die den Status deines Fast-Mode-Ratenlimits anzeigen. Siehe Fast Mode für Details zu diesen Headern.
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, welchen Spielraum du für Wachstum hast, wann du möglicherweise Spitzenauslastung 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):
Um höhere Ratenlimits oder eine höhere monatliche Ausgabenobergrenze anzufordern, verwende Request rate limit increase auf der Seite Limits.
Der Support kann ebenfalls Limits erhöhen. Bei dringenden Anliegen kontaktiere den Support.
Mehr über Workspaces erfährst 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 sorgt für 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:
Um deine aktuellen Organisations- und Workspace-Ratenlimits programmatisch auszulesen, verwende die Rate Limits API.
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:
| Header | Beschreibung |
|---|---|
retry-after | Die Anzahl der Sekunden, die du warten musst, bis du die Anfrage erneut versuchen kannst. Frühere Wiederholungsversuche schlagen fehl. |
anthropic-ratelimit-requests-limit | Die maximale Anzahl von Anfragen, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. |
anthropic-ratelimit-requests-remaining | Die Anzahl der verbleibenden Anfragen, bevor das Ratenlimit greift. |
anthropic-ratelimit-requests-reset | Der Zeitpunkt, zu dem das Anfrage-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. |
anthropic-ratelimit-tokens-limit | Die maximale Anzahl von Token, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. |
anthropic-ratelimit-tokens-remaining | Die Anzahl der verbleibenden Token (auf das nächste Tausend gerundet), bevor das Ratenlimit greift. |
anthropic-ratelimit-tokens-reset | Der Zeitpunkt, zu dem das Token-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. |
anthropic-ratelimit-input-tokens-limit | Die maximale Anzahl von Input-Token, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. |
anthropic-ratelimit-input-tokens-remaining | Die Anzahl der verbleibenden Input-Token (auf das nächste Tausend gerundet), bevor das Ratenlimit greift. |
anthropic-ratelimit-input-tokens-reset | Der Zeitpunkt, zu dem das Input-Token-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. |
anthropic-ratelimit-output-tokens-limit | Die maximale Anzahl von Output-Token, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. |
anthropic-ratelimit-output-tokens-remaining | Die Anzahl der verbleibenden Output-Token (auf das nächste Tausend gerundet), bevor das Ratenlimit greift. |
anthropic-ratelimit-output-tokens-reset | Der Zeitpunkt, zu dem das Output-Token-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. |
anthropic-priority-input-tokens-limit | Die maximale Anzahl von Priority-Tier-Input-Token, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. (Nur Priority Tier) |
anthropic-priority-input-tokens-remaining | Die Anzahl der verbleibenden Priority-Tier-Input-Token (auf das nächste Tausend gerundet), bevor das Ratenlimit greift. (Nur Priority Tier) |
anthropic-priority-input-tokens-reset | Der Zeitpunkt, zu dem das Priority-Tier-Input-Token-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. (Nur Priority Tier) |
anthropic-priority-output-tokens-limit | Die maximale Anzahl von Priority-Tier-Output-Token, die innerhalb eines Ratenlimit-Zeitraums erlaubt sind. (Nur Priority Tier) |
anthropic-priority-output-tokens-remaining | Die Anzahl der verbleibenden Priority-Tier-Output-Token (auf das nächste Tausend gerundet), bevor das Ratenlimit greift. (Nur Priority Tier) |
anthropic-priority-output-tokens-reset | Der Zeitpunkt, zu dem das Priority-Tier-Output-Token-Ratenlimit vollständig aufgefüllt sein wird, angegeben im RFC-3339-Format. (Nur Priority Tier) |
Die anthropic-ratelimit-tokens-*-Header zeigen die Werte für das derzeit restriktivste geltende Limit an. Wenn du zum Beispiel 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.
Was this page helpful?