Kontextmanagement im Claude Code

Claude Code hat jetzt ein 1-Million-Zeichen-Kontextfenster. Das ändert eine Menge. An der Grundregel ändert sich nichts: Ein größeres Fenster behebt kein schlechtes Sitzungsmanagement.

Was die Ergebnisse tatsächlich beeinflusst, ist die Entscheidung, die du nach jedem Zug triffst:

• in derselben Sitzung weitermachen
• /rewind zu einem besseren Zweig
• /clear und neu anzufangen
• /compact und die Zusammenfassung beibehalten
• den nächsten Abschnitt in einen Subagenten verschieben

Das ist die eigentliche Kontext-Management-Ebene in Claude Code. Die meisten schlechten Sitzungen werden nicht dadurch verursacht, dass das Modell schwach ist. Sie entstehen dadurch, dass der falsche Kontext zu lange mitgeführt wird.

Die offizielle Anthropic-Anleitung vom 15. April 2026 hat diesen Punkt verdeutlicht: Jeder Zug ist ein Verzweigungspunkt. Diese Seite setzt das in ein praktisches Betriebssystem um.

Schneller Erfolg

Wende diese beiden Regeln sofort an:

1. Neue Aufgabe, neue Sitzung. Wenn sich die Arbeit wesentlich geändert hat, führe „/clear“ aus oder starte eine neue „claude“-Sitzung.
2. Falscher Weg, zurückspulen statt korrigieren. Wenn Claude den falschen Zweig eingeschlagen hat, nutze „/rewind“, anstatt „das hat nicht funktioniert, versuch stattdessen dies“ auf den veralteten Kontext zu stapeln.

Wenn du dir nur diese beiden Gewohnheiten aneignest, steigt die durchschnittliche Qualität deiner Sitzungen schnell an.

Kontext, Verdichtung und Kontextverfall

Das Kontextfenster ist alles, was das Modell für seine nächste Antwort sehen kann:

• System-Prompt
• deine Konversationshistorie
• Tool-Aufrufe und -Ausgaben
• in den Kontext geladene Dateien
• geladener Speicher und Anweisungen

Claude Code kann viel mehr speichern als früher. Das bedeutet aber nicht, dass der Kontext frei ist.

Wenn der Kontext wächst, kann die Leistung nachlassen. Anthropic nennt das „Context Rot“: Die Aufmerksamkeit verteilt sich auf mehr Tokens, veraltetes Material bleibt hängen, und ältere, irrelevante Details beginnen, mit der Aufgabe zu konkurrieren, die dir gerade wichtig ist.

Wenn das Fenster zu voll wird, komprimiert Claude Code die Sitzung. Das bedeutet, dass die aktuelle Unterhaltung zu einer kürzeren Beschreibung zusammengefasst wird und die Arbeit auf der Grundlage dieser Zusammenfassung fortgesetzt wird. Nützlich, aber mit Verlusten verbunden.

Der entscheidende Fehler ist, den Kontext wie ein Archiv zu behandeln. Er ist kein Archiv. Er ist aktives Arbeitsgedächtnis.

Jeder Zug ist ein Verzweigungspunkt

Sobald Claude einen Zug beendet hat, stehen dir mehrere gültige Züge zur Verfügung. Der richtige hängt davon ab, ob der aktuelle Kontext noch tragfähig ist.

Wenn du dir eine Tabelle von dieser Seite merken willst, dann nimm diese.

Fünf alltägliche Szenarien

Hier kommen die Abstraktionen zum Einsatz. Die meisten realen Sitzungen passen in eines dieser Muster.

1. Die Implementierung einer Funktion wird zur Dokumentation

Du hast gerade die Auth-Middleware fertiggestellt und möchtest nun Migrationshinweise und Dokumentation für genau diese Änderung.

Beste Vorgehensweise: Mach in derselben Sitzung weiter

Warum: Der Code, die Entscheidungen und die Randfälle sind immer noch nützlich. Diesen Zustand neu aufzubauen, würde nur Zeit kosten.

2. Claude hat den falschen Implementierungsweg gewählt

Er hat die richtigen Dateien gelesen, sich dann aber für einen Ansatz entschieden, der nicht zur Codebasis passt.

Beste Vorgehensweise: „/rewind“

Warum: Behalte die nützlichen Erkenntnisse, verwerfe den fehlgeschlagenen Zweig.

3. Eine Aufgabe, zu viele Debugging-Reste

Du arbeitest immer noch an derselben Funktion, aber die Sitzung ist voller Fehlstarts und Logs, die in eine Sackgasse führen.

Beste Vorgehensweise: „/compact“ mit einem Hinweis

Warum: Die Aufgabe ist immer noch dieselbe; die Sitzung muss nur etwas ausgedünnt werden.

4. Du wechselst vom Programmieren zur Roadmap-Planung

Verwandter Bereich, andere Aufgabenform.

Beste Vorgehensweise: „/clear“ oder eine neue Sitzung starten

Warum: Die Überbleibsel der Umsetzung sind jetzt größtenteils nur noch Störfaktoren.

5. Du brauchst eine umfassende Überprüfung, aber nur das Ergebnis zählt

Du möchtest eine Nebenuntersuchung in einem anderen Repo, eine Spezifikationsprüfung oder eine umfassende Suche.

Beste Vorgehensweise: subagent

Warum: Halte das Zwischenrauschen aus dem übergeordneten Thread heraus.

Wann du in derselben Sitzung bleiben solltest

Bleib in derselben Sitzung, wenn:

• es sich immer noch um dieselbe Aufgabe handelt
• die Dateien, die Claude gerade gelesen hat, noch direkt relevant sind
• die aktuelle Argumentationskette noch nützlich ist
• das erneute Einlesen von allem langsamer und aufwendiger wäre als die Fortsetzung

Klassisches Beispiel: Du hast gerade eine Funktion implementiert und möchtest nun, dass Claude die Dokumentation genau für diese Funktion schreibt. Ein Neuanfang wäre möglich, aber Claude müsste den Code, den er bereits im Kontext hat, erneut lesen. Wenn die Aufgabe eng damit zusammenhängt und die aktuelle Sitzung noch übersichtlich genug ist, ist es sinnvoll, fortzufahren.

Die Frage lautet nicht „Ist das damit verbunden?“, sondern „Ist der aktuelle Kontext noch hilfreich?“

Wann man eine neue Sitzung starten sollte

Anthropics Faustregel ist einfach: Wenn du eine neue Aufgabe beginnst, solltest du auch eine neue Sitzung starten.

Fang neu an, wenn:

• du von einer Funktion zu einer anderen gewechselt bist
• die Sitzung viele Debugging- oder Erkundungsaktivitäten enthält
• der vorherige Arbeitszweig abgeschlossen ist
• die nächste Aufgabe andere Dateien, andere Ziele oder andere Einschränkungen erfordert

Das ist selbst bei 1M Kontext wichtig. Das größere Fenster gibt dir mehr Spielraum vor der Komprimierung. Es macht irrelevanten Kontext jedoch nicht harmlos.

Gute Beispiele für einen Wechsel in eine neue Sitzung:

• Die Auth-Refactoring ist abgeschlossen, jetzt geht es an die Abrechnung
• Implementierung abgeschlossen, jetzt Roadmap-Planung
• 40 Minuten mit der Fehlerbehebung verbracht, wechsle jetzt zu einem anderen Problem

Wenn du Kontinuität brauchst, schreibe eine kurze Übergabe in die erste Eingabeaufforderung der neuen Sitzung:

We just finished the auth middleware refactor.
What matters for this new task:
- the session format stayed unchanged
- files that matter now are X and Y
- we ruled out approach Z

New task: write the migration notes and docs.

Das ist oft übersichtlicher, als die gesamte alte Sitzung mitzunehmen.

Zurückspulen statt korrigieren

/rewind ist eines der wirkungsvollsten Tools für das Sitzungsmanagement in Claude Code und eines der am wenigsten genutzten.

Wenn Claude eine Reihe von Dateien liest, den falschen Ansatz wählt und du darauf reagierst mit:

That didn't work. Try B instead.

behältst du den fehlgeschlagenen Versuch, seine Begründung und deine Korrektur alle im selben Kontext. Manchmal ist das in Ordnung. Oft ist es aber nur Verunreinigung.

Besseres Muster:

1. Spule zurück bis zu dem Punkt direkt nach der nützlichen Erkundung
2. behalte die wertvollen Dateilesevorgänge
3. Lass den fehlgeschlagenen Zweig fallen
4. Starte von dort aus neu mit dem, was du gelernt hast

Beispiel:

Don't use approach A. The foo module does not expose that.
Go straight to approach B using the existing adapter in src/lib/foo.ts.

Dadurch erhält Claude den nützlichen Kontext, ohne dass der schlechte Zweig darüber gestapelt wird.

Zurückspulen ist am besten, wenn:

• die Erkundung nützlich war
• die versuchte Umsetzung falsch war
• du etwas Konkretes gelernt hast
• du die Nachweise behalten möchtest, aber nicht den Fehlpfad

/compact vs. „/clear“

Diese sind nicht austauschbar.

Verwende „/compact“, wenn:

• es sich immer noch um dieselbe Aufgabe handelt
• die Sitzung überladen ist
• du möchtest, dass Claude die wichtigen Erkenntnisse beibehält
• die Arbeit in derselben Richtung weitergeht

Du kannst die Komprimierung steuern:

/compact focus on the auth refactor, drop the test debugging

Das ist besonders nützlich, da dir der 1-M-Kontext nun mehr Zeit gibt, proaktiv zu komprimieren, bevor das Modell seinen schlechtesten Kontextzustand erreicht.

Verwende „/clear“, wenn:

• es sich um eine neue Aufgabe handelt
• du dem aktuellen Kontext nicht mehr vertraust
• du die volle Kontrolle darüber haben willst, was erhalten bleibt
• du den Übergang lieber selbst schreiben möchtest, anstatt einer unvollständigen Zusammenfassung zu vertrauen

Der Unterschied ist einfach:

• /compact bittet Claude zu entscheiden, was wichtig war
• /clear lässt dich entscheiden, was wichtig war

Was führt zu einem schlechten Compact

Anthropics Erklärung ist hier hilfreich: Schlechte Zusammenfassungen entstehen oft, wenn das Modell nicht vorhersagen kann, in welche Richtung deine Arbeit als Nächstes geht.

Beispiel:

1. Du verbringst eine lange Sitzung damit, ein Problem zu beheben
2. Autocompact wird ausgelöst
3. die Zusammenfassung konzentriert sich auf diesen Debugging-Pfad
4. deine nächste Eingabe wechselt zu einem anderen, aber verwandten Problem
5. die von dir gewünschten Details wurden weggelassen, weil die Zusammenfassung sie für unwichtig hielt

Deshalb ist manuelles „/compact“ in vielen praktischen Anwendungsfällen besser als passives „autocompact“. Du kannst Claude vor der Zusammenfassung mitteilen, in welche Richtung es weitergehen soll.

Eine nützliche Regel:

• Wenn du die nächste Phase kennst, fasse zusammen**, bevor** Claude sie erraten muss

Schlecht:

• 45 Minuten lang debuggen
• Lass die automatische Verdichtung laufen
• dann plötzlich umschwenken

Besser:

• die Debugging-Phase abschließen
• /compact focus on the fix plan and the files that matter next ausführen
• mit der Implementierung fortfahren

Die zu vermeidenden Anti-Patterns

Schlechtes Kontextmanagement ist meist nicht dramatisch. Es ist nur eine Reihe kleiner, nachlässiger Entscheidungen.

Achte auf Folgendes:

• Eine einzige Marathon-Sitzung für nicht zusammenhängende Aufgaben nutzen
• Einen fehlerhaften Zweig korrigieren, anstatt ihn zurückzusetzen
• Warten auf Autocompact, obwohl du die nächste Phase bereits kennst
• Lärmende Recherchen in der übergeordneten Sitzung zulassen
• „Verwandt“ als ausreichenden Grund anzusehen, um weiterzumachen

Das sind die Gewohnheiten, die ein starkes Modell inkonsistent erscheinen lassen.

Verwende Subagenten, um Zwischenrauschen fernzuhalten

Subagenten sind nicht nur ein Delegationswerkzeug. Sie sind ein Werkzeug zur Kontextverwaltung.

Der anthropische Gedankentest ist überzeugend:

Brauche ich diesen Zwischenergebnis noch einmal oder nur die Schlussfolgerung?

Wenn die Antwort „nur die Schlussfolgerung“ lautet, ist ein Subagent oft die sauberere Lösung.

Gute Kandidaten für Subagenten:

• eine andere Codebasis lesen und ein Muster zusammenfassen
• eine Implementierung anhand einer Spezifikation überprüfen
• Dokumentation aus deinem Git-Diff erstellen
• eine umfassende Suche durchführen, die den Hauptthread nicht überladen soll
• führen eine gezielte Prüfung durch und berichten darüber

Warum das funktioniert:

• Das Kind erhält ein neues Kontextfenster
• Es kann eine Menge Zwischenergebnisse generieren
• nur die endgültige Zusammenfassung wird an den Elternprozess zurückgesendet

Das ist eine der einfachsten Möglichkeiten, eine Hauptsitzung länger nutzbar zu halten.

Die praktischen Sitzungsregeln

Wenn du ein kompaktes Playbook willst, nutze dieses:

Regel 1: Neue Aufgabe, neue Sitzung

Verwandt ist nicht dasselbe wie gleich.

Regel 2: Falscher Zweig, zurückspulen

Stapele keine Korrekturen auf einen fehlgeschlagenen Pfad, wenn der fehlgeschlagene Pfad selbst nun nur noch Rauschen ist.

Regel 3: Gleiche Aufgabe, aufgeblähter Kontext, mit einem Hinweis komprimieren

Warte nicht auf die automatische Komprimierung, wenn du bereits weißt, was erhalten bleiben soll.

Regel 4: Wenn der nächste Schritt verrauscht ist, benutze einen Subagenten

Behalte den übergeordneten Kontext für Entscheidungen, nicht für die Erschöpfung.

Regel 5: Größerer Kontext bedeutet weniger erzwungene Resets, nicht gar keine Resets

1M-Kontext ist ein echtes Upgrade. Es ist keine Immunität.

Was sich durch den 1-M-Kontext tatsächlich geändert hat

Das 1-Million-Fenster hat die Wirtschaftlichkeit des Sitzungsmanagements in dreierlei Hinsicht verändert:

1. weniger erzwungene Komprimierungen
2. mehr Platz für längere zusammenhängende Aufgaben
3. mehr Zeit, proaktiv zu komprimieren, bevor es chaotisch wird

Es hat nichts an der Notwendigkeit geändert:

• bei neuen Aufgaben von vorne anzufangen
• schlechte Verzweigungen zurückzuverfolgen
• vermeiden, dass sich veraltete Debugging-Arbeiten durch nicht damit zusammenhängende Arbeit ziehen
• störende Arbeit an Subagenten zu delegieren

Das größte Missverständnis nach der Veröffentlichung von 1M Context war: „Ich kann jetzt alles in einer Sitzung behalten.“ Technisch gesehen sind längere Sitzungen möglich. Praktisch gesehen willst du aber immer noch klarere Grenzen als das.

/usage und Was zu beachten ist

Anthropic sagt, der neue Befehl „/usage“ sei durch Kundengespräche über lang laufende Sitzungen und das neue 1-Million-Fenster inspiriert worden. Das trifft das eigentliche Problem: Die meisten Nutzer brauchen nicht nur mehr Kontext, sie brauchen auch einen besseren Überblick darüber, wie sie ihn nutzen.

Bei alltäglichen Entscheidungen solltest du auf drei Dinge achten:

• ob die aktuelle Aufgabe noch dieselbe ist
• ob der aktuelle Kontext noch hilfreich ist
• ob der nächste Schritt detaillierte Zwischenergebnisse erfordert oder nur die Schlussfolgerung

Das ist umsetzbarer, als sich nur auf die reine Anzahl der Token zu versteifen.

Eine bessere Gewohnheitsschleife für den Kontext

Wende diese Abfolge an einem echten Arbeitstag an:

1. Beginne eine Sitzung mit einer klaren Aufgabe
2. Mach weiter, solange der aktuelle Kontext noch nützlich ist
3. spule zurück, wenn ein Zweig schiefgeht
4. Fasse bei natürlichen Phasenwechseln zusammen, mit einem Hinweis
5. Lösche die Sitzung, wenn sich die Aufgabe ändert
6. Erzeuge Unteragenten für störende Nebenaufgaben

Das ist das Betriebsmodell.

Ein 30-Sekunden-Entscheidungstest

Wenn du dir unsicher bist, was als Nächstes zu tun ist, stell dir drei Fragen:

1. Ist das immer noch dieselbe Aufgabe?
2. Ist der aktuelle Kontext immer noch eher hilfreich als hinderlich?
3. Werde ich das Zwischenergebnis des nächsten Schritts später noch brauchen?

Wenn die Antworten lauten:

• Ja / Ja / Ja -> weitermachen
• ja / nein / ja -> komprimieren
• ja / ja / nein -> Unteragent
• nein / nein / vielleicht -> löschen und neu starten

Das reicht normalerweise aus, um die richtige Entscheidung zu treffen, ohne zu viel darüber nachzudenken.

Quellen

• Claude-Code verwenden: Sitzungsverwaltung und 1M-Kontext
• Subagenten – Claude-Dokumentation

Verwandte Seiten

• 1M-Kontextfenster in Claude Code
• Kontextpuffer-Verwaltung
• Kontext-Engineering
• Dynamischer Startkontext