Kontextmanagement in Claude Code: /context, /compact, CLAUDE.md und Obsidian

Du beginnst eine Claude-Code-Sitzung mit einer klaren Aufgabe. Eine Stunde später liest Claude dieselben Dateien noch einmal, greift eine längst verworfene Entscheidung auf oder übersieht die Korrektur aus deiner letzten Nachricht. Gerade am Anfang wirkt das so, als sei das Modell plötzlich schlechter geworden.

Häufig liegt es aber an einem überfüllten Kontextfenster. Gesprächsverlauf, gelesene Dateien, Befehlsausgaben, Projektregeln und Antworten teilen sich einen begrenzten Arbeitsbereich. Wenn darin alte Fehlversuche und lange Logs liegen, konkurrieren sie mit den Fakten, die für den nächsten Schritt zählen.

Kontextmanagement bedeutet deshalb mehr als Token zu sparen. Du entscheidest bewusst, was Claude für die aktuelle Aufgabe braucht, welche Regeln dauerhaft im Projekt stehen müssen, was zusammengefasst werden kann und wann eine neue Sitzung sinnvoller ist. Die folgenden Abläufe funktionieren auch dann, wenn Begriffe wie Kontextfenster oder Auto Memory noch neu für dich sind.

Die wichtigsten Entscheidungen auf einen Blick

• Nutze /context, bevor du vermutest, warum eine Sitzung unübersichtlich geworden ist.
• Nutze /compact, wenn die Aufgabe gleich bleibt, aber Recherche, Dateiinhalte und Logs zu viel Platz belegen.
• Nutze /clear, wenn du zu einer anderen Aufgabe wechselst. Die vorherige Unterhaltung bleibt gespeichert und kann später fortgesetzt werden.
• Nutze /memory, um dauerhafte Projektanweisungen und Auto Memory zu verwalten. Ob sie tatsächlich geladen wurden, prüfst du mit /context.
• Nutze /usage für Kosten, Planlimits und Aktivität. /cost ist ein Alias dafür; /stats führt ebenfalls zu /usage und öffnet den Statistikbereich.
• Halte vor jeder Komprimierung fest, welche Entscheidung gilt, welche Dateien geändert wurden und welcher Prüfschritt als Nächstes folgt.

Das Kontextfenster ist der aktuelle Arbeitstisch

Das Kontextfenster umfasst alle Informationen, die Claude im aktuellen Schritt berücksichtigen kann. Ein aufgeräumter Arbeitstisch enthält zum Beispiel die Aufgabe, zwei relevante Dateien, eine kurze Fehlermeldung und das Abnahmekriterium. Auf einem überfüllten Tisch liegen dagegen verworfene Lösungswege, vollständige Build-Logs, doppelte Dateiausgaben und widersprüchliche Regeln.

Nicht nur der sichtbare Chat belegt diesen Platz:

Quelle	Wie unnötiger Ballast entsteht	Bessere Gewohnheit
Gesprächsverlauf	Nebenfragen und überholte Entscheidungen bleiben erhalten	Unabhängige Aufgaben trennen und die gültige Entscheidung notieren
Gelesene Dateien	Ganze Verzeichnisse oder generierte Dateien werden geladen	Erst suchen, dann nur passende Dateien oder Abschnitte lesen
Werkzeugausgaben	Wiederholte Tests und lange Logs sammeln sich an	Ursache und Endergebnis festhalten, Wiederholungen weglassen
CLAUDE.md und Regeln	Breite oder doppelte Vorgaben werden ständig geladen	Allgemeine Regeln kurz halten, Sonderabläufe auslagern
Skills und Werkzeuge	Jede aktivierte Fähigkeit bringt Beschreibungen mit	Nur die für die Aufgabe nötigen Fähigkeiten verwenden

Claude Code kann automatisch komprimieren, wenn sich das Fenster seiner Grenze nähert. Dadurch bricht die Sitzung nicht einfach ab. Die automatische Zusammenfassung muss jedoch selbst auswählen, was wichtig ist. Vor einem klaren Phasenwechsel ist eine manuelle Komprimierung mit einem konkreten Fokus zuverlässiger.

Was die einzelnen Befehle tatsächlich tun

Die Befehle sehen ähnlich aus, lösen aber verschiedene Probleme. Gib sie in einer interaktiven Claude-Code-Sitzung jeweils am Anfang einer Nachricht ein.

/context: Belegung untersuchen

/context zeigt die aktuelle Nutzung als farbige Übersicht und nennt Hinweise zu speicherintensiven Werkzeugen, umfangreichen Memory-Dateien und knapper Kapazität. Mit /context all erhältst du eine ausführlichere Aufschlüsselung.

/context
/context all

Führe den Befehl zu Beginn einer langen Aufgabe, nach einer größeren Recherche und vor /compact aus. Er entfernt nichts. Er zeigt dir lediglich, welche Bestandteile Platz beanspruchen und welche Fakten du in der nächsten Zusammenfassung hervorheben solltest.

/compact [Anweisungen]: zusammenfassen und dieselbe Aufgabe fortsetzen

/compact ersetzt den bisherigen Gesprächsverlauf durch eine strukturierte Zusammenfassung. Der Text hinter dem Befehl legt fest, was darin besonders sichtbar bleiben soll.

/compact Behalte den akzeptierten API-Vertrag, geänderte Dateien, den fehlschlagenden Test, bereits ausgeführte Befehle und den nächsten Schritt bei

Der Befehl passt, wenn das Ziel unverändert ist. Beispiel: Du behebst weiterhin denselben Authentifizierungsfehler, aber die Ursachenanalyse hat eine lange Unterhaltung erzeugt. Verlasse dich nicht darauf, dass jede Einzelheit erhalten bleibt. Unverzichtbare Regeln gehören bereits in CLAUDE.md, eine Spezifikation oder eine Übergabenotiz.

/clear [Name]: eine neue Unterhaltung beginnen

/clear startet eine Unterhaltung mit leerem Gesprächskontext. Optional kannst du der bisherigen Unterhaltung einen Namen geben.

/clear auth-fehler-abgeschlossen

Projekt-Memory wird für die neue Unterhaltung wieder geladen. Die alte Unterhaltung wird nicht gelöscht, sondern bleibt für /resume, claude --resume oder claude --continue gespeichert. Verwende /clear, wenn Ziel, betroffene Dateien und Entscheidungshistorie der nächsten Aufgabe wirklich unabhängig sind.

/memory: dauerhafte Hinweise verwalten

/memory listet Speicherorte von CLAUDE.md und CLAUDE.local.md, ermöglicht deren Bearbeitung und zeigt Auto-Memory-Einträge. Der Befehl beantwortet die Frage: “Wo soll diese wiederverwendbare Information liegen?”

/memory

Er beweist nicht, dass jede angezeigte Datei gerade aktiv ist. Prüfe dafür mit /context den Bereich für Memory-Dateien. Eine versionierte Projekt-CLAUDE.md kann das Team teilen. Auto Memory enthält dagegen lokale, repositorybezogene Erkenntnisse; sie gelten über Worktrees desselben Repositorys, aber nicht automatisch auf anderen Rechnern.

/usage, /cost und /stats: Verbrauch statt Kontext prüfen

/usage zeigt Sitzungskosten, Planlimits und Aktivitätsdaten. In unterstützten Abonnements kann die Ansicht den Verbrauch zusätzlich nach Skills, Subagents, Plugins und MCP-Servern aufteilen. /cost ist ein Alias für /usage. /stats ist ebenfalls ein Alias und öffnet dabei den Statistikbereich.

/usage
/cost
/stats

Diese Werte beantworten nicht dieselbe Frage wie /context: Die Verbrauchsansicht zeigt bereits genutzte Ressourcen und Limits; die Kontextansicht zeigt den Inhalt des aktuellen Arbeitsfensters. Komprimieren oder Leeren macht bereits entstandenen Verbrauch nicht rückgängig.

Die Entscheidung nach der Prüfung lässt sich auf eine einfache Frage reduzieren:

flowchart TD
  A["/context ausführen"] --> B{"Bleibt die Aufgabe gleich?"}
  B -->|Ja| C["/compact mit Fokus"]
  B -->|Nein| D["/clear und neues Briefing"]

Solange Ziel und Abnahmekriterium gleich bleiben, räumt /compact den Arbeitsbereich auf. Sobald eine unabhängige Aufgabe beginnt, verhindert /clear, dass alte Entscheidungen die neue Arbeit beeinflussen.

Vor dem Start ein Kontextbudget festlegen

Eine unklare Bitte wie “Lies das ganze Repository und repariere es” lädt meist zu viel Material. Gib Claude stattdessen ein kurzes Arbeitsbriefing mit Ziel, Umfang, Ausschlüssen, Abnahmekriterium und Prüfbefehl.

## Arbeitsbriefing
- Ziel: Die Weiterleitungsschleife bei abgelaufenen Sitzungen beheben.
- Im Umfang: src/auth/, tests/auth/session.test.ts
- Nicht im Umfang: neues UI und Wechsel des Identity-Providers
- Fertig, wenn: Abgelaufene Sitzungen genau einmal zu /login führen und der Regressionstest grün ist
- Prüfen mit: npm test -- tests/auth/session.test.ts
- Menschliche Freigabe nötig für: Cookie-Laufzeit oder Änderung der öffentlichen API

Suche anschließend eng, bevor du Dateien vollständig laden lässt. Diese Befehle kannst du kopieren und an dein Repository anpassen:

rg -n "expired session|redirect loop|set-cookie" src tests
git diff --stat
git status --short
npm test -- tests/auth/session.test.ts

Die Reihenfolge ist wichtig. rg grenzt die Kandidaten ein. git diff --stat und git status zeigen bestehende Änderungen, die nicht überschrieben werden dürfen. Der gezielte Test liefert ein messbares Ende. So braucht Claude nur wenige relevante Artefakte statt einer vollständigen Repository-Kopie.

Vor der Komprimierung eine Übergabenotiz schreiben

Schreibe vor /compact, /clear oder der Übergabe an eine andere Sitzung eine kurze Notiz. Sie soll nicht das gesamte Gespräch wiederholen, sondern genau den Zustand enthalten, den eine andere Person oder ein Agent für die Fortsetzung benötigt.

## Übergabenotiz
- Ziel:
- Aktuelle Diagnose:
- Bereits akzeptierte Entscheidungen:
- Geänderte Dateien:
- Ausgeführte Befehle und Ergebnisse:
- Uncommittete Änderungen, die erhalten bleiben müssen:
- Verbleibendes Risiko:
- Nächster Schritt:

Speichere die Notiz in einem Projektdokument, wenn sie geteilt werden soll. Alternativ kannst du die ausgefüllte Fassung als Fokus hinter /compact einfügen. Schreibe Ergebnisse statt Rohdaten: “Test scheitert in session.test.ts:84 wegen zweier Redirects” hilft weiter; zweihundert nahezu identische Stacktrace-Zeilen nicht.

Welche Informationen eine Komprimierung überstehen

Nach /compact werden verschiedene Arten von Informationen unterschiedlich behandelt:

Mechanismus	Verhalten nach /compact
Systemanweisung und Ausgabestil	Bleiben unverändert, weil sie nicht zum Gesprächsverlauf gehören
CLAUDE.md im Projektstamm und Regeln ohne Pfadfilter	Werden erneut von der Festplatte eingefügt
Auto Memory	Wird erneut eingefügt
Regeln mit paths: im Frontmatter	Fehlen, bis Claude wieder eine passende Datei liest
Verschachtelte CLAUDE.md in Unterverzeichnissen	Fehlen, bis eine Datei aus dem betreffenden Verzeichnis gelesen wird
Aufgerufene Skill-Inhalte	Werden innerhalb der dokumentierten Einzel- und Gesamtgrenzen erneut eingefügt
Hooks	Laufen weiterhin als Code und sind kein Gesprächskontext

Besonders empfindlich sind Fakten, die nur einmal im Chat genannt wurden. Sie können in der Zusammenfassung auftauchen, feine Details können aber entfallen. Muss eine Regel immer gelten, gehört sie in die CLAUDE.md im Projektstamm oder eine andere passende, dauerhafte Datei.

Du kannst den Fokus der Komprimierung zusätzlich in CLAUDE.md festlegen:

# CLAUDE.md

## Anweisungen für die Komprimierung
- Ziel, akzeptierte Entscheidungen und ausgeschlossene Bereiche beibehalten.
- Geänderte Dateien, Prüfkommandos, Testergebnisse und Blocker beibehalten.
- Nur Logzeilen behalten, die die Ursache erklären.
- Uncommittete Änderungen anderer Personen und die nächste sichere Aktion beibehalten.

Halte diesen Abschnitt kurz. CLAUDE.md selbst belegt zu Beginn jeder Unterhaltung Kontext. Eine vollständige Projektdokumentation an dieser Stelle würde genau das Problem neu erzeugen, das du lösen willst.

Aufgaben des Agenten und Freigaben durch Menschen

Claude kann suchen, Dateien vergleichen, Logs verdichten, Tests ausführen und beobachtete Fakten dokumentieren. Entscheidungen mit nicht ableitbaren Folgen bleiben beim Menschen.

Claude Code kann übernehmen	Ein Mensch muss entscheiden
Relevante Dateien finden und Logs auf die Ursache reduzieren	Geschäftsziel und akzeptable Kompromisse festlegen
Kontextdruck melden und eine Komprimierung vorschlagen	Entscheiden, ob zwei Aufgaben wirklich zusammengehören
Eine Übergabenotiz aus beobachteter Arbeit erstellen	Destruktive Aktionen, Zugangsdaten und Produktionsänderungen freigeben
Vereinbarte Prüfkommandos ausführen	Änderungen an Sicherheitsrichtlinien, öffentlichem Verhalten oder Datenspeicherung akzeptieren
Eine Regel nach ausdrücklicher Freigabe aktualisieren	Widersprüchliche Anforderungen von Beteiligten auflösen

Bitte den Agenten nicht, allein zu entscheiden, was niemals verloren gehen darf, und lasse diese Entscheidung anschließend nur im selben überfüllten Chat stehen. Der Mensch benennt die dauerhaften Grenzen; der Agent trägt sie am vereinbarten Ort ein und prüft, ob sie geladen werden.

Vier konkrete Anwendungsfälle

Anwendungsfall 1: Authentifizierung über mehrere Dateien umbauen

Situation: Die Recherche berührt Middleware, Cookie-Helfer, Integrationstests und Deployment-Einstellungen. Alle Dateien und jeder fehlgeschlagene Test in einer Unterhaltung erschweren die eigentliche Änderung.

Agentenbereich: Mit einer Suche den Authentifizierungsweg abbilden, umfangreiche Dokumentationsrecherche getrennt erledigen und nur den gewählten Vertrag, die Zieldateien und den relevanten Test im Hauptkontext behalten.

Menschliche Freigabe: Cookie-Laufzeit, Logout-Verhalten und Kompatibilitätszusagen. Das sind Produkt- und Sicherheitsentscheidungen.

Ablauf: Arbeitsbriefing schreiben, nach der Analyse /context ausführen, den akzeptierten Entwurf in der Übergabenotiz festhalten und vor der Implementierung gezielt komprimieren.

Anwendungsfall 2: Fehlgeschlagenes Deployment untersuchen

Situation: Mehrere Versuche erzeugen fast identische Logs. Die erste ursächliche Fehlermeldung geht zwischen Installationsausgaben und Warnungen unter.

Agentenbereich: Versuche vergleichen, den ersten kausalen Fehler finden und Umgebung sowie exakten Befehl notieren. Doppelte Ausgabe gehört nicht in die Zusammenfassung.

Menschliche Freigabe: Änderungen an Zugangsdaten, Provider-Konfiguration oder Rollback. Claude darf diagnostizieren, aber nicht stillschweigend Rechte erweitern oder Produktionsrichtlinien ändern.

Anwendungsfall 3: Technischen Artikel erstellen und prüfen

Situation: Quellen, Redaktionsregeln, Codeprüfung, Übersetzungsnotizen und Screenshots überladen schnell die Schreibsitzung.

Agentenbereich: Quellen in einer Recherchenotiz, dauerhafte Regeln in CLAUDE.md und den fertigen Text in MDX halten. Nur bestätigte Fakten und offene Fragen in den Schreibkontext übernehmen.

Menschliche Freigabe: Zielgruppe, kommerzielles Versprechen und Haupt-CTA. Der Agent darf keine persönlichen Erfahrungen, Messwerte oder Kundenergebnisse erfinden.

Anwendungsfall 4: Vom Bugfix zu einem neuen Feature wechseln

Situation: Der Fehler ist behoben, im selben Terminal soll nun ein unabhängiges Dashboard entstehen.

Agentenbereich: Abschließenden Diff und Testergebnis melden und eine klare Aufgabengrenze vorschlagen.

Menschliche Freigabe: Bestätigen, dass keine offene Folgearbeit des Bugfixes zur neuen Aufgabe gehört. Danach /clear bugfix-abgeschlossen verwenden. Wird später ein Detail benötigt, kann die gespeicherte Sitzung mit /resume geöffnet werden.

Konkrete Fallstricke und ihre Behebung

Fallstrick 1: /compact als vollständiges Gedächtnis behandeln

Eine Zusammenfassung ist selektiv. Eine einmal erwähnte Nebenbedingung kann entfallen.

Behebung: Dauerhafte Regeln in CLAUDE.md oder einer Spezifikation ablegen und akzeptierte Entscheidungen vor der Komprimierung in die Übergabenotiz schreiben.

Fallstrick 2: /clear während einer laufenden Aufgabe verwenden

Zu frühes Leeren entfernt den aktiven Arbeitsstand. Die Ursachenanalyse muss dann erneut aufgebaut werden.

Behebung: Bleiben Ziel und Abnahmetest gleich, mit Fokus komprimieren. Nur bei einer echten Aufgabengrenze leeren.

Fallstrick 3: /memory mit “aktuell geladen” verwechseln

Verschachtelte Dateien und Regeln mit Pfadfilter sind nach einer Komprimierung möglicherweise noch nicht aktiv.

Behebung: Mit /context den Bereich der Memory-Dateien prüfen und eine passende Datei lesen, damit die betreffende Regel erneut geladen wird.

Fallstrick 4: Sicherheitsgrenzen nur in CLAUDE.md formulieren

CLAUDE.md ist Kontextanweisung, keine harte technische Sperre. Unklare oder widersprüchliche Regeln können uneinheitlich befolgt werden.

Behebung: Berechtigungen und Hooks für Aktionen verwenden, die zwingend blockiert oder geprüft werden müssen. CLAUDE.md bleibt bei kurzen Arbeitsregeln.

Fallstrick 5: Auto Memory als Teamdokumentation verwenden

Auto Memory liegt lokal. Es wird zwar in Worktrees desselben Repositorys geteilt, aber nicht automatisch auf Rechner anderer Teammitglieder oder in Cloud-Umgebungen übertragen.

Behebung: Gemeinsame Konventionen in eine versionierte CLAUDE.md, Regeln oder Projektdokumente verschieben.

Fallstrick 6: Verbrauch und Kontext verwechseln

Eine Sitzung kann wenig Kontext und trotzdem bereits hohe Nutzung haben. Umgekehrt kann ein volles Kontextfenster bei noch moderatem Verbrauch entstehen.

Behebung: Mit /context über Eingrenzen, Delegieren, Komprimieren oder Leeren entscheiden. Mit /usage Kosten und Planlimits beobachten.

CLAUDE.md, Projektdateien und Obsidian richtig aufteilen

Nicht jede nützliche Notiz sollte bei jeder Sitzung automatisch geladen werden. Obsidian eignet sich für lange Recherche, Alternativen, Besprechungsnotizen und spätere Ideen. Das Repository eignet sich für geteilte Regeln, Spezifikationen, Übergaben und veröffentlichte Inhalte.

Ort	Geeigneter Inhalt
Projekt-CLAUDE.md	Kurze Regeln, die in fast jeder Sitzung nötig sind
.claude/rules/	Anweisungen für bestimmte Dateitypen oder Pfade
Projektdokumente	Geteilte Entscheidungen, Spezifikationen und Übergaben
Obsidian	Lange Recherche, Hypothesen, Quellen und Ideenbestand
Auto Memory	Lokale Vorlieben und wiederkehrende Erkenntnisse

Ergänzende Abläufe findest du im Leitfaden für CLAUDE.md, in der Anleitung zur Token-Optimierung und im Claude-Code-und-Obsidian-Workflow.

Ein einfacher Ablauf für jede längere Sitzung

1. Briefing: Ziel, Umfang, Ausschlüsse, Abnahmetest und nötige Freigaben nennen.
2. Eingrenzen: Erst suchen, dann nur Dateien und Ausgabe für die nächste Entscheidung laden.
3. Prüfen: Nach größerer Recherche oder bei Wiederholungen /context ausführen.
4. Festhalten: Entscheidungen, geänderte Dateien, Prüfergebnis und nächsten Schritt notieren.
5. Wählen: Für dieselbe Aufgabe /compact, für eine neue Aufgabe /clear, für gespeicherte Arbeit /resume verwenden.

Für wiederverwendbare Prompts und Arbeitsvorlagen zu diesem Ablauf gibt es den praxisnahen Claude-Code-Promptleitfaden.

Offizielle Quellen

• Kontextfenster untersuchen
• Befehlsreferenz
• Projekt-Memory in Claude Code
• Sitzungen verwalten und fortsetzen

Was wir geprüft haben

Für diese Überarbeitung haben wir die Befehlsnamen und das aktuelle Alias-Verhalten mit der offiziellen Befehlsreferenz abgeglichen: /cost und /stats führen zu /usage, wobei /stats den Statistikbereich öffnet. Die offizielle Tabelle zum Kontextfenster bestätigt außerdem, welche Anweisungen nach /compact erneut eingefügt werden und welche erst nach dem Lesen einer passenden Datei zurückkehren. In der Sitzungsdokumentation haben wir geprüft, dass /clear eine neue Unterhaltung beginnt, ohne die vorherige zu löschen, und dass gespeicherte Arbeit über die Resume-Befehle wieder geöffnet werden kann. Die Shell-Befehle und Markdown-Vorlagen wurden auf kopierbare Syntax geprüft; projektspezifische Pfade und Testkommandos müssen weiterhin an das jeweilige Repository angepasst werden.