Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Context Management

Level 1 | 35 Minuten

Verstehe wie Claude denkt — Das mentale Modell, Token-Grenzen und die Kunst der Kontext-Steuerung

Lernziele

Wie Claude Informationen verarbeitet

Um Claude Code effektiv zu nutzen, musst du verstehen wie es Informationen verarbeitet. Claude ist kein Mensch der Dinge 'weiß' — es ist ein Sprachmodell das bei JEDER Anfrage den gesamten bereitgestellten Kontext liest und daraus eine Antwort generiert. Dieses Verständnis ist fundamental für alles was danach kommt. Stell dir Claude wie einen hochintelligenten Leser vor, der bei jeder Frage ALLE Dokumente die du ihm gegeben hast von Anfang bis Ende liest. Die CLAUDE.md, die bisherige Konversation, alle gelesenen Dateien, alle Tool-Ergebnisse — bei JEDER einzelnen Nachricht wird alles erneut verarbeitet. Es gibt kein 'Langzeitgedächtnis' zwischen den Verarbeitungsschritten. Das bedeutet praktisch: Informationen die am Anfang der Session stehen (CLAUDE.md, System-Prompt) werden bei JEDER Nachricht berücksichtigt. Informationen die vor 20 Nachrichten gegeben wurden, sind technisch noch vorhanden, aber Claude gewichtet sie möglicherweise weniger stark. Dieses Phänomen heißt 'Lost in the Middle' — Informationen am Anfang und Ende des Kontexts werden besser verarbeitet als solche in der Mitte. Die praktische Konsequenz: Wichtige Informationen gehören in die CLAUDE.md (wird immer am Anfang geladen) oder in die aktuelle Nachricht (am Ende des Kontexts). Alles dazwischen kann 'verloren gehen' — nicht physisch gelöscht, aber von Claude weniger beachtet. Ein zweiter wichtiger Aspekt: Claude hat kein Bewusstsein für FEHLENDE Informationen. Wenn du vergisst zu erwähnen dass die API Rate-Limited ist, wird Claude Code ohne Rate-Limiting implementieren — ohne nachzufragen. Claude arbeitet mit dem was es hat und ergänzt aus seinem Trainingswissen. Deshalb ist vollständiger Kontext so wichtig. Das mentale Modell zusammengefasst: Claude = Hochintelligenter Leser mit perfektem Arbeitsgedächtnis, aber ohne Langzeitgedächtnis und ohne die Fähigkeit zu wissen was es nicht weiß.

WIE CLAUDE INFORMATIONEN GEWICHTET
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Bei jedem Prompt gewichtet Claude die verfügbaren Infos:

HÖCHSTE PRIORITÄT:
┌──────────────────────────────────────────────┐
│  Deine aktuelle Nachricht                    │  ← Was du JETZT fragst
│  → Claude fokussiert sich hierauf            │
├──────────────────────────────────────────────┤
│  Kürzliche Konversation (letzte 5-10 Msgs)  │  ← Aktueller Kontext
│  → Entscheidungen, Codeänderungen           │
├──────────────────────────────────────────────┤
│  CLAUDE.md                                   │  ← Permanenter Kontext
│  → Wird bei JEDER Anfrage berücksichtigt     │
├──────────────────────────────────────────────┤
│  Geladene Dateien                            │  ← Projekt-Code
│  → Nur was gerade relevant ist               │
├──────────────────────────────────────────────┤
│  Ältere Konversation (>10 Msgs zurück)       │  ← Verblasst!
│  → Details gehen verloren, nur Kernpunkte    │
└──────────────────────────────────────────────┘
NIEDRIGSTE PRIORITÄT

WICHTIG: Claude hat ein "Lost in the Middle" Problem.
Informationen am ANFANG und am ENDE des Kontexts
werden besser erinnert als Informationen in der Mitte.
→ Deshalb: Wichtiges gehört in die CLAUDE.md (Anfang)
   oder in den aktuellen Prompt (Ende).
💡 Die zentrale Erkenntnis Claude ist wie ein Kollege mit perfektem Kurzzeitgedächtnis aber KEINEM Langzeitgedächtnis. Alles was du ihm sagst, vergisst er nach der Session. Was in der CLAUDE.md steht, wird bei JEDER Session neu gelesen — das ist sein einziges "Gedächtnis". Konsequenz: Alles Wichtige muss entweder in der CLAUDE.md stehen oder explizit im aktuellen Prompt wiederholt werden.

Token-Limits verstehen

Jedes Claude-Modell hat ein festes Context Window — die maximale Menge an Information die es gleichzeitig verarbeiten kann. Überschreitest du dieses Limit, verliert Claude den Überblick und die Qualität leidet massiv. Tokens zu verstehen ist daher überlebenswichtig. Ein Token ist ungefähr ein Wort oder 4 Zeichen. Der Satz 'Claude Code ist ein mächtiges Tool' besteht aus etwa 7 Tokens. Eine typische Quelldatei mit 100 Zeilen hat ca. 1.000-2.000 Tokens. Die gesamte CLAUDE.md hat vielleicht 1.000-3.000 Tokens. Die aktuellen Modell-Limits (seit März 2026): Claude Opus 4.6 und Sonnet 4.6 haben ein Context Window von 1.000.000 Input-Tokens (1M) — fünfmal mehr als das vorherige 200K-Limit. Opus kann 32.000, Sonnet 16.000 Output-Tokens generieren. Claude Haiku hat weiterhin 200.000 Input-Tokens. Diese Zahlen klingen nach viel — aber sie füllen sich schneller als du denkst. Eine typische Session nach 20 Nachrichten: System-Prompt und CLAUDE.md: ~3.000 Tokens. MCP Server Tool-Beschreibungen: ~5.000-20.000 Tokens (je nach Anzahl aktiver Server). Bisherige Konversation (alle Nachrichten hin und her): ~20.000-50.000 Tokens. Gelesene Dateien und Tool-Ergebnisse: ~30.000-100.000 Tokens. Zusammen: 58.000-173.000 Tokens. Mit dem 1M-Limit hast du jetzt deutlich mehr Luft — aber Context Management bleibt wichtig, weil die Performance ab ~90% Auslastung dennoch degradiert. Was passiert wenn du das Limit erreichst? Claude Code warnt dich nicht automatisch. Stattdessen beginnt die Qualität schleichend zu sinken: Frühere Details werden weniger berücksichtigt, Entscheidungen werden inkonsistent, und Claude kann sich an Dinge von vor 15 Nachrichten nicht mehr zuverlässig erinnern. Deshalb ist proaktives Token-Management essentiell: Regelmäßig /context prüfen, /compact nutzen bevor der Kontext voll wird, und neue Sessions für neue Aufgaben starten. Mehr dazu in den folgenden Abschnitten.

MODEL TOKEN LIMITS
━━━━━━━━━━━━━━━━━━
Opus 4.6:    1M Input    | 32K Output  (seit März 2026)
Sonnet 4.6:  1M Input    | 16K Output  (seit März 2026)
Haiku 4.5:   200K Input  | 8K Output

TOKEN APPROXIMATION
━━━━━━━━━━━━━━━━━━━
~4 Zeichen  = 1 Token (Englisch)
~3 Zeichen  = 1 Token (Code)
~3.5 Zeichen = 1 Token (Deutsch)

PRAKTISCHE BEISPIELE:
━━━━━━━━━━━━━━━━━━━━
1 Zeile Code           ≈ 20-40 Tokens
100 Zeilen Code        ≈ 3.000 Tokens
package.json           ≈ 500 Tokens
Typische .ts Datei     ≈ 2.000 Tokens
Große Datei (500 Zln)  ≈ 10.000 Tokens
CLAUDE.md (gut)        ≈ 1.500-3.000 Tokens

1M Tokens klingt enorm — aber:
→ 100 große Dateien = ~1.000.000 Tokens
→ Context Management bleibt dennoch wichtig
→ Performance degradiert ab ~90% Auslastung

Was passiert wenn der Context voll wird?

Wenn sich das Context Window füllt, passiert etwas Gefährliches: Die Qualität von Claude's Antworten verschlechtert sich SCHLEICHEND. Es gibt keinen klaren Moment an dem alles bricht — stattdessen werden die Ergebnisse langsam aber stetig schlechter. Dieses Phänomen heißt Context Rot. Context Rot durchläuft fünf Phasen: Phase 1 (0-30% Auslastung) — Alles funktioniert perfekt. Claude hat reichlich Platz und berücksichtigt alle Informationen. Phase 2 (30-50%) — Immer noch gut, aber die optimale Zone. Phase 3 (50-70%) — Erste subtile Qualitätsverluste. Claude beginnt gelegentlich Details zu übersehen oder Entscheidungen zu treffen die früheren Vorgaben widersprechen. Phase 4 (70-85%) — Deutliche Qualitätsverluste. Claude vergisst regelmäßig Entscheidungen von vor 10+ Nachrichten, generiert Code der nicht zu früheren Änderungen passt, und beginnt sich zu wiederholen oder zu widersprechen. Phase 5 (85%+) — Kritisch. Claude kann die Masse an Informationen nicht mehr sinnvoll verarbeiten. Fehler häufen sich, Code wird inkonsistent, und grundlegende Vorgaben werden ignoriert. Die Tücke: In Phase 3-4 MERKST du den Qualitätsverlust oft nicht sofort. Claude generiert weiterhin syntaktisch korrekten Code der auf den ersten Blick gut aussieht. Aber die subtilen Fehler — fehlende Edge-Case-Behandlung, Inkonsistenzen mit früheren Dateien, ignorierte Konventionen — zeigen sich erst beim Review oder Testing. Die Lösung ist proaktives Management: Nutze /context regelmäßig um den Füllstand zu prüfen. Bei 50-60% Auslastung: /compact um den Kontext zu komprimieren. Bei 70%+: Neue Session starten. Bei der Arbeit an einem neuen, unabhängigen Task: Immer eine neue Session. Die goldene Regel: Lieber eine Session zu früh beenden als eine zu spät. Eine frische Session mit guter CLAUDE.md produziert bessere Ergebnisse als eine überladene Session mit allem Kontext der Welt.

DIE 5 PHASEN DER CONTEXT-DEGRADIERUNG
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 1: FRISCH 🟢 (0-25% Context)
→ Perfekte Ergebnisse, schnelle Antworten
→ Alles wird erinnert, kein Vergessen

Phase 2: PRODUKTIV 🟡 (25-50% Context)
→ Gute Ergebnisse, leicht langsamer
→ Gelegentlich redundante Datei-Reads
→ OPTIMAL für die meiste Arbeit

Phase 3: DEGRADIERT 🟠 (50-75% Context)
→ Claude wiederholt sich
→ Details aus früheren Nachrichten verschwinden
→ "compacting conversation..." erscheint
→ ⚠️ HANDLUNGSBEDARF: Jetzt /compact nutzen!

Phase 4: KRITISCH 🔴 (75-90% Context)
→ Claude vergisst kürzliche Entscheidungen
→ Bugs die schon gefixt wurden tauchen wieder auf
→ Architektur-Entscheidungen werden ignoriert
→ 🚨 SOFORT /clear oder neue Session!

Phase 5: KOLLAPS 💀 (>90% Context)
→ Auto-Compaction entfernt wichtige Details
→ Claude halluziniert Dateien die nicht existieren
→ Antworten sind inkohärent
→ 💀 NEUE SESSION ist die einzige Lösung

Context-Steuerung — Die wichtigsten Befehle

Claude Code bietet dir mehrere Befehle um den Kontext aktiv zu steuern. Diese Befehle sind dein Werkzeugkasten gegen Context Rot — nutze sie regelmäßig und proaktiv, nicht erst wenn die Probleme offensichtlich sind. Der wichtigste Befehl: /compact. Er fasst die gesamte bisherige Konversation in eine kompakte Zusammenfassung zusammen. Statt 50.000 Tokens Konversationshistorie hast du danach vielleicht 5.000 Tokens Zusammenfassung. Die Kernaussagen und Entscheidungen bleiben erhalten, die Details werden komprimiert. Wann /compact nutzen? Faustregel: Nach 15-20 Nachrichten, oder wenn /context zeigt dass der Kontext über 50% ausgelastet ist. Du verlierst dadurch Details, aber behältst die Essenz. Das ist fast immer ein guter Trade-off. /clear löscht den gesamten Kontext und startet quasi eine neue Session — aber im gleichen Terminal-Fenster. Nutze das wenn du eine komplett andere Aufgabe beginnen willst und der bisherige Kontext nur stören würde. /context zeigt dir den aktuellen Füllstand des Context Windows: Wie viele Tokens sind belegt? Wovon? Wie viel Platz ist noch frei? Mit dem 1M Context Window hast du mehr Spielraum, aber die Monitoring-Tools sind trotzdem essentiell um Qualitätsverlust zu vermeiden. /cost zeigt den Token-Verbrauch und die Kosten der aktuellen Session. Nicht direkt ein Context-Steuerungs-Tool, aber hilfreich um ein Gefühl für den Verbrauch zu entwickeln. Für gezielte Kontext-Steuerung beim Start: --include lädt nur bestimmte Dateien oder Verzeichnisse. --exclude schließt Dateien aus. --no-context startet ohne automatisches Projekt-Scanning. Diese Flags sind besonders bei großen Projekten nützlich um Claude auf den relevanten Code-Bereich zu fokussieren. Mein täglicher Workflow: /context am Anfang prüfen → Aufgabe bearbeiten → alle 15 Nachrichten /compact → bei neuem Task /clear oder neue Session.

# Token-Verbrauch der Session prüfen
/cost
# → Current session:
# → Input tokens: 45,230 | Output tokens: 12,450
# → Cost: $0.32 | Context usage: 5% (45K/1M)

# Kontext komprimieren (WICHTIGSTES Tool)
/compact
# → Claude fasst die bisherige Konversation zusammen
# → Behält Kern-Entscheidungen, entfernt Redundanz

# Gezielte Komprimierung (Pro-Tipp!)
/compact keep only: current file changes, error messages, architecture decisions
# → DU bestimmst was behalten wird!

# Konversation komplett leeren (frischer Start)
/clear
# → Alles wird gelöscht, nur CLAUDE.md bleibt

# Nur bestimmte Dateien inkludieren
claude --include "src/services/**/*.ts"

# Dateien ausschließen
claude --exclude "**/*.test.ts" --exclude "node_modules"

# Ohne Projekt-Kontext (für allgemeine Fragen)
claude --no-context "Was ist dependency injection?"

.claudeignore — Dateien permanent ausschließen

Die .claudeignore Datei funktioniert wie .gitignore — sie definiert Dateien und Verzeichnisse die Claude Code NIEMALS lesen oder analysieren soll. Das spart enormen Kontext-Platz und beschleunigt die Analyse, besonders bei großen Projekten. Ohne .claudeignore scannt Claude beim Start das gesamte Projektverzeichnis. Bei einem typischen Node.js-Projekt bedeutet das: node_modules (tausende Dateien, riesiger Kontext), dist/build Ordner (kompilierter Code), .git (Version History), Testdaten, Bilder, Fonts und andere Binärdateien. All das verbraucht Kontext der besser für deinen eigentlichen Code genutzt würde. Die wichtigsten Einträge die in fast jede .claudeignore gehören: node_modules/ (npm Dependencies — Claude kennt die Libraries bereits), dist/ und build/ (kompilierter Output), .git/ (Git-Interna), coverage/ (Test-Coverage-Reports), *.min.js und *.min.css (minifizierte Dateien), Bilder, Fonts und andere Binärdateien. Projektspezifische Einträge: Große Datendateien (Fixtures, Seeds, Dumps), generierte Dateien (Swagger-Output, TypeScript-Deklarationen), Konfigurationsdateien die sensible Daten enthalten (.env, credentials.json), und Verzeichnisse die für die aktuelle Arbeit irrelevant sind. Die Syntax ist identisch zu .gitignore: Zeilen mit # sind Kommentare, * ist ein Wildcard, / am Ende markiert Verzeichnisse, ! negiert ein Pattern. Du kannst auch Glob-Patterns nutzen: **/*.test.ts würde alle Test-Dateien ausschließen (nicht empfohlen, nur als Beispiel). Ein konkretes Beispiel: Ein Next.js-Projekt ohne .claudeignore verbraucht beim Start ~40.000 Tokens für das Scanning. Mit einer guten .claudeignore nur ~8.000 Tokens. Das sind 32.000 Tokens mehr Platz für deine eigentliche Arbeit — das entspricht etwa 20 zusätzlichen Nachrichten in der Konversation. Mein Tipp: Erstelle die .claudeignore direkt beim Projekt-Setup. Sie ist eine der einfachsten und wirkungsvollsten Optimierungen die du machen kannst.

# .claudeignore — Was Claude ignorieren soll

# Dependencies (unnötig groß, Claude braucht sie nie)
node_modules/
vendor/
.pnpm/

# Build Outputs (generiert, nicht relevant)
dist/
build/
.next/

# Sensible Daten (Security!)
.env
.env.*
*.pem
*.key
secrets/

# Große Binaries (verbrauchen nur Tokens)
*.zip
*.tar.gz
*.mp4
*.pdf

# Generated Code (nicht manuell bearbeiten)
*.generated.ts
*.d.ts
coverage/

# Legacy Code (nicht anfassen!)
src/legacy/
deprecated/
💡 Der Effekt von .claudeignore Eine gut konfigurierte .claudeignore reduziert den Basis-Kontext um 40-60%. Ohne .claudeignore: Claude liest ggf. node_modules, Build-Outputs, Binaries → 100.000+ Tokens verschwendet BEVOR du überhaupt eine Frage stellst Mit .claudeignore: Nur relevanter Quellcode wird gelesen → Mehr Token-Budget für deine eigentliche Arbeit

Context Flow — Eine typische Session

Um Context Management wirklich zu verinnerlichen, musst du sehen wie der Kontext sich in einer typischen Session entwickelt. Hier ist der Verlauf einer realistischen 30-minütigen Arbeitssession — mit Token-Verbrauch und optimalen Eingriffspunkten. Minute 0-2 — Session-Start: Claude lädt die CLAUDE.md (~2.000 Tokens), die MCP-Server-Beschreibungen (~8.000 Tokens) und scannt die Projektstruktur (~3.000 Tokens). Gesamt: ~13.000/1.000.000 Tokens (1,3% Auslastung bei 1M; bei 200K wären es 6,5%). Alles im grünen Bereich. Minute 3-10 — Analyse und erste Aufgabe: Du beschreibst deine Aufgabe, Claude liest 3-5 relevante Dateien. Gesamt: ~35.000 Tokens (17,5%). Noch reichlich Platz. Claude arbeitet perfekt. Minute 10-20 — Implementation: Claude schreibt Code, du gibst Feedback, es liest weitere Dateien. Der Konversationsverlauf wächst. Gesamt: ~80.000 Tokens (40%). Optimale Arbeitszone. Jetzt wäre ein guter Zeitpunkt für /compact. Minute 20-25 — Vertiefung: Du bittest um Tests, Claude liest Testdateien als Referenz, schreibt neue Tests. Gesamt: ~120.000 Tokens (60%). Kritischer Bereich. Du solltest JETZT /compact ausführen wenn du es nicht schon getan hast. Minute 25-30 — Ohne /compact: Gesamt: ~160.000 Tokens (80%). Claude beginnt subtile Details zu vergessen. Ein Testname widerspricht der Naming-Convention, eine Funktion hat keine Error-Handling obwohl das 10 Nachrichten zuvor besprochen wurde. Das Optimum: Bei Minute 20 einmal /compact ausführen. Danach hast du wieder ~40.000 Tokens (20%) und kannst weitere 15-20 Nachrichten in optimaler Qualität arbeiten. Der typische Anfänger-Fehler: Kein /compact, Session läuft bis 90%+ Auslastung, Qualität sinkt unbemerkt, und am Ende wundert man sich warum der generierte Code so inkonsistent ist.

SESSION START
━━━━━━━━━━━━━
Tokens: 3,500 (System + CLAUDE.md)
Phase: 🟢 FRISCH

DU: "Erkläre mir den UserService"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Claude liest: userService.ts, user.types.ts, userRepository.ts
Tokens: 15,000 (+11,500)
Phase: 🟢 FRISCH

5 NACHRICHTEN AUSTAUSCH...
━━━━━━━━━━━━━━━━━━━━━━━━━
Tokens: 55,000
Phase: 🟡 PRODUKTIV — alles gut

10 WEITERE NACHRICHTEN...
━━━━━━━━━━━━━━━━━━━━━━━━━
Tokens: 120,000
Phase: 🟠 DEGRADIERT
⚠️ Claude wiederholt sich, liest Dateien erneut

DU: /compact
━━━━━━━━━━━━
Claude fasst Konversation zusammen
Tokens: 60,000 (gespart: 60,000!)
Phase: 🟡 PRODUKTIV — wieder gut!

WEITER ARBEITEN...
━━━━━━━━━━━━━━━━━
Tokens: 95,000
Phase: 🟡 PRODUKTIV

NEUES FEATURE? → /clear + neuen Task starten
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tokens: 3,500 (zurück auf Start)
Phase: 🟢 FRISCH

Strategien für große Projekte

Bei Projekten mit hunderten oder tausenden Dateien reicht normales Context-Management nicht mehr. Du brauchst eine bewusste Strategie um Claude fokussiert zu halten — andernfalls verliert es sich in der Masse an Code und produziert generische statt projektspezifische Ergebnisse. Strategie 1 — Fokussiertes Laden: Nutze --include um Claude beim Start nur den relevanten Projektbereich zu zeigen. Arbeitest du am Auth-Modul? 'claude --include src/auth/ src/middleware/'. Am Payment-System? 'claude --include src/payment/ src/billing/'. Claude bekommt nur den Code den es braucht. Strategie 2 — Modulare CLAUDE.md: Statt einer riesigen CLAUDE.md erstelle modulare Ergänzungen die du bei Bedarf lädst. Die Haupt-CLAUDE.md enthält nur die universellen Regeln. Für das Frontend-Modul gibt es eine separate .claude/frontend.md die du mit @.claude/frontend.md in der Session referenzieren kannst. Strategie 3 — Subagent-Delegation: Nutze Subagents für explorative Aufgaben die viel Kontext brauchen. Statt selbst 50 Dateien zu durchsuchen ('Wo wird die Payment-Logik verwendet?'), delegierst du das an einen Subagent der in seinem eigenen Kontext arbeitet und nur das Ergebnis zurückmeldet. Strategie 4 — Session-Segmentierung: Teile große Aufgaben in separate Sessions auf. Session 1: Analyse und Planung. Session 2: Backend-Implementation. Session 3: Frontend-Implementation. Session 4: Tests. Jede Session startet frisch und fokussiert. Strategie 5 — Aggressive .claudeignore: Bei großen Projekten kann die .claudeignore aggressiver sein. Schließe nicht nur node_modules aus, sondern auch Verzeichnisse die du aktuell nicht brauchst: Legacy-Code, andere Team-Module, Docs, Assets. Die Kombination aller fünf Strategien macht den Unterschied zwischen 'Claude versteht mein Projekt nicht' und 'Claude arbeitet als hätte es das Projekt selbst gebaut'.

Die 5 häufigsten Context-Fehler

Diese fünf Fehler machen fast alle Anfänger. Sie sind die Hauptursache für schlechte Ergebnisse, hohe Kosten und Frustration mit Claude Code. Kenne sie und vermeide sie — du wirst sofort bessere Resultate sehen. Fehler 1 — Die Endlos-Session: Du chattest stundenlang in einer Session weiter, lädst immer mehr Dateien, und wunderst dich warum Claude sich ab Nachricht 30 an nichts mehr erinnert. Lösung: Regelmäßig /compact, neue Session für neue Aufgaben. Fehler 2 — Der Kontext-Overkill: Du lädst zur Sicherheit ALLE Dateien des Projekts. 'Dann hat Claude ja den vollen Überblick!' In Wahrheit überflütest du den Kontext mit irrelevanter Information und Claude verliert den Fokus. Lösung: --include für gezieltes Laden, .claudeignore für permanentes Ausschließen. Fehler 3 — Kein Context-Monitoring: Du weißt nie wie voll dein Context Window ist. Du arbeitest blind und merkst Probleme erst wenn die Codequalität einbricht. Lösung: /context regelmäßig prüfen, Warnstufen kennen (50% = aufpassen, 70% = handeln). Fehler 4 — Keine CLAUDE.md: Ohne CLAUDE.md verschwendest du bei jeder Session Kontext-Platz um Claude dein Projekt zu erklären. Die gleichen Informationen wieder und wieder. Lösung: Einmalig eine gute CLAUDE.md schreiben die permanent verfügbar ist. Fehler 5 — /compact vergessen: Der häufigste Fehler überhaupt. /compact ist dein wichtigstes Werkzeug und die meisten Nutzer vergessen es bis es zu spät ist. Lösung: Mach es zur Gewohnheit — nach jedem größeren Abschnitt einer Aufgabe /compact ausführen. Die gute Nachricht: Wenn du nur EINEN dieser Fehler behebst — das regelmäßige Nutzen von /compact — verbesserst du deine Ergebnisse bereits um geschätzt 30-40%. Alle fünf zusammen machen dich zum Context-Management-Profi.

FEHLER 1: "Analysiere mein gesamtes Projekt"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ Claude lädt ALLES → Context sofort bei 80%+
✅ "Analysiere die Auth-Module in src/auth/"

FEHLER 2: Nie /compact nutzen
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ Session bis zum Limit laufen lassen → Phase 4-5
✅ Alle 10-15 Nachrichten: /compact

FEHLER 3: Code in den Prompt kopieren
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ "Hier ist meine 500-Zeilen Datei: ..."
✅ "Schau dir src/services/bigfile.ts an"
(Claude kann Dateien SELBST lesen — viel effizienter!)

FEHLER 4: Session über Tage offen lassen
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ Kontext wird stale, Dateien ändern sich
✅ Neue Session für neue Tasks, jeden Tag frisch starten

FEHLER 5: .claudeignore vergessen
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ node_modules wird gelesen (RIESIG! Tausende Tokens verschwendet)
✅ .claudeignore am ersten Tag konfigurieren

Vorher/Nachher — Context Management in Aktion

Der beste Beweis für den Wert von gutem Context-Management: Die gleiche Aufgabe, einmal mit und einmal ohne bewusstes Management. Die Unterschiede in Codequalität und Konsistenz sind so deutlich, dass du danach nie wieder ohne /compact arbeiten wirst. Szenario: Du arbeitest seit 25 Minuten an einer Feature-Implementierung. Du bittest Claude einen API-Endpoint zu implementieren der die gleichen Patterns wie die vor 20 Minuten erstellten Endpoints nutzen soll. OHNE Context Management (Context bei 75%): Claude implementiert den Endpoint mit einem leicht anderen Error-Response-Format als die vorherigen. Die Validierung nutzt ein anderes Pattern. Der Funktionsname folgt einer anderen Konvention. Die Tests haben eine andere Struktur. Alles funktioniert technisch, aber die Inkonsistenz bedeutet: Du musst den Code manuell anpassen. Zeitaufwand: 15-20 Minuten Nacharbeit. MIT Context Management (/compact bei 50%): Claude hat eine kompakte Zusammenfassung der bisherigen Arbeit. Es kennt die Patterns, Konventionen und Entscheidungen. Der neue Endpoint nutzt exakt das gleiche Error-Format, die gleiche Validierung, die gleiche Naming-Convention und die gleiche Test-Struktur. Nacharbeit: 0 Minuten. Die Erklärung: Nach /compact hat Claude eine destillierte Version des bisherigen Kontexts — nur die wesentlichen Entscheidungen und Patterns, ohne den Ballast von 20 einzelnen Nachrichten. Diese komprimierte Information wird besser verarbeitet als der originale, ausgedehnte Kontext. Das Paradoxe: Weniger Kontext führt zu BESSEREN Ergebnissen. Weil die wichtigen Informationen klarer hervortreten wenn sie nicht in einem Meer aus Details untergehen. Das ist die Kernlektion des Context Managements: Es geht nicht darum Claude MEHR Information zu geben, sondern die RICHTIGE Information in der RICHTIGEN Menge.

AUFGABE: "Füge Caching zum Products-Endpoint hinzu"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

❌ OHNE Context Management:
━━━━━━━━━━━━━━━━━━━━━━━━━━
Session läuft seit 2 Stunden (Phase 🔴 KRITISCH)
→ Claude vergisst: "Wir nutzen Redis" (vor 40 Msgs besprochen)
→ Implementiert In-Memory Cache statt Redis
→ Ignoriert das bestehende Cache-Pattern in cache.ts
→ Nutzt andere Naming Convention als der Rest
→ Du korrigierst... Claude vergisst die Korrektur 5 Msgs später
→ Frustration, Zeit verschwendet

✅ MIT Context Management:
━━━━━━━━━━━━━━━━━━━━━━━━━━
/clear (frische Session)
claude --include "src/api/products.ts" --include "src/middleware/cache.ts"
> "Füge Redis Caching zum Products-Endpoint hinzu.
>  Folge dem Pattern in cache.ts.
>  Cache für 5 Minuten, invalidiere bei Product-Updates."

→ Claude sieht NUR relevante Dateien
→ Folgt dem bestehenden Cache-Pattern
→ Korrekte Redis-Konfiguration
→ Konsistente Naming Convention
→ Fertig in 5 Minuten statt 45
💡 Pro-Tipp: Kontext-Effizienz Gute Praktiken die sofort helfen: 1. Referenziere Dateien statt sie zu zitieren: ❌ "In der Datei mit dem Code function xyz()..." ✅ "In src/utils/xyz.ts" 2. Nutze präzise Pfade: ❌ "Die Datei mit den User-Funktionen" ✅ "src/services/userService.ts, Funktion getUser()" 3. Gib Claude Kontext über den ZWECK: ❌ "Ändere die Funktion" ✅ "Ändere getUser() damit sie auch inaktive User findet, weil wir für den Admin-Bereich alle User anzeigen müssen"

Zusammenfassung