AIDiveIntro: die Woche, die kürzer wurde
Das Wochenlimit von Claude Code ist Mitte September 2026 um 17% gesunken, als die Sommer-Aktion endete. Nutzer der größten Tarife berichten jetzt von einer leeren Woche schon am Mittwoch. In der Ankündigung von Anthropic heißt es, die Limits seien dauerhaft um 25% angehoben worden, und der Beitrag direkt danach nennt dieselbe Änderung eine Reduzierung um 17%.
Jede Tippliste zum Strecken des Limits kommt ohne eine einzige Zahl aus. Dieser Artikel stellt jedem Fix eine gemessene Zahl zur Seite und bringt sie in eine Rangfolge. Zwei Ergebnisse stechen heraus: Fast die Hälfte der Tokens eines Monats ging an Subagents, und eine einzige lange Pause sorgt dafür, dass die nächste Nachricht den Großteil der Session neu schreibt.
Was sich geändert hat, und wie man zählt
Die Messungen hier stammen aus den Claude-Code-Logs eines einzelnen Entwicklers über einen Monat: 455 Sessions und 63.398 Requests, vom 3. September bis zum 3. Oktober.
Die Aktion lief von Mai bis zum 13. September und machte das Wochenlimit 50% höher. Das Limit pro Fünf-Stunden-Fenster hat sich nie bewegt. Ende August verkündete der Entwickler-Account von Anthropic eine dauerhafte Erhöhung um 25%, und einen Beitrag später sagt derselbe Thread, es laufe auf eine Reduzierung um 17% hinaus. Beide Aussagen stimmen:
| Zeitraum | Wochenlimit (altes Limit = 100) |
|---|---|
| Vor der Aktion | 100 |
| Während der Aktion (Mai bis 13. September) | 150 |
| Dauerhaftes Niveau seit dem 14. September | 125 |
Von 150 auf 125 sind die 17%, die die Leute spüren. Ein Nutzer mit zwei der größten Tarife schrieb, mittwochs bei 100% zu sein, sei vorher nie vorgekommen. Ein anderer, im selben Tarif, lag an einem Dienstagmorgen bei 86%. Die Kürzung ist nicht die einzige Ursache: Anfang September erschien ein hungrigeres Modell, also geht nicht jede leere Woche auf diese Änderung zurück.
Von deiner Seite aus siehst du einen Prozentwert. Die Ansicht /usage schlüsselt die jüngste Nutzung nach Skills, Subagents, Plugins und jedem verbundenen MCP-Server auf und markiert Cache-Misses. Eine Taste schaltet zwischen dem letzten Tag und den letzten sieben um. Was du nicht sehen kannst, ist die Größe des Limits in Tokens: Anthropic veröffentlicht Prozentwerte und Multiplikatoren, nie eine Token-Zahl. Alles, was unten gemessen wird, ist deshalb in Tokens angegeben, stammt aus einem Workload und ist kein Anteil deiner Woche.
Das Zählen von Tokens aus den Logs hat eine Falle. Das Log schreibt dieselbe Antwort mehrfach, sodass das Addieren aller Zeilen 18,6 Milliarden Tokens ergibt. Einmal gezählt sind es 9,3 Milliarden. Eine naive Zählung verdoppelt fast alles.
Subagents: fast die Hälfte der Rechnung
Ein Subagent ist ein weiteres Claude, das deine Session für eine Nebenaufgabe startet und das nach Abschluss Bericht erstattet. Im gemessenen Monat nahmen Subagents 48,1% aller Tokens in 2.631 Läufen.
| Messgröße | Anteil der Subagents |
|---|---|
| Alle Tokens | 48,1% |
| Output-Tokens | 63,9% |
| Gewichtet, wie die öffentliche Preisliste Output und Cache-Writes gewichtet | 55,3% |
Jeder Subagent zahlt außerdem einen Eintrittspreis. Bevor er irgendetwas tut, trägt seine erste Anfrage bereits im Median 47.117 Tokens mit: die Anweisungen, die Tool-Liste und die Skill-Liste, alles erneut gesendet. Jemand anderes hat das auf einer anderen Maschine gemessen und kam auf 16.000 bis 21.000 Tokens pro Start bei Agents, deren eigener Prompt winzig ist. Wie es in diesem Artikel heißt, ist die Agent-Datei ein Rundungsfehler innerhalb ihrer eigenen Startkosten.
Das Modell ist die andere Hälfte. Standardmäßig erbt ein Subagent das Modell der Hauptunterhaltung, sodass das Umschalten der Session auf das größte Modell auch jeden Helfer darauf setzt. In den gemessenen Logs bearbeitete das kleinste Modell weniger als 1% der Subagent-Requests. Der Fix ist eine Zeile in der Datei des Agents: ein Feld model, das für Jobs wie Tests ausführen oder Dateien durchsuchen auf ein kleineres Modell gesetzt wird.
Daraus ergeben sich zwei Gewohnheiten. Verzichte auf den Subagent bei einem kleinen Job, den du direkt erledigen könntest, und lege bei denen, die du behältst, ein kleines Modell fest.
Die Grenze dieses Ergebnisses: Niemand hat gemessen, wie viel das Festlegen als Anteil der Woche spart, und ein kleines Modell, das mehr Durchgänge braucht, kann mehr kosten. Die 48% stammen aus Arbeit, die sich stark verzweigt. Dein eigener Anteil steht in der Ansicht /usage.
Der Fünf-Minuten-Cache, den keiner listet
Claude Code hält deine Unterhaltung serverseitig in einem Prompt-Cache, und das erneute Lesen kostet einen Bruchteil des erneuten Sendens. Für die Hauptsession lebt dieser Cache eine Stunde. Für einen Subagent lebt er fünf Minuten.
Die Dokumentation sagt es deutlich: Subagents bekommen fünf Minuten, auch mit Abo, bis du etwas Längeres wählst. Dasselbe gilt für alles außerhalb der Hauptunterhaltung, einschließlich Hintergrundarbeit und Compaction. Die gemessenen Logs stimmen damit überein: Jeder Cache-Write eines Subagents landete in der Fünf-Minuten-Stufe und jeder einer Hauptsession in der Ein-Stunden-Stufe.
Ein Entwickler auf Reddit bemerkte, was das bewirkt: Einer seiner Subagents schrieb an einem einzigen Tag achtmal seinen gesamten Kontext neu. Der Fix ist eine Zeile in der Settings-Datei, "subagentPromptCacheTtl": "1h".
| Seine Messung | Vorher | Nachher |
|---|---|---|
| Cache-Writes | 12,2 Millionen Tokens | 3,0 Millionen Tokens |
| Fünf-Stunden-Fenster mit vier Subagents | von 2% auf 100% | von 0% auf 22% |
Das ist ein Nutzer, der zwei verschiedene Tage vergleicht, kein kontrollierter Test. In den hier gemessenen Logs spielt es kaum eine Rolle: Nur 95 von 41.790 Folge-Requests von Subagents (etwa zwei von tausend) kamen nach einer Wartezeit von mehr als fünf Minuten, auch wenn jeder davon etwa 75.000 Tokens neu schrieb.
Es hängt also davon ab, wie deine Subagents arbeiten. Wenn sie auf einen langen Build, ein Review oder auf dich warten, schalte es ein. Wenn sie in kurzen Schüben laufen, lass es, denn ein Cache, der eine Stunde hält, kostet beim Schreiben mehr.
Die Pause, die die ganze Session neu schreibt
Der Cache der Hauptsession hält eine Stunde. Nach einer längeren Pause ist er weg, und die nächste Nachricht kann nichts zurücklesen. Die Dokumentation formuliert es klar: Die Nachricht, die du nach der Pause sendest, verfehlt den Cache und verarbeitet deinen gesamten Kontext erneut.
| Pause vor der Nachricht | Requests | Cache neu geschrieben (Median) |
|---|---|---|
| Unter 5 Minuten | 18.029 | 1.176 Tokens |
| 5 bis 60 Minuten | 414 | 1.327 Tokens |
| Über 60 Minuten | 79 | 130.332 Tokens |
Die typische Session enthielt in diesem Moment 175.523 Tokens, der größte Teil wurde also erneut geschrieben. Der Zähler behandelt einen Write auch nicht wie einen Read. Ein Entwickler schaltete einen Logging-Proxy vor Claude Code und beobachtete sein Fünf-Stunden-Fenster: Nach seinen Verhältnissen wiegt ein in den Cache geschriebener Token etwa vierzigmal so viel wie ein daraus gelesener.
Claude Code weiß das. Wenn du eine große Session nach einer langen Pause fortsetzt, bietet es an, stattdessen aus einer Zusammenfassung fortzusetzen. Nimm das Angebot an.
Die günstigere Gewohnheit liegt früher. Wenn eine Aufgabe erledigt ist, leere die Session, solange der Cache noch warm ist. Leeren kostet nichts, und die nächste Aufgabe beginnt klein. Compaction funktioniert auch, aber eine riesige Session zu komprimieren ist selbst ein riesiger Request.
Eine Pause ist nicht der einzige Weg, den Cache zu verlieren. Ein Modellwechsel mitten in der Session leert ihn, weil jedes Modell seinen eigenen hält. Bei den neuesten Modellen tut das ein Wechsel des Efforts nicht. Claude Code fragt nach einer Bestätigung für einen Modellwechsel, solange der Cache warm ist, und diese Rückfrage ist die Warnung.
Die Grenzen: 79 kalte Rückkehrer sind eine kleine Stichprobe, und manche davon folgen auf eine Compaction. Eine Zusammenfassung verliert außerdem Details, dieser Fix kostet also etwas Kontinuität.
Effort: der Fix, der Qualität kosten kann
Effort bestimmt, wie lange das Modell denken darf, bevor es antwortet. Es gibt fünf Stufen, von low bis max, und das Denken wird als Output abgerechnet. Der Standard ist high bei den meisten Modellen und medium bei den zwei neuesten.
Die Dokumentation sagt, das Denk-Budget könne pro Request in die zehntausende Tokens gehen, und die oberste Stufe neige zum Überdenken. Bei den neuesten Modellen lässt sich das Denken gar nicht abschalten, die Stufe ist also die einzige Stellschraube.
Ein Entwickler ließ dieselben 29 echten Aufgaben auf allen fünf Stufen laufen:
| Effort-Stufe | Durchschnittskosten pro Aufgabe | Bestandene Aufgaben (von 29) |
|---|---|---|
| low | 2,50 $ | 23 |
| medium | 3,15 $ | 28 |
| high | 5,01 $ | 26 |
| xhigh | 6,51 $ | 25 |
| max | 8,84 $ | 27 |
Die Qualität folgte nicht den Kosten. Medium bestand mehr Aufgaben als jede höhere Stufe und lieferte pro Dollar auch die meisten bestandenen Aufgaben. In seinen Worten scheint die Kurve bei medium ihr Maximum zu haben. Das Claude-Code-Team arbeitet genauso: Einer seiner Entwickler baut mit low oder medium, prüft und fährt die Verifikation nur mit high.
Der Haken erklärt, warum dieser Fix Qualität kosten kann. Bei den schweren Problemen, die er ausgewählt hatte, bestand low null von fünf Malen und high fünf von fünf. Ein low-Versuch dauerte zwei Minuten, ein high-Versuch dreiunddreißig.
Passe den Effort also dem Schritt an: medium zum Bauen, high, wenn ein Fehler teuer ist (ein Bug in altem Code, eine Migration, eine abschließende Prüfung), max fast nie. Die Session-Logs halten den Effort jedes Requests fest, du kannst also nachsehen, was du wirklich gefahren hast.
Diese Kosten sind in Dollar auf einem älteren Modell angegeben, kein Anteil der Woche, das hat niemand veröffentlicht. Und ein günstiger Versuch, der scheitert und zweimal läuft, kostet mehr als einer, der funktioniert.
Die Tipps, die weniger wiegen als versprochen
Manche Fixes stehen auf jeder Liste und bewegen kaum etwas. Man kann sie gratis ausprobieren. Dort ist die Woche nur nicht geblieben.
Was beim Start geladen wird, ist in dieser Gruppe der echte Posten. Ein Artikel maß die erste Anfrage aus einem leeren Ordner mit 29.061 Tokens und in einem echten Projekt mit fast 39.000. In den hier gemessenen Logs liegt die mediane erste Anfrage bei 55.989 Tokens, je nach Projekt zwischen 15.764 und 105.020. Der Befehl /context zeigt, was darin steckt (Memory-Dateien, Skills, Tool-Listen), und nennt jede geladene Memory-Datei. Kürze, was du nie benutzt. Der Gewinn ist bescheiden, weil dieser Block einmal geschrieben und danach bei jedem Turn aus dem Cache gelesen wird. Weh tut er bei einem Kaltstart und bei jedem Subagent-Start.
| Beliebter Tipp | Gemessen |
|---|---|
| MCP-Server entfernen | 1.350 Tokens für 51 Tools über drei Server; 18 Tokens für einen Server mit einem Tool |
| Prompt-Vorschläge abschalten | 3 bis 4% bei einem Nutzer; die Behauptung „bis zu 10%“ stammte von einem Account mit riesigen Kontexten |
| Shell-Output filtern | etwa 0,1% des Gesamtvolumens, gemessen von einem Mitwirkenden an einem dieser Filter |
Tool-Definitionen werden inzwischen standardmäßig zurückgestellt, weshalb MCP-Server so wenig wiegen. Die Dokumentation nennt die Kosten der Prompt-Vorschläge klein. Alle drei wachsen mit der Größe deines Kontexts, und Server kosten mehr auf älteren Modellen, bei denen das Zurückstellen aus ist. Schalte sie ab, wenn du magst, aber erwarte nicht, dass du die Woche zurückbekommst.
Die Ranking-Tabelle
Gerankt nach dem, was gemessen wurde:
| Rang | Fix | Gemessen | Haken |
|---|---|---|---|
| 1 | Weniger, günstigere Subagents | 48,1% der Tokens; 47.117 pro Start | Weniger Parallelität |
| 2 | Keine kalte Session fortsetzen | 130.332 Tokens neu geschrieben gegenüber 1.176 | Eine Zusammenfassung verliert Details |
| 3 | Effort: medium zum Bauen | 3,15 $ gegenüber 5,01 $ pro Aufgabe; 28 von 29 bestanden | Low scheitert an schweren Problemen |
| 4 | Subagent-Cache auf eine Stunde | 12,2 Millionen auf 3,0 Millionen Cache-Write-Tokens | Lohnt sich nur, wenn Subagents warten |
| 5 | Kürzen, was beim Start geladen wird | +9.744 Tokens auf einer Basis von 29.061 | Einmal pro Session gezahlt |
Die drei beliebten (MCP-Server, Prompt-Vorschläge, Shell-Output) sind nicht dort, wo die Woche geblieben ist.
Die Grenzen, ganz offen: Dieses Ranking ist in Tokens angegeben, stammt aus einem Monat Arbeit einer Person plus Messungen anderer Leute. Anthropic veröffentlicht die Größe des Limits in Tokens nicht, also kann niemand von außen daraus einen Anteil deiner Woche machen. Deine Reihenfolge kann abweichen, und die Ansicht /usage zeigt es dir.
Die beiden größten Fixes sind Gewohnheiten, keine Einstellungen, und sie sind gratis: weniger Subagents starten und nie eine kalte Session vollständig fortsetzen.
