Claude Code verliert an Leistung, wenn die Kontextqualität sinkt – nicht erst wenn das Kontextfenster voll ist. Die meisten Entwickler, die inkonsistente Ergebnisse erleben, haben dasselbe Problem: zu viel im Kontext, davon zu wenig nützlich. Eine aufgeblähte CLAUDE.md, ein Auto-Capture-Memory-Tool im Hintergrund, fünf MCP-Server angebunden „nur für den Fall" – jeder fügt Rauschen hinzu, das Claude Code verarbeiten muss, bevor er Ihre eigentliche Frage beantwortet. Die Lösung sind nicht bessere Tools. Die Lösung sind weniger, besser gewählte Inputs.
Nicht mehr Kontext. Besserer Kontext.
Dieser Artikel basiert auf zwei echten Projekten: florianstangl.com, ein persönlicher Website-Umbau mit Astro und einem eigenen SCSS-Design-System, und einem deutlich komplexeren Client-Projekt. Dasselbe Degradationsmuster trat in beiden auf. Im komplexen Projekt war es deutlicher sichtbar – dort spielt das Signal-Rausch-Verhältnis eine größere Rolle.
Was „Claude wird schlechter" wirklich bedeutet
Claude Code verschlechtert sich nicht zufällig. Die Degradation hat ein Muster: Antworten werden generisch, wo sie einmal spezifisch waren, frühere Projektentscheidungen werden ignoriert, und Claude Code stellt Fragen neu, die er in früheren Sessions bereits beantwortet hat. Entwickler beschreiben das als Claude Code, der „Dinge vergisst" oder „mit der Zeit dümmer wird." Die Ursache liegt fast nie am Modell. Sie liegt fast immer am Kontext.
Claude Code verarbeitet jede Session anhand aller Informationen, die zu diesem Zeitpunkt in seinem Kontext stehen. Wenn der Kontext hochwertige, spezifische, stabile Informationen enthält – Projektarchitektur, Namenskonventionen, harte Constraints – spiegeln die Antworten diese Spezifität wider. Wenn der Kontext Rauschen enthält – veraltete Anweisungen, Auto-Capture-Tool-Verlauf, redundante MCP-Server-Beschreibungen – verbraucht Claude Code Verarbeitungskapazität für Material, das die Antwort nicht verbessert.
Beim komplexen Client-Projekt wurde die Degradation nachvollziehbar. Sessions mit einem sauberen, minimalen Kontext lieferten konsistent spezifische Antworten. Sessions, die einen verrauschten Kontext von früheren Tool-Integrationen übernahmen, lieferten Antworten, die technisch korrekt, aber architektonisch uninformiert waren – die Art von Antwort, die die unmittelbare Frage löst und dabei etwas Benachbartes bricht. Bei einem einfacheren Projekt wie florianstangl.com erzeugte dasselbe Rauschen Reibung. Bei einem komplexen Projekt erzeugte es Regressionen.
Der Unterschied ist wichtig: Kontextfenster-Erschöpfung – Kontextfenster voll, Performance sinkt – ist das Problem, das die meisten Guides behandeln. Kontextqualitäts-Degradation – Kontextfenster hat Platz, ist aber voll mit Inhalten mit niedrigem Signal – ist das Problem, das die meisten Entwickler tatsächlich erleben.
Warum Kontextqualität mehr zählt als Kontextgröße
Claude Code generiert Antworten, indem er jeden Token im aktuellen Kontext verarbeitet. Ein 50.000-Token-Kontext voller relevanter, kuratierter Informationen liefert bessere Antworten als ein 20.000-Token-Kontext mit Anweisungen, die Claude Code durch Lesen der Codebasis ableiten könnte, Session-Verlauf von vor drei Wochen und Tool-Beschreibungen für Server, die in dieser Session nicht genutzt wurden.
Kontextqualität ist das Verhältnis von nützlichem Signal zu Gesamttokens. Niedriger Qualitätskontext ist kein abstraktes Problem – er ist direkt beobachtbar als Antworten, die die Oberfläche einer Frage adressieren statt ihrer eigentlichen Constraints. Claude Code mit hochwertigem Kontext weiß, dass das Projekt BEM-Naming mit einem c--Präfix verwendet, und fragt nie danach. Claude Code mit minderwertigem Kontext fragt, rät oder fällt auf ein generisches Muster zurück.
Die praktische Konsequenz: Bevor Sie irgendetwas zum Claude Code Setup hinzufügen – eine neue CLAUDE.md-Regel, ein Memory-Tool, einen MCP-Server – ist die nützliche Frage nicht „könnte das hilfreich sein?", sondern: „Liefert das Informationen, die Claude Code nicht selbst aus dem Code ableiten kann?" Informationen, die Claude Code aus dem Code ableiten kann, sind Rauschen – mit einer Ausnahme: Constraints, bei denen Claude Code ohne expliziten Hinweis regelmäßig Fehler macht, auch wenn sie im Code sichtbar wären. Stabile, projektspezifische Informationen, die nicht im Code stehen, sind Signal.
Drei Kategorien von Inhalt verschlechtern die Kontextqualität konsistent:
- Im Code erkennbare Anweisungen – Namenskonventionen, die aus jeder bestehenden Datei lesbar sind, Architekturmuster, die in der Verzeichnisstruktur sichtbar sind, Technologieentscheidungen, die aus package.json offensichtlich sind
- Zeitgebundener Kontext – laufender Aufgabenstatus, Session-Verlauf, Notizen über das, woran Sie letzten Donnerstag gearbeitet haben
- Spekulative Regeln – Anweisungen für Szenarien, die nicht eingetreten sind und vielleicht nicht eintreten werden: „Falls wir jemals Authentifizierung hinzufügen, denken Sie daran..."
Alle drei fühlen sich beim Schreiben nützlich an. Alle drei erzeugen in der Praxis Rauschen.
Was in Ihre CLAUDE.md gehört – und was nicht
CLAUDE.md ist eine persistente Anweisungsdatei, die Claude Code zu Beginn jeder Session liest. Die Datei hat einen Zweck: projektspezifische Informationen bereitzustellen, die Claude Code nicht durch Lesen der Codebasis erhält. Alles andere ist Overhead.
Der häufigste Fehler ist, CLAUDE.md als umfassendes Onboarding-Dokument zu behandeln. Das ist sie nicht. Sie ist eine Constraint-Liste. Die Frage für jede Zeile in CLAUDE.md lautet: Würde Claude Code das auch ohne diesen Hinweis richtig machen? Wenn ja – raus damit.
In CLAUDE.md aufnehmen | Aus CLAUDE.md herauslassen |
|---|---|
Nicht-standardmäßige Build-Befehle | Technology Stack (aus package.json lesbar) |
Harte Constraints, die Claude Code regelmäßig verletzt | Namenskonventionen, die in jeder Datei sichtbar sind |
Workflow-Schritte, die nicht aus der Codebasis ersichtlich sind | Architekturmuster, die aus der Verzeichnisstruktur klar sind |
Nicht verhandelbare Output-Anforderungen | Allgemeine Best Practices, die Claude Code bereits kennt |
Domain-spezifische Regeln, die von Standardmustern abweichen | Anweisungen für hypothetische zukünftige Szenarien |
Externe Service-Referenzen, die nicht im Code sichtbar sind | Alles, was sich von Session zu Session ändert |
Eine CLAUDE.md, die auf einen Bildschirm passt und nur die linke Spalte enthält, wird eine 400-zeilige CLAUDE.md übertreffen, die beides mischt. Länger ist nicht gründlicher – es ist mehr Rauschen.
Auf florianstangl.com enthält CLAUDE.md Build-Befehle, die SCSS-Import-Reihenfolge, die BEM-Präfix-Konvention (weil c- nicht standardmäßig ist und Claude Code ohne diesen Hinweis kein Präfix verwendet), Deployment-Anweisungen und externe Service-Referenzen, die in keiner versionierten Datei sichtbar sind. Alles andere ist ableitbar. In einer Phase, als CLAUDE.md mit Architekturnotizen, Content-Richtlinien und allgemeinen Prinzipien erweitert wurde, lieferten Sessions spürbar weniger präzise Antworten. Die Datei wurde gekürzt. Die Präzision kehrte zurück.
Der Signal-Rausch-Test gilt für jede Zeile bei jeder Überprüfung: Wenn das Entfernen der Zeile Claude Codes Antworten in einem gut strukturierten Projekt nicht ändern würde, gehört die Zeile nicht hinein.
Wie Memory-Systeme und Auto-Capture-Tools gegen Sie arbeiten
Das Konzept hinter KI-Memory-Tools ist solide: Kontext über Sessions hinweg erhalten, damit Claude Code vergangene Entscheidungen, den aktuellen Projektstatus und langfristig gültige Constraints kennt. Die meisten Implementierungen tauschen Kontextqualität gegen Kontextvolumen ein.
Auto-Capture-Memory-Systeme zeichnen Tool-Nutzung, Datei-Lesevorgänge und Session-Aktivität in einen durchsuchbaren Speicher auf, der in zukünftige Sessions injiziert wird. Das Problem: Aufgezeichnete Verläufe sind signalarm – welche Dateien gelesen wurden, welche Befehle liefen, was Claude Code vor drei Sessions über eine Datei sagte, die sich inzwischen geändert hat. Volumen ist hoch. Relevanz pro Token ist niedrig. Der Nettoeffekt auf die Antwortqualität ist negativ.
Manuell kuratierter Speicher – spezifische Fakten über das Projekt, die nicht im Code stehen, Architekturentscheidungen mit expliziter Begründung, langfristig relevante Constraints – erzeugt das gegenteilige Ergebnis. Signaldichte ist hoch. Jedes injizierte Faktum verbessert die Antwort.
Das Tool, das Ihrer KI ein Gedächtnis geben sollte, war dasjenige, das ihr das präzise Denken raubte.
Das ist kein Argument gegen Persistenz über Sessions hinweg. Es ist ein Argument für Sorgfalt bei dem, was persistiert wird. Zwei Fragen entscheiden, ob etwas in ein Memory-System gehört: Ist dieses Faktum stabil genug, um in der nächsten Session noch wahr zu sein? Und ist es nicht aus dem aktuellen Code-Status ableitbar? Beide Antworten müssen Ja lauten. Wenn eine Nein ist, ist das Faktum Rauschen, das darauf wartet, injiziert zu werden.
Entwickler, die am meisten von Auto-Capture-Tools profitieren, sind diejenigen, die von null starten und keine Memory-Disziplin haben. Auto-Capture ist ein Boden, keine Decke. Wenn bereits ein kuratiertes, signalreiches Memory-System vorhanden ist, fügt Auto-Capture Rauschen in etwas hinzu, das funktionierte.
Das MCP-Server-Problem, das niemand erwähnt
Model Context Protocol Server erweitern Claude Codes Fähigkeiten durch Tools: Suche, Datenbankzugriff, externe APIs, Analytics-Plattformen. Jeder verbundene MCP-Server registriert seine Tool-Namen im Kontext von Claude Code zu Beginn jeder Session. Claude Code verwendet ein Lazy Loading – vollständige Parameter-Schemata laden nur bei Bedarf – aber die Tool-Namen selbst sind immer präsent und müssen immer durchdacht werden.
Die Kosten liegen nicht primär im Token-Verbrauch. Die Kosten sind Rauschen bei der Tool-Auswahl. Wenn die aktive Tool-Liste kurz ist, ist das richtige Tool für eine Aufgabe offensichtlich. Wenn die aktive Tool-Liste 150 Namen über sieben verbundene Server enthält – eine realistische Zahl für einen Entwickler mit Research-, Analytics-, Datenbank- und Deployment-Servern – muss Claude Code mehr Optionen durcharbeiten, um das richtige zu identifizieren. Angrenzende, plausibel klingende Alternativen nehmen zu. Die Routing-Präzision sinkt.
Ein konkretes Beispiel: Ein Search-Server bedeutet, dass „Suche" auf ein Tool abbildet. Drei verbundene Server, die jeweils eine Form von Suche oder Nachschlagen anbieten, bedeuten, dass jede Suchanfrage eine Entscheidung erfordert: Welches Tool welches Servers ist für diese spezifische Anfrage am geeignetsten? Der Overhead ist pro Entscheidung gering. Über eine vollständige Session mit Dutzenden von Tool-Aufrufen akkumuliert er sich.
Die richtige Anzahl verbundener MCP-Server ist das Minimum, das für die aktuelle Projektphase erforderlich ist. Ein Server, der für eine einmalige Recherche hinzugefügt und nie getrennt wurde, ist eine Belastung für jede nachfolgende Session. Ein Server, der verbunden ist, weil er nützlich sein könnte, ist Kontextrauschen mit einem laufenden Abonnement.
Die nützliche Audit-Frage ist nicht „Was macht dieser Server?" – sondern: „Wann habe ich zuletzt aktiv ein Tool von diesem Server genutzt, und hätte ich es bemerkt, wenn er nicht da gewesen wäre?"
Ihr Claude Code Setup in 15 Minuten prüfen
Dieser Audit dauert fünfzehn Minuten und zeigt konsistent die wirkungsvollsten Änderungen. Führen Sie ihn zu Beginn einer neuen Projektphase durch – oder immer wenn Claude Code Antworten weniger präzise wirken als früher.
Schritt 1: CLAUDE.md prüfen
Lesen Sie jede Zeile und wenden Sie den Ableitbarkeitstest an: Kann Claude Code das durch Lesen der Codebasis richtig machen, ohne expliziten Hinweis? Wenn ja, löschen Sie die Zeile. Was nach diesem Schritt übrig bleiben sollte: nicht-standardmäßige Build-Befehle, harte Constraints, die Claude Code ohne sie regelmäßig verletzt, und externe Service-Referenzen, die in keiner Datei sichtbar sind. Ziel-Länge nach dem Audit: unter 80 Zeilen. Jede Zeile über 80 ist ein Kandidat für die Löschung.
Schritt 2: Verbundene MCP-Server prüfen
Listen Sie alle verbundenen MCP-Server auf. Identifizieren Sie für jeden die letzte Aufgabe, bei der ein Tool von diesem Server direkt genutzt wurde. Wenn die Antwort „ich erinnere mich nicht" oder „nicht in den letzten zwei Wochen" lautet – trennen Sie ihn. Die erneute Verbindung dauert dreißig Sekunden. Die Session-für-Session-Kosten des Verbunden-Lassens akkumulieren sich schneller als es scheint.
Schritt 3: Memory-System prüfen
Wenn Sie ein Memory-System nutzen, scannen Sie die letzten zehn Einträge. Für jeden Eintrag: Ist dieses Faktum noch wahr? Könnte Claude Code es aus dem aktuellen Code-Status selbst schließen? Wenn veraltet oder ableitbar – entfernen. Ein Memory-System mit fünfzig veralteten Einträgen ist schlechter als kein Memory-System – es führt in jeder Session, in der es läuft, aktiv in die Irre.
Schritt 4: Session-Hygiene prüfen
Stellen Sie fest, wann /clear oder /compact zuletzt in Claude Code verwendet wurde. Bei Aufgaben, die mehrere Sessions umfassen, wird der Kontext aus früheren Sessions übernommen, sofern nicht gelöscht. Wenn die aktuelle Aufgabe sich wesentlich von der der vorherigen Session unterscheidet, verhindert ein Löschen vor dem Start, dass früherer Kontext die aktuelle Aufgabe stört.
Schritt 5: Der Ein-Bildschirm-Test
Alles, was Claude Code über das Projekt wissen muss und nicht im Code steht, sollte auf einen Bildschirm passen. Wenn nicht, hat das Setup Overhead angehäuft. Die Frage ist nicht, was hinzuzufügen ist – sondern was zu kürzen ist.
Nach Abschluss dieses Audits für das komplexe Client-Projekt wurden drei MCP-Server getrennt, CLAUDE.md von 340 auf 78 Zeilen reduziert und das Memory-System von 200 auf 31 Einträge gekürzt. Die Qualität der Session-Antworten verbesserte sich innerhalb von zwei Sessions – Antworten wurden spezifisch für die tatsächliche Architektur des Projekts statt technisch korrekt, aber kontextuell generisch.
Häufige Fragen
Warum wird Claude Code mit der Zeit schlechter?
Claude Code büßt an Leistung ein, wenn die Kontextqualität über eine Session oder zwischen Sessions sinkt. Die häufigsten Ursachen: Eine CLAUDE.md, die über nicht ableitbare Anweisungen hinausgewachsen ist, ein Auto-Capture-Memory-Tool, das veralteten Session-Verlauf injiziert, zu viele MCP-Server, die Tool-Namen hinzufügen und Routing-Rauschen erzeugen, und seltene Nutzung von /clear zwischen unverwandten Aufgaben. Die Degradation liegt nicht am Modell – sie liegt am Kontext, den das Modell erhält.
Was gehört in CLAUDE.md?
CLAUDE.md sollte nur Informationen enthalten, die Claude Code nicht durch Lesen der Codebasis ableiten kann: nicht-standardmäßige Build-Befehle, harte Constraints, die Claude Code ohne Hinweis regelmäßig verletzt, externe Service-Referenzen, die in keiner Datei sichtbar sind, und projektspezifische Abweichungen von Standardmustern. Alles, was aus package.json, der Verzeichnisstruktur oder bestehenden Dateiinhalten ableitbar ist, gehört nicht hinein.
Wie viele MCP-Server sollte ich mit Claude Code verwenden?
Das Minimum, das für die aktuelle Arbeitsphase benötigt wird. Jeder verbundene MCP-Server fügt Tool-Namen zur aktiven Liste hinzu und erhöht das Routing-Rauschen vor dem ersten Prompt. Trennen Sie Server, die in den letzten zwei Wochen nicht aktiv genutzt wurden. Die erneute Verbindung dauert unter dreißig Sekunden.
Wie verbessere ich Claude Code Performance bei komplexen Projekten?
Komplexe Projekte verstärken Kontextqualitätsprobleme – je mehr bewegliche Teile eine Codebasis hat, desto mehr hängt Claude Code davon ab, dass sein Kontext präzise und spezifisch ist. Die wirkungsvollsten Maßnahmen: CLAUDE.md auf nur harte Constraints und nicht ableitbare Anweisungen kürzen, ein manuell kuratiertes Memory-System pflegen statt auf Auto-Capture zu vertrauen, und /clear zwischen verschiedenen Aufgabentypen innerhalb einer Session nutzen.
Beeinflusst die CLAUDE.md-Datei Claude Code Performance direkt?
Ja. Claude Code liest CLAUDE.md zu Beginn jeder Session und wendet sie als Constraint-Schicht über seine Antworten an. Eine CLAUDE.md mit signalreichen, spezifischen Anweisungen liefert präzise Antworten. Eine CLAUDE.md mit ableitbaren, generischen oder veralteten Anweisungen fügt dem Kontext Rauschen hinzu. Signaldichte zählt mehr als Dateilänge – 20 Zeilen harter Constraints übertreffen 300 Zeilen, die Constraints mit ableitbaren Beobachtungen mischen.