Was Claudes Fünf-Stunden-Limit tatsächlich auslöst und vier Wege daran vorbei
Claude setzt die Nutzungsgrenze nicht auf Basis einzelner Nachrichten, sondern über ein rollierendes Fünf-Stunden-Fenster. Wer versteht, wann die Uhr startet und was sie misst, kann den Zeitpunkt für intensive Arbeit gezielter planen.
Wenn Sie mitten in einem Refactoring die Meldung "You've reached your usage limit. You can resume in X hours" erhalten haben, lautet die eigentliche Frage nicht, wie viele Nachrichten Sie bekommen. Entscheidend ist, was die Uhr misst und wann sie gestartet ist.
Das Fuenf-Stunden-Limit ist ein rollierendes Zeitfenster. Der Timer startet mit dem Zeitstempel Ihrer ersten Nachricht in einer Nutzungssitzung, nicht um Mitternacht und auch nicht in dem Moment, in dem Sie gesperrt werden.
Daraus ergeben sich zwei Konsequenzen, und sie erklaeren den Groteil der Verwirrung:
Es gibt zudem ein eigenstaetliches woechentliches Limit, das unabhaengig vom Fuenf-Stunden-Fenster zurueckgesetzt wird. Wenn Sie das Sitzungslimit erreichen, heisst das nicht, dass Ihr Wochenkontingent erschoepft ist, und umgekehrt.
Anthropic veroeffentlicht kein universelles Nachrichtenkontingent. Die Nutzung wird nach mehreren Faktoren gewichtet, die sich gegenseitig verstaerken:
Veroeffentlichte Schaetzungen liegen fuer Claude Pro bei rund 45 Nachrichten pro Fuenf-Stunden-Fenster, fuer Max 5x bei etwa 225 und fuer Max 20x bei etwa 900. Betrachten Sie diese als Groessenordnungszahlen, die von all dem oben Genannten abhaengen, nicht als garantierte Werte.
Das ist der Teil, der viele ueberrascht, und er ist mechanisch bedingt statt raetselhaft.
Ein Chat-Zug sendet einen Prompt und erhaelt eine Antwort. Der Kontext ist kurz und waechst kaum.
Eine Agent-Schleife ist rekursiv. Bei jedem Schritt wird der angesammelte Kontext erneut gesendet: dieselben Dateien, dieselben Tool-Ausgaben, dieselben Anweisungen. Eine Aufgabe mit fuenfzig Schritten kann denselben Kontext fuenfzigmal erneut einlesen. Der Verbrauch steigt mit der Aufgabenlaenge auf eine Weise, wie es ein einzelner Chat-Zug nie tut. Deshalb kann eine lange Coding-Sitzung ein Kontingent aufbrauchen, das sonst eine Woche Chat haette decken koennen.
Wenn Sie sehen moechten, wohin das Kontingent tatsaechlich fliesst, sind die beiden wichtigsten Stellschrauben die Gespraechslaenge und die Modellwahl, in dieser Reihenfolge.
1. Auf das Zuruecksetzen warten. Kostenlos und korrekt, wenn die Aufgabe warten kann. Die Uhr laeuft bereits seit Ihrem Sitzungsstart, pruefen Sie also die Reset-Zeit, bevor Sie annehmen, dass es noch fuenf Stunden dauert.
2. Den Kontext verkleinern. Beginnen Sie einen neuen Thread, statt einen langen fortzufuehren. Fassen Sie Tool-Ausgaben zusammen, statt sie einzufuegen. Begrenzen Sie die Anzahl der Schritte, die eine einzelne Agent-Aufgabe dauern darf, damit eine ausufernde Schleife das Zeitfenster nicht in einem Rutsch leert. Das ist die wirksamste Massnahme, und sie kostet nichts.
3. Nutzungsguthaben verwenden, falls vorhanden. Wenn Guthaben aktiviert und verfuegbar ist, laufen Sitzungen ueber das enthaltene Limit hinaus weiter, statt zu pausieren. Sie arbeiten weiter und zahlen den Mehrverbrauch.
4. Diese Arbeitslast auf einen API-Key mit einem anderen Limit-Modell verlagern. Diese Option wird oft unterschaetzt, weil sie die Form der Einschraenkung veraendert, nicht deren Groesse. Ein Abo begrenzt ein Zeitfenster. Ein API-Key misst Tokens oder Anfragen.
Beide sind legitim; sie scheitern auf unterschiedliche Weise.
Eine tokenbasiert abgerechnete API bietet eine hohe Obergrenze, aber eine unvorhersehbare Rechnung. Die Kosten einer Aufgabe sind erst nach ihrem Abschluss bekannt, was Budgetierung zu einer rueckblickenden Uebung macht und die Zuordnung pro Projekt zu einer Rekonstruktionsarbeit.
Eine anfragebasiert abgerechnete API begrenzt die Kosten ueber die Anzahl der Schritte, die Sie erlauben. Das verwandelt Budgetierung von einem Buchhaltungsproblem in eine Konfigurationsentscheidung, was der richtige Ort dafuer ist, wenn Sie Agents betreiben statt zu chatten.
Fuer einen Coding-Agent, der lange Aufgaben ausfuehrt, ist das zweite Modell meist die bessere Wahl. Fuer gelegentlichen Chat und kurze Aufgaben ist Token-Metering oft guenstiger.
Welche Option Sie auch waehlen, pruefen Sie Folgendes, bevor Sie sich festlegen:
Ich betreibe Coding-Agents statt Chat, daher war das Fenstermodell die falsche Form fuer meine Arbeitslast, und ich habe diese Arbeit zu einem anfragebasiert abgerechneten Gateway verlagert. Ich verwende APIClaw, OpenAI-kompatibel, pro Anfrage statt pro Token abgerechnet, und die Umstellung erforderte nur eine Aenderung der Base-URL. Wenn Sie beim Abo bleiben, ist der Kontext-Verkleinerungsrat oben der Teil, der sich in jedem Fall lohnt.
Das Fuenf-Stunden-Limit ist ein rollierendes Zeitfenster, gemessen ab Ihrer ersten Nachricht, gewichtet nach Gespraechslaenge, Modell und Anhaengen statt nach einer starren Nachrichtenanzahl. Agents leeren es schnell, weil sie bei jedem Schritt den Kontext erneut senden. Die Loesungen, nach Kosten sortiert: Kontext verkleinern, Agent-Schritte begrenzen, Guthaben nutzen oder das Limit-Modell vollstaendig wechseln.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
If you have hit "You've reached your usage limit. You can resume in X hours" in the middle of a refactor, the useful question is not how many messages you get. It is what the clock is measuring and when it started.
The five-hour limit is a rolling window. The timer starts at the timestamp of your first message in a usage session, not at midnight and not at the moment you get blocked.
Two consequences follow, and they explain most of the confusion:
There is also a separate weekly cap that resets independently of the five-hour window. Hitting the session limit does not mean you have exhausted the weekly allowance, and vice versa.
Anthropic does not publish a universal message quota. Usage is weighted by several factors that compound:
Published estimates put Claude Pro at roughly 45 messages per five-hour window, Max 5x around 225, and Max 20x around 900. Treat those as order-of-magnitude figures that vary with everything above, not as published guarantees.
This is the part that surprises people, and it is mechanical rather than mysterious.
A chat turn sends a prompt and gets a reply. The context is short and does not grow much.
An agent loop is recursive. Every step re-sends the accumulated context: the same files, the same tool outputs, the same instructions. A fifty-step task can re-read the same context fifty times. Consumption grows with task length in a way a single chat turn never does, which is why one long coding session can consume an allowance that would have covered a week of chat.
If you want to see where the allowance actually goes, the two levers that matter most are conversation length and model choice, in that order.
1. Wait for the reset. Free, and correct if the task can wait. The clock is already running from your session start, so check the reset time before assuming it is five hours away.
2. Shrink the context. Start a fresh thread rather than continuing a long one. Summarise tool output instead of pasting it. Cap the number of steps a single agent task may take, so a runaway loop cannot drain the window in one go. This is the highest-leverage fix and it costs nothing.
3. Use usage credits if you have them. When credits are enabled and available, sessions continue past the included limit rather than pausing. You keep working, and you pay for the overage.
4. Move that workload to an API key with a different limit model. This is the option people underweight, because it changes the shape of the constraint rather than the size of it. A subscription caps a window of time. An API key meters tokens or requests.
Both are legitimate; they fail differently.
A token-metered API gives you a large ceiling and an unpredictable bill. The cost of a task is only knowable after it finishes, which makes budgeting retrospective and per-project attribution a reconstruction exercise.
A request-metered API bounds cost by the number of steps you allow. That converts budgeting from an accounting problem into a configuration decision, which is where it belongs if you are running agents rather than chatting.
For a coding agent that runs long tasks, the second model is usually the better fit. For occasional chat and short jobs, token metering is often cheaper.
Whichever you pick, check these before committing:
I run coding agents rather than chat, so the window model was the wrong shape for my workload and I moved that work to a request-metered gateway. The one I use is APIClaw — [OI]-compatible, priced per request rather than per token, and it took a base-URL change to adopt. If you stay on a subscription, the context-shrinking advice above is the part worth doing regardless.
The five-hour limit is a rolling window measured from your first message, weighted by conversation length, model, and attachments rather than a flat message count. Agents drain it fast because they re-send context every step. The fixes, in order of cost: shrink context, cap agent steps, use credits, or change the limit model entirely.