Claude Code Pro Max 5x-Tarif: Kontingent selbst bei moderater Nutzung nach nur 1,5 Stunden aufgebraucht

• Beim Tarif Pro Max 5x (1M Kontext) wird das Token-Limit bereits nach 1,5 Stunden überschritten, selbst bei moderaten Q&A- und Entwicklungsaufgaben
• Als Ursache wird ein Fehler vermutet, bei dem cache_read-Tokens mit dem vollen Faktor (1.0x) berechnet werden, wodurch der Caching-Effekt entfällt und der Verbrauch sprunghaft ansteigt
• Automatische Aufrufe aus Hintergrund-Sessions, Auto-Compact und große Kontexteingaben erhöhen gemeinsam die Verbrauchsgeschwindigkeit
• Die Community analysiert vor allem eine verkürzte Cache-TTL (1 Stunde → 5 Minuten) sowie Cache-Invalidierung (cache busting) als Kernursachen
• Anthropic arbeitet an einem kleineren Standard-Kontext (400k), UX-Verbesserungen und Optimierungen für inaktive Aufrufe und sammelt Nutzerfeedback

---

Problem des schnellen Kontingentverbrauchs im Pro-Max-5x-Tarif

• Im Tarif Pro Max 5x (claude-opus-4-6, 1M Kontext) wurde berichtet, dass das Kontingent bereits nach 1,5 Stunden erschöpft ist, obwohl nur mittelintensive Q&A- und leichte Entwicklungsarbeit durchgeführt wurde
  • In den vorherigen 5 Stunden intensiver Entwicklung war der Verbrauch noch normal, nach dem Reset trat dann der schnelle Verbrauch auf
  • Die Umgebung war Claude Code CLI on WSL2, betroffen war eine einzelne Session (mit 2 Auto-Compact-Vorgängen)
• Als Hauptursache wird ein Fehler vermutet, bei dem cache_read-Tokens mit dem vollen Faktor (1.0x) berechnet werden
  • Korrekt wäre, dass cache_read mit dem Faktor 1/10 berechnet wird; andernfalls entfällt der Caching-Effekt
  • Die Tokennutzung wurde über das usage-Objekt in den Session-Logs (~/.claude/projects/.../*.jsonl) analysiert
• Automatische Aufrufe aus Hintergrund-Sessions, die teure Verarbeitung von Auto-Compact und große Eingaben durch das 1M-Kontextfenster beschleunigen den Verbrauch zusätzlich
• Laut Community-Analyse nennen einige Nutzer vor allem eine verkürzte Cache-TTL (1 Stunde → 5 Minuten) und Cache-Invalidierung (cache busting) als Hauptursachen
• Das Anthropic-Team arbeitet an einem kleineren Standard-Kontext (400k), UX-Verbesserungen und Optimierungen für inaktive Aufrufe und bittet um zusätzliche Daten über Nutzerfeedback

Gemessener Tokenverbrauch

• Fenster 1 (15:00–20:00, 5 Stunden, intensive Entwicklung)

  • 2.715 API-Aufrufe, 1.044M Cache read, 16.8M Cache create, 1.15M Output-Tokens
  • Effektive Eingabe (bei Anwendung des 1/10-Faktors): 121.8M Tokens
  • Umsetzung von Express-Server + iOS-App, graphify-Pipeline und SPEC-basierter Multi-Agent-Koordination

• Fenster 2 (20:00–21:30, 1,5 Stunden, moderate Nutzung)

  • Haupt-Session (vibehq): 222 API-Aufrufe, 23.2M Cache read, 1.4M Cache create, 91k Output
  • Hintergrund-Sessions (einschließlich token-analysis, career-ops): insgesamt 691 Aufrufe, 103.9M Cache read, 387k Output
  • Insgesamt 13.1M effektive Tokens (bei Anwendung des 1/10-Faktors) → unter normalen Bedingungen keine Kontingentüberschreitung
  • Tatsächlich jedoch 105.7M Tokens (bei 1.0x-Berechnung) → 70.5M pro Stunde, was zum aufgebrauchten Kontingent passt

Zusammenfassung der Hauptprobleme

• 1. Fehler bei der Berechnung des Gebührenlimits für Cache-read-Tokens

  • Erwartet: cache_read wird mit dem Faktor 1/10 berechnet
  • Tatsächlich: Berechnung mit vollem Faktor, wodurch der Caching-Effekt aufgehoben wird
  • In einer 1M-Kontext-Umgebung werden pro Aufruf 100–960k Tokens übertragen, sodass bei mehr als 200 Aufrufen das Kontingent innerhalb weniger Minuten aufgebraucht sein kann

• 2. Verbrauch des gemeinsamen Kontingents durch Hintergrund-Sessions

  • Auch inaktive Sessions (wie token-analysis oder career-ops) verbrauchen durch Auto-Compact- und Post-Processing-Aufrufe fortlaufend das gemeinsame Kontingent

• 3. Teure Aufrufe durch Auto-Compact

  • Vor der Komprimierung wird der gesamte Kontext (~966k Tokens) als cache_creation gesendet, wodurch automatisch der teuerste Aufruf ausgelöst wird

• 4. Nebenwirkungen des 1M-Kontextfensters

  • Große Kontexte lassen die Tokenzahl pro Aufruf stark ansteigen und beschleunigen den Verbrauch des Kontingents

Schritte zur Reproduktion

1. Claude Code mit dem Opus-Modell im Tarif Pro Max 5x ausführen
2. Unter ~/.claude/rules/ etwa 30 Regeldateien einbinden (19k Token Overhead)
3. Tool-zentrierte Aufgaben wie Dateilesen, Build und Tests ausführen
4. Mit dem Befehl /context die Zunahme des Kontexts prüfen
5. Nach 200–300 Aufrufen den schnellen Kontingentrückgang bestätigen
6. In anderen Terminals 2–3 Sessions parallel offen halten
7. Auch nach einem Reset bestätigen, dass das Kontingent in kurzer Zeit erschöpft ist

Vergleich von erwartetem und tatsächlichem Verhalten

• Erwartet:

  • cache_read wird mit dem Faktor 1/10 berechnet
  • Inaktive Sessions verursachen nur minimalen Verbrauch
  • Auto-Compact führt nicht zu übermäßigem Verbrauch
  • Bei moderater Nutzung sollte das Kontingent 2–3 Stunden reichen

• Tatsächlich:

  • Aufgebraucht innerhalb von 1,5 Stunden
  • Hintergrund-Sessions verursachen 78 % des Verbrauchs
  • Insgesamt 105.7M übertragene Tokens, was darauf hindeutet, dass cache_read mit vollem Faktor berechnet wurde

Vorschläge zur Verbesserung

1. Berechnung von cache_read klarstellen — den tatsächlich verwendeten Faktor für die Kontingentberechnung in der Dokumentation angeben
2. Begrenzung nach effektiven Tokens — cache_read so korrigieren, dass es mit dem Faktor 1/10 berechnet wird
3. Erkennung inaktiver Sessions — automatische Aufrufe in inaktiven Sessions verhindern oder Warnhinweise anzeigen
4. Sichtbarkeit des Tokenverbrauchs in Echtzeit — Nutzung nach cache_read, cache_create, Eingabe und Ausgabe getrennt anzeigen
5. Kostenprognose auf Basis des Kontexts — die erwarteten Tokenkosten vor der Ausführung einer Aufgabe anzeigen

Community-Analyse und Diskussion

• cnighswonger

  • Erfasste mit dem Interceptor claude-code-cache-fix über 24 Stunden Daten aus 1.500 Aufrufen
  • Beim Test von drei Hypothesen (cache_read 0.0x, 0.1x, 1.0x) zeigte nur das 0.0x-Modell konsistente Ergebnisse im 5-Stunden-Fenster (CV 34,4 %)
  • Fazit: cache_read hat praktisch kaum Einfluss auf das Kontingent, der Cache funktioniert normal
  • Allerdings ist weitere Verifizierung nötig, da die Daten nur von einem einzelnen Account stammen

• henu-wang

  • Seit einer Regression, bei der die Cache-TTL von 1 Stunde auf 5 Minuten verkürzt wurde, entsteht bei jedem Pausieren einer Session cache_create, was 12,5-fach höhere Kosten verursacht
  • Je länger der Kontext wird, desto stärker steigen die Kosten nichtlinear an
  • Als Workarounds werden kurze Sessions, aktive Nutzung des Befehls /compact und das Vorladen zentraler Kontexte in CLAUDE.md empfohlen

• bcherny (Anthropic-Team)

  • Räumt ein, dass Prompt-Cache-Misses bei Nutzung des 1M-Kontextfensters teuer sind
  • Es werden UX-Verbesserungen getestet (etwa die Empfehlung von /clear beim Fortsetzen langer Sessions) sowie eine Reduzierung des Standard-Kontexts auf 400k
  • Außerdem wurden Fälle bestätigt, in denen inaktive Aufgaben bei Multi-Agent- oder Plugin-Nutzung übermäßig viele Tokens verbrauchen; daran wird mit automatischer Bereinigung und verbessertem Scheduling gearbeitet

• wadabum

  • Weist auf einen Bug hin, bei dem in neuen Sessions überhaupt kein Cache-Treffer auftritt (#47098, #47107)
  • Da der systemseitige Prompt auf Basis von git status und Blöcke in CLAUDE.md in jeder Session variieren, kommt es zu Cache-Invalidierung (cache busting)
  • cnighswonger antwortete, dass sein Interceptor zwar einige Sortierungsstabilisierungen vornimmt, das git-status-Problem aber separat behoben werden müsse

Zusammenfassung der Community-Vorschläge

• RockyMM: Wenn eine Session das Limit erreicht, automatisch zusammenfassen und die Wiederaufnahme ermöglichen; außerdem TTL auf 10 Minuten verkürzen
• mikebutash: Berichtet, dass im Pro-Tarif nur 2 Prompts pro 5 Stunden möglich seien; mit Rollback auf Version v2.1.81 und Installation von cache-fix sei eine 3- bis 4-fache Verbesserung bestätigt worden
• wutlu: Das Zurücksetzen der Session pro Aufgabe mildert das Problem
• dprkh: Unterstützt die Ursachenanalyse durch Teilen des Debug-Mode-Skills (Skill.md)

Fazit

• Das schnelle Aufbrauchen des Kontingents im Pro-Max-5x-Tarif ist auf ein Zusammenspiel aus Cache-Verhalten, TTL-Regression, Kontextaufblähung und Hintergrund-Aufrufen zurückzuführen
• Die Community kommt zu dem Schluss, dass eher Cache-Invalidierung und die verkürzte TTL als ein Berechnungsfehler bei cache_read die Hauptursachen sind
• Das Anthropic-Team arbeitet an einem kleineren Standard-Kontext, besserer Cache-UX und Optimierungen für inaktive Aufrufe und bittet um zusätzliche Daten über Nutzerfeedback (/feedback)

[kimjoin2]

Qualitativ gibt es nichts, was das wirklich ersetzen könnte.
Es wäre schön, wenn man es mit einem einfachen Patch länger nutzen könnte.

[GN⁺]

Meinungen auf Hacker News

• Hier ist Boris vom Claude-Code-Team. Nach Untersuchung der zuletzt gemeldeten Probleme gibt es zwei Hauptursachen

  1. Bei Verwendung des 1M-Token-Context-Windows sind Prompt-Cache-Misses teuer. Die aktuelle Cache-TTL beträgt 1 Stunde; wenn man also länger als eine Stunde weg ist, läuft die Session ab und der gesamte Cache muss erneut geladen werden. Zur Verbesserung haben wir UX-Anpassungen ausgerollt und prüfen eine Option, den Standardwert auf 400k zu senken. Zum sofortigen Testen kann man den Befehl CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude verwenden
  2. Wenn zu viele Plugins oder Agenten gleichzeitig laufen, wird unnötig viel Token-Budget verbraucht. Um das zu beheben, arbeiten wir an UX-Verbesserungen sowie automatischer Bereinigung und Terminierung nicht wesentlicher Aufgaben
     Nutzer mit Problemen helfen uns beim Debugging, wenn sie über den Befehl /feedback Feedback senden
  • Boris, die Erfahrungsberichte der Nutzer aus der Community sind keine bloßen Ausnahmen. Wie Jeff Bezos sagte: Manchmal sagen nicht die Daten, sondern Anekdoten die Wahrheit. Ihr solltet ernsthaft prüfen, ob eure Metriken falsch sind
  • Ich habe mich gefragt, warum dieses Problem plötzlich auftrat, und bei der Untersuchung stellte sich heraus, dass die Prompt-Cache-TTL von 1 Stunde auf 5 Minuten reduziert wurde. Selbst wenn man eine neue Session startet, muss letztlich alles neu aufgebaut werden, was ineffizient ist. Eine Struktur, bei der man den Cache-Ablauf überwachen muss, widerspricht der Philosophie von CC
  • In meinem Fall war die schlimmste Regression der Teil, in dem der System-Prompt bei jeder Datei eine Malware-Prüfung durchführen wollte. Dadurch wurden Tokens schnell verbraucht, und ständig kam die Antwort „not a malware“. Dieses Design ist eine Fehlentscheidung. Ich habe das Projekt schließlich abgebrochen und bin zu Qwen gewechselt, was ziemlich ordentlich ist
  • Die /clear-Benachrichtigung ist keine Lösung. Wenn man den Cache leert, muss man am Ende alles wieder neu aufbauen, die Kosten bleiben also gleich. Nutzer per UX zu kleineren Kontexten zu drängen verschlechtert die Servicequalität. Wenn es ein Kostenproblem ist, sollte man Preis oder Architektur korrigieren
  • OpenAI hat bei Problemen Nutzungslimits zurückgesetzt, Anthropic macht so etwas nicht. Das Ganze wirkt diesmal absichtlich

• In letzter Zeit war Claude auffällig langsamer und ineffizienter. Selbst wenn ich Dateien gezielt angebe, landet es über 5 Minuten in einer Explorationsschleife und stößt schnell an Session-Limits. Schon bei dreimaliger Nutzung pro Tag sind 25 % des Wochenlimits weg. Deshalb bin ich zum 100-$-Codex-Plan gewechselt, der bei Genauigkeit und Großzügigkeit deutlich besser ist. Der Tonfall von Codex nervt mich allerdings, daher habe ich in Agents.md eigene Anweisungen ergänzt. Das UI-Gefühl war beim früheren Claude Code besser, aber bei Backend-Debugging und dem Lösen komplexer Probleme ist Codex überlegen. Momentan würde ich empfehlen, den 20-$-Plan von Codex und Cursor zu vergleichen

  • Ich hatte eine ähnliche Erfahrung. Vor ein paar Tagen schien Claude nur noch festzuhängen und nachzudenken, am nächsten Tag funktionierte es wieder normal
  • Ich nutze den Codex-Business-Plan (30 Euro) und habe das Gefühl, dass die Quote zuletzt gesunken ist. Trotzdem sind die Bedingungen immer noch deutlich besser als bei Claude Code
  • Ich vergleiche derzeit das Verhalten des Confidence Score bei den Modellen Opus, Haiku und Sonnet. Opus ist bei Aufgaben mittlerer Schwierigkeit am effizientesten
  • Ich habe CC, Gemini-cli und Codex verwendet, und CC ist immer noch am besten. Ich frage mich, ob eine Kombination mit Cursor oder Aider besser wäre
  • Bei AI Coding gibt es viel Kontextverschwendung; wenn man den Umfang mit einer benutzerdefinierten Sandbox begrenzt, steigt die Effizienz

• Nachdem ich die Issues durchgesehen habe, verstehe ich, warum Anthropic Tickets so schnell schließt. Das meiste wirkt wie von AI erzeugtes Rauschen. Meine Lösung war folgende:

  1. In allen Sessions max thinking aktivieren, um unnötige Pfadsuche zu reduzieren
  2. Die Session dauerhaft aktiv halten. Wenn der Cache nach 5 Minuten abläuft, müssen die Tokens erneut aufgebaut werden
  3. Nach 200k Tokens sofort compact ausführen
     Mein größter Ärger ist, dass Anthropic das 1M-Modell erzwungen hat
  • Ich musste bei den Issues auch lachen. Wahrscheinlich hat jemand Claude Code einfach gesagt: „Untersuche, warum die Tokens aufgebraucht sind“
  • Die einen sagen, man solle thinking einschalten, die anderen, man solle es ausschalten. Dass beides Tokens sparen soll, ist ironisch
  • Der Kern ist ein Bug, bei dem der Cache zufällig invalidiert wird. Der API-Client scheint Subscriber-Caches vorzeitig zu beenden. Außerdem wurden die Kosten für Input-Tokens heimlich erhöht
  • Ich kann das bestätigen. Max effort hilft. Wichtig ist, den Kontext unter 25 % zu halten. Ich frage mich, ob es eine Möglichkeit gibt, den Cache-Ablaufstatus zu prüfen
  • Mit den Befehlen /model opus oder /model sonnet kann man das 1M-Modell deaktivieren

• Es fühlt sich an, als käme nun das Ende des Zeitalters der Subventionen. Auch in der Google-Gemini-Community gibt es zuletzt massiven Frust wegen gekürzter Quoten (Issue-Link). Ich bin am Ende ebenfalls zur Kombination aus Kiro IDE und Codex CLI gewechselt und zufrieden

  • Diese Entwicklung war absehbar. Es war eine kluge Strategie, in der Zeit der Gratis-Tokens die nötigen Bibliotheken im Voraus aufzubauen
  • Anthropic richtet sich inzwischen stärker auf Unternehmenskunden aus, und OpenAI geht einen ähnlichen Weg. Auf Reddit und Discord suchen einige nach Open-Model- oder chinesischen Alternativen, aber einen vollständigen Ersatz gibt es nicht
  • antigravity verbraucht die Pro-Quote schnell, aber der Flash-Modus ist deutlich großzügiger. Bei einem STM32-Projekt habe ich damit eine dreifach höhere Produktivität erreicht
  • Am Ende dieser Entwicklung steht vielleicht eine Zeit, in der Werbung an die Ausgaben gehängt wird
  • Das erinnert mich an die früheren 3-$-Uber-Fahrten

• Beunruhigend ist, dass das Issue, das die eigentliche Ursache des Problems benennt, mit „Not planned“ geschlossen wurde

  • Die Antwort wirkt unnatürlich, als hätte AI sie geschrieben. Auch die Logik „1-Stunden-TTL ist teurer“ klingt seltsam. Dass aus Kostengründen kein Toggle angeboten wird, ist schwer nachvollziehbar
  • Man muss sich davor nicht unbedingt fürchten. Wenn die Qualität schlechter wird, nutzt man es eben nicht mehr
  • Ich sehe darin eine Struktur, in der Anthropic Tokens wie in einem Casino verkauft und es egal ist, wenn Nutzer Geld verlieren. Wenn man so ein Modell nicht mag, sind lokale LLMs aus meiner Sicht die bessere Wahl

• Nachdem ich auf Version 2.1.34 zurückgerollt habe, waren die meisten Quoten- und Cache-Probleme gelöst.
  Ich habe in ~/.claude/settings.json Dinge wie "effortLevel": "high" und "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 ergänzt und andere Versionen entfernt.
  Adaptive thinking ist noch nicht ausgereift, könnte aber künftig hilfreich werden. Trotzdem überlege ich, zu Codex zu wechseln

  • Ich habe in meiner ~/.bashrc ebenfalls CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 usw. gesetzt

• Ähnliche Probleme gab es auch bei kleineren Modellen. Ein fairer Handel beginnt mit transparenter Messung. Ich werde mein Abo diesen Monat kündigen

  • Es gab Fälle, in denen eine Session startete, während der Computer im Energiesparmodus war, und dabei Tokens verbraucht wurden. Sogar einfache Fragen wie „Wie spät ist es gerade?“ haben 10 % verbraucht

• Dieses Jahr habe ich meine Steuererklärung testweise mit AI-Agenten gemacht. Ich habe Opus 4.6, Codex 5.4 und Antigravity 3.1 jeweils im 20-$-Plan verwendet.
  Codex erledigte alles in 12 Minuten perfekt, Antigravity ließ eine Seite aus, korrigierte das aber schnell. Claude Code brach wegen Überschreitung des Nutzungslimits ab und hatte auch nach einem erneuten Versuch noch Fehler. Das war enttäuschend

  • Ich habe ein ähnliches Experiment gemacht, und bei mir war Claude so präzise wie ein Steuerberater. Interessant ist, dass die Ergebnisse selbst bei derselben Aufgabe je nach Session unterschiedlich ausfallen. Kundensupport im Zeitalter nichtdeterministischer Software ist wirklich eine ungewohnte Erfahrung

• Seit der auf Reddit veröffentlichten Update-Mitteilung hat sich Claude so verändert, dass es für alltägliches Coding praktisch unbrauchbar geworden ist. Die Credits meines Pro-Kontos waren in einer Stunde aufgebraucht, daher bin ich wieder zu Gemini oder ChatGPT zurück

• Letztlich scheint die Token-Abrechnungsstruktur von Anthropic so gestaltet zu sein, dass normale Nutzer benachteiligt werden. In der Praxis merkt man sofort, wie viel Geld sie wirklich wollen