Claude Code 1M Context: So verhindere ich Context Rot

Claude Code 1M Context: So verhindere ich Context Rot

Der Sitzungszähler zeigte 612.000 Tokens an. Opus 4.7 lief seit fast vier Stunden. Es hatte 38 Dateien gelesen, eine Laravel-Service-Schicht refaktoriert, Tests geschrieben und forderte mich nun selbstbewusst auf, eine Methode in einer Klasse zu aktualisieren, die ich vor neunzig Minuten gelöscht hatte.

Nicht halluziniert. Gelöscht. Von Claude selbst. Mit einem Tool-Aufruf, den ich in derselben Sitzung nachverfolgen konnte.

Ich saß da, starrte auf das Terminal — der Kaffee war kalt, der Cursor blinkte unter einem Fix, der einen Rückschritt ausgeliefert hätte — und spürte das gleiche Unbehagen, das jeder Claude Code Power-User kennt. Das Modell wurde nicht dümmer. Das Modell ertrank. Irgendwo zwischen Token 300k und Token 600k war der Kontext still und heimlich von einem Vorteil zu einer Belastung geworden.

Das ist der Teil, den niemand ins Marketing für das Claude Code 1M context window schreibt. Das Fenster ist echt. Es funktioniert. Ich kann es belegen. Aber „1 Million Tokens“ ist nicht dasselbe wie „1 Million Tokens klarer, fokussierter, verlässlicher Logik“. Genau in dieser Lücke spielt sich der Großteil meines aktuellen Debuggings ab.

In den letzten 30 Tagen habe ich genug Opus 4.7-Sitzungen auf Max 20x durchlaufen, um genau zu ermitteln, wann Context Rot einsetzt, was ihn auslöst und welche fünf konkreten Maßnahmen lange Claude Code-Sitzungen präzise statt schwammig halten. Nichts davon ist theoretisch. Alles stammt aus echten, zuvor gebrochenen Builds.

Falls du jemals erlebt hast, wie Claude eine Bedingung vergisst, die du in Nachricht drei gesetzt hast, ist dieser Artikel für dich.

Was „1M Context“ in Claude Code aktuell wirklich bedeutet

Kurzer Hinweis vorab, denn die Versionsnummern sind entscheidend und die meisten Beiträge liegen hier falsch.

Das 1-Million-Token-Window in Claude Code kam nicht mit Opus 4.5. Opus 4.5 (November 2025) lag bei etwa 250k. Das 1M-Window wurde mit Claude Opus 4.6 am 5. Februar 2026 eingeführt — und wurde dann am 13. März 2026 allgemein in Claude Code für Opus 4.6 und Sonnet 4.6 verfügbar. Das aktuelle Modell ist Opus 4.7, erschienen am 16. April 2026, das weiterhin denselben 1M-Token-Limit enthält.

Der Zugriff hängt weiterhin vom gewählten Plan ab:

• Max, Team, Enterprise — 1M ist bei Opus 4.6/4.7 automatisch verfügbar, ohne Aufpreis, keine Option umzustellen
• Pro (20 $/Monat) — hier ist eine Anmeldung erforderlich: Tippe /extra-usage in Claude Code, und über die Standard-Token hinausgehende Nutzung wird über Extra-Usage-Credits abgerechnet
• API — die Abrechnung für Kontexte jenseits 200k läuft über das Long-Context-Tarifmodell; schaue vor Workflow-Entwicklung mit dem niedrigen Preis unbedingt auf die aktuelle Anthropic-Preisliste

Das Kontextfenster selbst umfasst alles, was das Modell gleichzeitig sehen kann: den System-Prompt, deine CLAUDE.md, die Verlaufshistorie, jede Datei, die Claude mit dem Read-Tool gelesen hat, sämtliche Tool-Ausgaben, jedes Glob/Grep-Ergebnis und die aktuelle Nachricht, die du gerade eingetippt hast. Alles zählt. Alles konkurriert um Aufmerksamkeit.

Dieser letzte Punkt ist entscheidend. Halte daran fest.

Die Zahl, die niemand zitiert: Context Rot beginnt bei 300k, nicht bei 1M

Das Marketingversprechen jedes Large-Context-Modells suggeriert eine gleichbleibend hohe Leistungsfähigkeit – dass Token 999.000 genauso nützlich ist wie Token 9.000. Das ist nicht der Fall. Es gibt einen publizierten Begriff für das, was tatsächlich passiert, und er sollte zum Vokabular jedes Claude-Code-Nutzers gehören.

Context rot bezeichnet den messbaren Leistungsabfall eines Modells mit wachsendem Input-Kontext. Das ist kein spezifischer Fehler von Anthropic. Chroma’s Studie 2025 testete 18 Frontier-Modelle – GPT-4.1, Claude Opus 4, Gemini 2.5, alle – und fand bei jeder gemessenen Eingabelängen-Stufe Anzeichen von context rot. Auch das Engineering-Team von Anthropic hat das offen thematisiert und vergleicht Kontextfenster mit einem „endlichen Aufmerksamkeitsbudget“, das mit jedem neuen Token schrumpft – ganz wie das Arbeitsgedächtnis eines Menschen.

Die für Claude Code entscheidende Zahl lautet: Die Leistungsdegradation ist ab etwa 300.000 bis 400.000 Tokens spürbar. Das entspricht ca. 30–40% des 1M-Limits – deutlich früher als die Werbezahlen suggerieren. Im MRCR-Multineedle-Retrieval-Benchmark liegt Opus 4.6 bei voller Million Tokens noch bei einer Genauigkeit von 76 %, was für ein Frontier-Modell ausgezeichnet ist. Aber „76 % akkurat abrufbare Daten“ sind brandgefährlich, wenn ein Agent eigenständig produktiven Code editiert. Die anderen 24 % werden früher oder später zum Problem – und zwar für Sie.

In der Praxis äußert sich context rot nur selten in so gravierenden Halluzinationen, dass sie sofort auffallen. Meist ist es leiser, subtiler. Es sind die vier unten beschriebenen Fehlermuster – und sobald Sie sie benennen können, lassen sie sich gezielt aufspüren.

Die vier Fehlermodi, die ich jetzt explizit benenne

Bevor ich den passenden Wortschatz dafür hatte, fühlte sich jeder „Claude benimmt sich seltsam“-Moment wie dasselbe vage Problem an. Heute diagnostiziere ich sie in Sekunden. Jeder Modus erfordert eine andere Lösung.

1. Kontextverschmutzung

Verschmutzung bedeutet, dass irrelevante Informationen das Signal verdrängen. Du hast ein Grep ausgeführt, das 800 Treffer zurückgegeben hat. Du hast Claude aus Vorsicht eine 4.000 Zeilen lange Logdatei lesen lassen. Du hast das gesamte node_modules-Types-Verzeichnis angehängt, weil du nicht sicher warst, in welcher Datei sich der Typ befindet. Für sich genommen ist das alles nicht verkehrt. Zusammen verwandelt es jedoch Claudes Aufmerksamkeit in eine Suppe.

Das Modell weiß nicht, was du als relevant betrachtest. Es behandelt jedes Token als potenziell entscheidend. Je mehr Rauschen du einfügst, desto mehr Denkleistung wird fürs erneute Bewerten dieses Rauschens verschwendet.

Erkennbares Anzeichen: Claude bezieht sich plötzlich auf Dateien, die du längst vergessen hast beigefügt zu haben.

2. Zielverschiebung

Zielverschiebung ist die schleichende Erosion der ursprünglichen Absicht. Du hast die Sitzung mit „Schreibe die Auth-Middleware um, sodass OAuth 2.1 unterstützt wird, alle bestehenden JWT-Flows bleiben erhalten, das User-Model darf nicht geändert werden“ begonnen. Drei Stunden später, nachdem Claude 22 Dateien gelesen, acht nicht zusammenhängende Lint-Fehler behoben und einen Logging-Helper umgebaut hat, bittest du ihn, einen neuen Claim zum JWT-Payload hinzuzufügen – und er ändert das User-Model.

Claude hat deine Vorgabe nicht ignoriert. Die Vorgabe ist einfach verblasst. Mit 400k Tokens zwischen ursprünglicher Anweisung und aktuellem Turn ist der Signal-Rausch-Abstand des System-Prompts kollabiert.

Erkennbares Anzeichen: Claude macht für die akute Aufgabe alles richtig, ignoriert aber eine Vorgabe aus dem ursprünglichen Briefing.

3. Gedächtnis-Korruption

Das ist der Modus, der mich gezwungen hat, diesen Beitrag zu schreiben. Gedächtnis-Korruption tritt auf, wenn das interne Weltmodell des Agents von der Realität abdriftet. Die Datei, von der Claude denkt, dass sie unter app/Services/UserService.php existiert, wurde in Runde 47 gelöscht. Claude verwendet immer noch die Version, die er sich gemerkt hat. Du liest seinen Plan, er wirkt schlüssig, du stimmst zu – und der Patch landet auf einer Datei, die nicht mehr existiert, oder schlimmer: auf einer veralteten Version der Datei.

Mein schlimmster Fall trat bei einem Multica-Refactoring auf: Opus hatte einen Service dreimal in der Session gepatcht, und beim vierten Patch hat er einen Diff gegen die erste Version der Datei erzeugt. Die Zwischenpatches existierten im Verlauf — sie hatten nur kein Gewicht mehr.

Erkennbares Anzeichen: Tool-Calls referenzieren Zustände, die nicht mit dem aktuellen Filesystem übereinstimmen.

4. Entscheidungsungenauigkeit

Entscheidungsungenauigkeit ist die Konsistenz-Steuer. Zu Beginn der Session hast du beschlossen: „Alle Fehler in diesem Service werfen DomainException und werden weitergereicht; der Handler loggt zu Sentry.“ Später, tief im Kontextfenster, schreibt Claude eine neue Methode, die alles als \Exception fängt, zu Log::error protokolliert und einen 500 zurückgibt.

Das ist kein falscher Code – es ist nur nicht dein Code. Andere Entscheidungen, widersprüchliche Muster, keine konsistente Design-Linie.

Erkennbares Anzeichen: Codestil und Architekturentscheidungen passen plötzlich nicht mehr zum Rest der Codebasis, obwohl Claude den Rest gelesen hat.

Jeder dieser Fehler hat seine Lösung. Keine davon lautet „ein kleineres Modell verwenden“. Es geht bei allen um deinen Umgang mit dem Fenster.

Die fünf Strategien, die ich täglich einsetze

Wenn eine Claude Code-Session die 300k-Token-Grenze überschreitet – oder ich eines der vier oben genannten Fehlerbilder erkenne – habe ich fünf Optionen. Die Kunst liegt darin, zu wissen, welche man wählt. Sie sind nicht austauschbar.

Option 1: Weiterarbeiten (und warum ich das fast nie tue)

Der Standard-Move: Einfach weitermachen. Die Versuchung ist groß, denn man ist „im Flow“ und die Wechselkosten erscheinen hoch.

Ich entscheide mich dafür fast nie mehr, es sei denn, ich bin unter 300k Tokens UND die Arbeit ist oberflächlich (Single-File, Single-Concern). Jenseits dieser Marke ist Weitermachen Glücksspiel – jeder neue Schritt verstärkt den Context Rot. Die Kosten eines fehlerhaften Patches im Produktbetrieb übersteigen bei weitem die Kosten, die Session zu pausieren und den Kontext zurückzusetzen.

Option 2: Kompaktieren – aber manuell

/compact fasst die bestehende Konversation zu einer kürzeren Zusammenfassung zusammen und macht weiter. Theoretisch ist das die Zauberformel gegen Kontextaufblähung. In der Praxis ist Autokompakt – also die Version, die automatisch beim Erreichen der Kontextfenster-Grenze ausgelöst wird – unzuverlässig. Claudes Kompaktierungslogik priorisiert jüngste Beiträge und kann dabei unbemerkt älteren, wichtigen Kontext entfernen: das ursprüngliche Briefing, Architekturentscheidungen, die Vorgaben aus Nachricht drei.

Ich lasse also niemals Autokompakt automatisch laufen. Ich führe /compact immer manuell und proaktiv um den 300k-Punkt herum aus und gebe explizite Anweisungen, was erhalten bleiben soll:

/compact Preserve: (1) das originale Briefing am Anfang der Session,
(2) alle Architekturentscheidungen aus den Durchgängen 1–15,
(3) die Liste aller bereits modifizierten Dateien samt Begründung,
(4) jede Vorgabe, die mit "DO NOT" oder "MUST" beginnt.
Drop: Tool-Ausgabe-Inhalte, Zwischenergebnisse von Grep, Dateilesungen, die nicht wieder benötigt werden.

Diese eine Anweisung verändert die Qualität der Kompaktierung dramatisch. Jetzt geht es nicht mehr um „Chat zusammenfassen“, sondern um das Erstellen eines strukturierten Übergabedokuments. Das ist ein gewaltiger Unterschied.

Option 3: Löschen und Neustart

/clear löscht den Kontext komplett. Das ist die Nuklearoption – und gleichzeitig öfter die richtige Wahl, als ich früher dachte.

Ich nutze /clear, wann immer ich zu wirklich unabhängiger Arbeit wechsle – etwa wenn nach dem Abschluss des Auth-Refactors an einen Billing-Webhook-Fix gearbeitet wird. Es bringt keinerlei Vorteil, den Auth-Kontext in die Billing-Session zu übernehmen, vielmehr gibt es massive Nachteile (Verschmutzung, Driften, sämtliche der oben beschriebenen Probleme).

Der Fehler, den die meisten mit /clear machen, ist, dies als Scheitern zu betrachten. Das ist es nicht. Eine frische 12k-Token-Session mit fokussierter Arbeit ist jeder abgestandenen 600k-Token-Session mit diffuser Logik überlegen – jedes Mal.

Option 4: Clear + JSON Save (mein Standard bei komplexer Arbeit)

Das ist meine bevorzugte Strategie. Bevor ich den Kontext lösche, lasse ich Claude eine strukturierte JSON-Datei schreiben, die den Stand der Arbeit so dokumentiert, dass ich eine frische Session nahtlos wieder anstoßen kann. Zum Beispiel so:

{
  "objective": "Auth-Middleware auf OAuth 2.1 migrieren und dabei JWT-Flows erhalten",
  "constraints": [
    "app/Models/User.php darf nicht geändert werden",
    "Alle neuen Endpunkte müssen das Präfix /api/v1 behalten",
    "Bestehende JWT-Consumer müssen weiterhin funktionieren"
  ],
  "files_modified": [
    {"path": "app/Http/Middleware/Authenticate.php", "status": "complete"},
    {"path": "app/Services/Auth/OAuthHandler.php", "status": "in-progress"}
  ],
  "open_decisions": [
    "Strategie für Refresh Token Rotation noch offen",
    "Es muss geklärt werden, ob altes JWT-Format einen Deprecation-Header bekommt"
  ],
  "next_step": "Implementiere die Refresh-Token-Rotation in OAuthHandler::refresh()"
}

Dann führe ich /clear aus, starte eine neue Session und die erste Nachricht lautet: „Lies .claude/state.json, bestätige, dass du das aktuelle Ziel und die Vorgaben verstehst, und fahre dann beim next_step fort.“

Diese Übergabe ist um Welten zuverlässiger als jedes /compact, das ich je ausprobiert habe. Die neue Session startet vielleicht mit 15k Tokens und perfektem Signal. Kein Driften, kein beschädigtes Gedächtnis, keine halb erinnerten Vorgaben.

Option 5: Subagents für alles, was den Kontext fluten könnte

Subagents sind Claude Codes Ausweg für Aufgaben, die sonst riesige Tool-Ausgaben ins Haupt-Kontextfenster spülen würden. Der Agent arbeitet im eigenen isolierten Kontext-Window, erledigt die Aufgabe und gibt nur das Endergebnis an die Hauptsession zurück.

Der mentale Test, den ich verwende – und den auch das Team von Anthropic nutzt – lautet: „Werde ich diese Tool-Ausgabe nochmal benötigen, oder reicht mir das Fazit?“

Nur das Fazit nötig? Subagent einsetzen. Beispiele:

• „Durchsuche den gesamten Codebestand nach allen Stellen, an denen das Legacy-Zahlungsgateway aufgerufen wird, und liefere Dateilisten sowie Zeilennummern zurück.“ – ideale Subagent-Aufgabe. Das Grep-Resultat würde sonst 40k Tokens im Hauptkontext fressen. Die finale Liste umfasst 200 Tokens.
• „Lies diese 12 Dokumentationsseiten und teile mir mit, auf welcher die Rate-Limit-Info steht.“ – Subagent. Die 12 Seiten würden den Kontext verschmutzen. Die Antwort passt in einen Satz.
• „Führe die Test-Suite aus und berichte nur die fehlgeschlagenen Fälle mit Stack Traces.“ – Subagent. Die 8.000 Zeilen Pass-Ausgabe braucht man nicht.

Ich richte diese als echte Claude Code Subagents in .claude/agents/ ein, damit das Orchestrieren wiederholbar ist. Beim ersten Mal, als ich eine 90-minütige Session im Nachhinein mit Subagents für suchintensive Schritte ausgestattet habe, sank der Hauptkontext von 400k auf 90k – und Opus blieb während des gesamten Jobs fokussiert und leistungsstark.

Die drei Praktiken, die wichtiger sind als jede Eingabe

Neben den fünf Optionen gibt es drei Gewohnheiten, die im Alltag den größten Unterschied machen. Keine davon ist spektakulär.

Zurückspulen statt Nachprompten

Wenn Claude eine falsche Entscheidung trifft und du sie korrigierst, bleibt diese falsche Entscheidung für immer im Kontext. Drei Interaktionen später korrigierst du einen weiteren verwandten Fehler. Bei der zehnten Runde besteht die Unterhaltung zur Hälfte aus echter Arbeit und zur Hälfte aus „nein, nicht das, mach das stattdessen“. Das Context Rot beschleunigt sich.

Die sauberere Methode besteht darin, zurückzuspulen – die Unterhaltung auf den Stand vor dem falschen Zug zurückzusetzen und mit einer besseren, neu formulierten Anweisung erneut zu starten, die das Gelernte berücksichtigt. Claude Code erlaubt dir, vorherige Nachrichten zu bearbeiten. Nutze das. Die zurückgespulte Session ist erheblich sauberer, lässt sich besser verdichten und produziert weniger nachgelagerte Fehler.

Ich behandle das dritte „Nein, das stimmt immer noch nicht“ inzwischen als automatischen Auslöser zum Zurückspulen, nicht zum fortgesetzten Korrigieren.

Regelmäßige Zusammenfassungen sind Pflicht

Alle 50–75k Token substantieller Arbeit frage ich: „Fasse das aktuelle Ziel, die vereinbarten Rahmenbedingungen und die bisher erledigten Aufgaben zusammen.“ Maximal zwei Absätze.

Das klingt verschwenderisch. Tatsächlich ist das Gegenteil der Fall. Die Zusammenfassung zwingt Claude, sich erneut am Brief zu orientieren, was das Ziel-Drift in den folgenden Runden drastisch reduziert. Außerdem gibt sie mir eine schnelle Möglichkeit zu erkennen, wenn Claudes Verständnis bereits abdriftet – falls die Zusammenfassung falsch ist, weiß ich, dass context rot bereits eingesetzt hat und es Zeit für /compact oder /clear ist.

Sieh Zusammenfassungen als günstige Alternative zur Kompaktierung. Kompaktierung restrukturiert den Speicher, Zusammenfassungen festigen ihn.

Klare Kompaktierungsanweisungen schlagen immer das Standardverhalten

Ich habe das bereits bei Option 2 behandelt, aber es lohnt sich, es als eigene Regel hervorzuheben. Wenn du /compact ohne Anweisungen laufen lässt, vertraust du darauf, dass Claudes Standardverhalten erkennt, was in deiner Arbeit wirklich essenziell ist. Oft tut es das nicht. Die Rahmenbedingung aus Nachricht drei ist für den Zusammenfasser einfach nur Text.

Gib bei /compact immer explizit an, was erhalten bleiben, was entfernt werden und wie die Ausgabe strukturiert sein soll. Behandle es wie die Dokumentation einer Übergabe an ein Teammitglied und nicht wie einen Zauberbefehl.

So sieht das End-to-End aus: Eine echte Sitzung

Hier ist eine vereinfachte Version davon, wie eine lange Claude Code-Sitzung bei mir jetzt tatsächlich abläuft, nachdem ich diesen Zyklus einen Monat lang verfeinert habe:

1. Sitzungsbeginn — CLAUDE.md ist präzise, das Briefing steht in der ersten Nachricht, die Anforderungen sind explizit. Token-Anzahl: ~5k.
2. Erste 200k Tokens — konzentrierte Arbeit. Ich optimiere nichts. Dateien lesen, Code schreiben, Tests ausführen. Der Kontext bleibt gesund.
3. 300k-Marke — erster Checkpoint. Ich fordere eine Zusammenfassung an. Richtung wird bestätigt. Noch kein /compact, solange die Arbeit fokussiert bleibt.
4. 400k-Marke — zweiter Checkpoint. Wenn ich noch mitten in einer Aufgabe stecke, führe ich ein manuelles /compact mit expliziten Anweisungen zu Behalten/Verwerfen durch. Token-Anzahl fällt zurück auf ~80k. Weiter geht’s.
5. Alles, was >20k Tool-Output erzeugen würde — Sub-Agent. Immer.
6. Ende eines abgeschlossenen Arbeitsabschnitts — JSON-Statusdatei schreiben, /clear, neue Sitzung, Re-Priming aus JSON. Der Wechsel kostet mich 3 Minuten und bewahrt mich vor sich verstärkender context rot.
7. Erste “nein, das passt immer noch nicht”-Schleife — Pause. Analysieren, welcher der vier Fehlermodi vorliegt. Den richtigen Fix wählen. Nicht blind weiter prompten.

Das war‘s. Keine Magie. Keine neuen Tools. Nur disziplinierte Nutzung der Funktionen, die Claude Code bereits mitbringt.

Das Ergebnis: Ich führe jetzt produktive Claude Code-Sessions durch, die sich über einen gesamten Arbeitstag auf demselben Projekt erstrecken, ohne dass das Modell abschweift. Vor einem Monat kam ich nicht einmal durch einen Dienstagnachmittag, ohne eine Kaskade an Halluzinationen zu erleben.

Was ich in den ersten drei Wochen falsch gemacht habe

Ich schulde dir die ehrliche Version, wie ich das herausgefunden habe – denn ich habe auf dem Weg dorthin viel Geld verschwendet.

Ich bin davon ausgegangen, dass mehr Kontext automatisch besser ist. Ich habe absichtlich mehr Dateien in den Kontext gepackt, „damit Claude volle Sicht hat“. Falsch. Jede irrelevante Datei war eine kleine Bremse bei jedem weiteren Durchgang. Weniger ist mehr. Lies nur das, was du wirklich brauchst, nicht das, was vielleicht nützlich sein könnte.

Ich habe autocompact vertraut. Drei Wochen lang ließ ich es einfach laufen, wann es wollte. Die Verschlechterung schlich sich so langsam ein, dass ich alles Mögliche verantwortlich machte – mich selbst, meine Prompts, meine Projektstruktur – aber nie den eigentlichen Übeltäter. Beim ersten Mal, als ich autocompact deaktivierte und manuelle Kompaktierungen mit expliziten Anweisungen durchführte, war der Unterschied wie Tag und Nacht.

Ich habe Subagenten vermieden, weil mir die Orchestrierung wie zusätzlicher Aufwand erschien. Auch da lag ich falsch. Einen Search-Subagenten oder Test-Runner-Subagenten einzurichten kostet einmalig zehn Minuten. Danach ersparst du dir in jeder Session diese 50.000-Token-Tool-Dumps.

Und ich habe /clear als Niederlage betrachtet. Das ist es nicht. Eine saubere Session ist keine gescheiterte Session. Eine saubere Session ist ein Werkzeug. Nutze es.

Häufig gestellte Fragen

Wann beginnt Context Rot in Claude Code?

Context Rot in Claude Code wird ab etwa 300.000 bis 400.000 Tokens messbar — das entspricht ungefähr 30–40 % des 1M-Windows. Die Leistung bricht zu diesem Zeitpunkt nicht ein, aber Zielabweichungen, Speicherfehler und inkonsistente Entscheidungen werden deutlich wahrscheinlicher. Behandle 300k als deinen ersten Kontrollpunkt, nicht 1M als Grenze.

Sollte ich /compact oder /clear in Claude Code verwenden?

Verwende /compact, wenn die aktuelle Aufgabe noch läuft und der jüngste Kontext wirklich benötigt wird; verwende /clear, wenn du zu einer völlig anderen Aufgabe wechselst oder der Kontext so stark verschmutzt ist, dass eine Zusammenfassung immer noch zu viel Rauschen hinterließe. Für komplexe, laufende Aufgaben empfiehlt sich das Muster: Schreibe eine JSON-Zustandsdatei, führe /clear aus und starte eine frische Sitzung aus der JSON-Datei.

Kostet das 1M Context-Window in Claude Code extra?

Bei Max-, Team- und Enterprise-Plänen ist das 1M Context-Window für Opus 4.6 und Opus 4.7 ohne Aufpreis enthalten. Im Pro-Plan (20 $/Monat) musst du dich mit /extra-usage für die 1M-Option entscheiden, und Tokens oberhalb des Standard-Windows werden zu Extra-Usage-Credits abgerechnet. Die API-Preise nutzen die Langkontext-Stufe ab 200k — überprüfe die aktuellen Konditionen, bevor du deinen Workflow darauf aufbaust.

Was ist der Unterschied zwischen /compact und Sub-Agents?

/compact fasst das bestehende Gespräch in deiner aktuellen Sitzung zusammen, um Tokens freizugeben; Sub-Agents verhindern von vornherein das Aufblähen des Kontexts, indem sie Nebenaufgaben in eigenen, isolierten Kontextfenstern ausführen und nur das Endergebnis zurückgeben. Verwende Sub-Agents für alle Aufgaben, deren Tool-Ausgabe du nicht dauerhaft referenzieren musst — etwa Suche, Log-Analyse, Testläufe.

Warum beginnt Claude Code in langen Sitzungen zu halluzinieren?

Lange Claude-Code-Sitzungen halluzinieren durch Context Rot — je mehr Eingabetokens, desto dünner verteilt das Modell seine Aufmerksamkeit, und ältere Vorgaben, Dateiinhalte und Entscheidungen werden untergewichtet. Die Lösung ist nicht ein größeres Fenster, sondern aktives Management: manuelles /compact mit expliziten Anweisungen, regelmäßige Zusammenfassungen, Sub-Agents für Output-intensive Tasks und /clear+JSON-Übergaben zwischen größeren Arbeitsblöcken.

Also: Dein Terminal ist offen. Die Sitzung steht bei 280k Tokens. Opus 4.7 schlägt gerade vor, eine Datei zu bearbeiten, von der du zu 80 % sicher bist, sie vor einer Stunde gelöscht zu haben.

Was tust du in den nächsten 60 Sekunden?

Wenn deine Antwort lautet „Claude noch einmal prüfen lassen“, managst du Kontext immer noch auf die alte Weise. Wenn sie dagegen lautet „Zum letzten sauberen Turn zurückgehen, JSON-Zustandsdatei schreiben, /clear ausführen und neu starten“ — willkommen bei der Version von Claude Code, mit der du wirklich einen ganzen Arbeitstag skalieren kannst. Das 1M-Window ist real. Die Zuverlässigkeit darin ist etwas, das du aktiv gestalten musst.

Ich gestalte lieber, als dem Modell die Schuld zu geben.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io