Wie das 5-Stunden-Limit berechnet wird

Auf einen Blick (Kurzfassung):

5-Stunden-Fenster: Das Limit zählt gleitend ab deiner ersten Nachricht im Fenster.
Input dominiert: Teure Sessions mit riesigem Kontext verbrauchen dein Kontingent viermal schneller als kurze Sessions.
Opus vs. Sonnet: Opus 5 hat ein eigenes Zusatz-Budget – setze es gezielt für schwierige Aufgaben ein.

Die Kurzfassung

Auf Abo-Plänen laufen mehrere Limits parallel:

Limit	Geltungsbereich	Reset
Session-Limit („5-Stunden-Fenster")	alle Modelle gemeinsam	alle 5 Stunden
Wochen-Limit	alle Modelle gemeinsam	fester, deinem Account zugewiesener Zeitpunkt pro Woche
Modellspezifisches Wochen-Limit	ein Modell (Opus bzw. Sonnet, je nach Plan)	fester Wochenzeitpunkt
Opus-Limit	nur Opus-Requests	siehe Fehlermeldung

Die offiziellen Quellen sind bei der Bezeichnung des zweiten Wochen-Limits nicht einheitlich: der Max-Plan-Artikel spricht von einem zusätzlichen Limit „für Sonnet-Modelle", das Usage-Dashboard zeigt laut Support-Artikel Resets „für Opus und alle anderen Modelle" getrennt. Verlass dich auf die tatsächlichen Balken-Beschriftungen in /usage auf deinem Plan — die sind für deinen Account autoritativ.

Wie das Session-Fenster funktioniert

Das Session-Limit ist ein rollierendes Kontingent, das alle fünf Stunden zurückgesetzt wird. Die Fehlermeldung nennt einen konkreten Reset-Zeitpunkt:

You've hit your session limit · resets 3:45pm
You've hit your weekly limit  · resets Mon 12:00am
You've hit your Opus limit    · resets 3:45pm

In den Claude-Einstellungen unter Settings → Usage zeigt „Current session", wie viel des Fünf-Stunden-Kontingents verbraucht ist plus die verbleibende Zeit im Fenster. Genau diese Restzeit-Anzeige ist der entscheidende Hinweis auf die Mechanik: Das Fenster wird mit deiner ersten Nachricht angelegt und läuft fünf Stunden später ab — es ist kein kontinuierliches, tokenweises Nachfüllen.

Häufiges Missverständnis: In vielen Drittanbieter-Blogs steht, die vor exakt fünf Stunden verbrauchten Tokens würden „kontinuierlich wieder verfügbar". Keine offizielle Anthropic-Quelle beschreibt das so, und ein einzelner angezeigter Reset-Zeitpunkt plus Restlaufzeit passt nicht dazu. Für die Praxis ist das entscheidend — siehe Artikel 3.

Welches Limit welche Abhilfe hat

Session- und Wochen-Limit gelten über alle Modelle hinweg. Ein Wechsel per /model bringt hier nichts.
Das Opus-Limit ist modellspezifisch. Nach „You've hit your Opus limit" kannst du mit /model auf Sonnet oder Haiku wechseln und sofort weiterarbeiten.
Beides zählt gleichzeitig. Ein großer Aktivitätsschub kann das Wochenkontingent aufbrauchen, bevor das Session-Fenster überhaupt zurückgesetzt wird.

Was Anthropic nicht veröffentlicht

Es gibt keine offiziell publizierten absoluten Zahlen — keine Nachrichten pro Fenster, keine Tokenbudgets, keine Stundenkontingente pro Plan. Veröffentlicht ist ausschließlich:

Relative Vielfache: Max 5× bietet fünfmal, Max 20× zwanzigmal so viel Nutzung pro Session wie Pro.
Die Reset-Semantik (siehe oben).
Die Einflussfaktoren: Nachrichtenlänge und -komplexität, Größe von Datei-Anhängen, Länge der Konversationshistorie, Tool-Nutzung (Research, Websuche), Modellwahl, Artefakt-Erstellung.

Genau deshalb fühlen sich die Limits „unberechenbar" an und unterscheiden sich zwischen zwei Nutzern auf demselben Plan: jeder Request verbraucht unterschiedlich viel.

Zahlen aus Blogposts nicht als Fakt übernehmen. Werte wie „~45 Nachrichten pro 5-Stunden-Fenster für Pro" kursieren breit, stammen aber nicht aus offiziellen Quellen. Die einzige belastbare Größenordnung war eine Anthropic-Schätzung bei Einführung der Wochenlimits im August 2025 (~40–80 Stunden Sonnet pro Woche für die meisten Pro-Nutzer) — inzwischen sind Modelle, Tokenizer und Limits mehrfach geändert worden. Nutze sie höchstens als Größenordnung, nie als Planungsgrundlage.

Was in den Topf einzahlt

Das Kontingent ist geteilt zwischen Claude Code, Claude-Chat und Cowork. Intensive Nutzung in einem Produkt reduziert die Kapazität in den anderen.

Innerhalb von Claude Code zahlen ein:

Die komplette Konversationshistorie, bei jedem Turn neu gesendet
Projekt-Kontext: CLAUDE.md und alle gelesenen Dateien
Thinking-Tokens (als Output abgerechnet)
Subagents — eigener Kontext, eigene Tokens
Agent Teams — jeder Teammate ist eine eigene Claude-Instanz, ca. 7 × Verbrauch
Scheduled Tasks, die auch bei idler Session feuern
/compact, das die zusammenzufassende Konversation selbst liest
Cache-Misses nach längeren Pausen

Warum lange Sessions überproportional zehren

Die Docs benennen fünf Ursachen dafür, dass eine seit Stunden offene Session viel mehr Kontingent verbraucht, als die eigene Aktivität nahelegt:

Langer Kontext — die ganze Konversation wird pro Nachricht neu gesendet.
Cache-Misses — die erste Nachricht nach einer Pause, die länger als die Cache-Lebensdauer ist, verarbeitet den gesamten Kontext neu. Im Abo ist die Lebensdauer eine Stunde; sie fällt auf fünf Minuten, sobald Usage Credits verbraucht werden.
Scheduled Tasks — feuern im Intervall, auch bei idler Session.
Agent-Teammates — verbrauchen bis zum Beenden weiter.
Compaction — ist selbst ein großer Request.

Was sich zuletzt geändert hat

Die Limits sind kein statisches System. Belegte Änderungen aus offiziellen Kanälen — jeweils Momentaufnahmen zum Zeitpunkt der Ankündigung. Die Reihenfolge unten ergibt sich aus den Post-IDs; keiner der Posts trägt ein von uns verifiziertes Datum, und keine Docs-Seite bestätigt den aktuellen Stand der Peak-Hour-Regelung. Im Zweifel gilt, was /usage auf deinem Account zeigt:

Änderung	Quelle
Einführung wöchentlicher Rate-Limits für Pro und Max; Anthropic schätzte, dass unter 5 % der Abonnenten betroffen sind	@AnthropicAI
Peak-Hour-Drosselung: werktags 5–11 Uhr PT / 13–19 Uhr GMT lief man schneller durch das 5-Stunden-Limit; Wochenlimits blieben unverändert	Thariq (Anthropic)
Verdopplung der 5-Stunden-Limits für Pro, Max und Team; Peak-Hour-Reduktion für Pro und Max wieder entfernt; API-Rate-Limits für Opus deutlich angehoben	@claudeai
Mehrfache Resets aller 5-Stunden- und Wochenlimits, u. a. nach einem Bug, bei dem Sessions exzessiv parallele Subagents spawnten und Kontingent verbrannten	@ClaudeDevs

Merkposten aus dem Subagent-Bug: unkontrollierte Parallelität ist der schnellste Weg, ein Kontingent zu verbrennen. Das gilt auch ohne Bug für Agent Teams und aggressive Delegation — siehe Opus 5 in Artikel 5.

Nachschauen statt raten

Werkzeug	Zeigt
`/usage`	Plan-Balken, Aktivitätsstatistik, Aufschlüsselung nach Skills / Subagents / Plugins / MCP-Servern. `d` / `w` für 24 h bzw. 7 Tage.
`/usage-credits`	Öffnet Billing bzw. sendet bei Team/Enterprise ohne Billing-Rechte eine Anfrage an die Admins.
Statusline mit `rate_limits`	Dauerhafte Anzeige des Restkontingents.
Desktop-App	Usage-Ring neben dem Modell-Picker.
VS-Code-Extension	„Account & usage"-Dialog mit Day/Week-Umschalter (ab v2.1.174).

/usage berechnet die Aufschlüsselung aus der lokalen Session-Historie dieses Rechners. Nutzung von anderen Geräten oder aus claude.ai fließt nicht ein — die Zahlen sind Näherungen, die Plan-Balken kommen dagegen vom Server.

Team und Enterprise

Auf Claude for Teams und Enterprise zieht jede Person aus einem Sitzplatz-Kontingent, das auf einem rollierenden Fünf-Stunden-Fenster und einem Wochenfenster zurückgesetzt wird. Größe je nach Seat-Tier (Standard oder Premium), geteilt mit Claude-Chat und Cowork. Nutzung innerhalb des Kontingents wird nicht in Dollar gemessen; erst Usage Credits erzeugen messbare Ausgaben.

Nicht verwechseln: Die in den Docs genannten Zahlen wie „≈ 13 $ pro Entwickler und aktivem Tag" oder „150–250 $ pro Monat" sowie die TPM/RPM-Tabellen gelten für API-/Console-/Enterprise-Abrechnung pro Token — nicht für Pro- oder Max-Abos. Der Dollarbetrag im Session-Block von /usage ist für Abonnenten ausdrücklich nicht abrechnungsrelevant.