CLAUDE.md kürzen: die neuen Regeln für Opus 5 und Fable 5

Wenn du Claude Code mit Opus 5 oder Fable 5 benutzt und deine CLAUDE.md noch aus der alten Zeit stammt, bremst du das Modell aus, ohne es zu merken. Die kurze Antwort: Deine Datei darf drastisch schrumpfen. Rein gehören nur die Eigenheiten deines Projekts und die Fallen, in die man dort tappt. Alles, was Claude beim Blick in die Dateien selbst sieht, kann raus.

Das ist keine Bauchentscheidung von mir. Anthropic hat das bei sich selbst gemacht und die Zahlen dazu veröffentlicht.

Das Wichtigste vorab

• Anthropic hat über 80 Prozent des System-Prompts von Claude Code entfernt, für Modelle wie Opus 5 und Fable 5, laut eigenem Blogpost ohne messbaren Verlust in den Coding-Tests (Quelle).
• Dahinter steckt kein Sparzwang. Die Detailregeln waren Leitplanken für schwächere Modelle. Bei den neuen stehen sie dem besseren eigenen Urteil im Weg.
• Für dich heißt das: eine kurze CLAUDE.md schlägt eine vollständige. Unten findest du einen fertigen Prompt, mit dem Claude deine eigene Datei durchgeht.

Was Anthropic bei sich selbst gemacht hat

Claude Code hat, vereinfacht gesagt, eine eigene Hausordnung. Ein Text, der bei jedem Start mitläuft und beschreibt, wie sich das Modell verhalten soll. Über die Jahre ist dieser Text gewachsen, weil man jedem Fehlverhalten eine Regel entgegengesetzt hat.

Für die Modelle der Claude-5-Generation haben sie diesen Text laut ihrem Blogpost zu Context Engineering um mehr als 80 Prozent gekürzt. Ihr Wort für den Effekt ist “Unhobbling”, also die Fesseln abnehmen. Die alten Regeln waren dazu da, den schlimmsten Fall zu verhindern. Bei Modellen, die selbst gut abwägen können, verhindern sie stattdessen den besten Fall.

Ein Beispiel aus dem Artikel, für Nicht-Entwickler übersetzt: Früher stand in der Anleitung, dass Claude im Code keine Erklärungen dazuschreiben darf. Gemeint sind Notizen, die nicht zum Programm gehören, sondern nur für Menschen da sind, damit man später noch versteht, was eine Stelle tut. Eine kurze Zeile, mehr nicht, so die alte Regel. Heute steht dort sinngemäß nur noch ein Satz: Schreib so, wie der Rest des Projekts geschrieben ist.

Aus einer Vorschrift wurde eine Richtung. Und dieser eine Satz deckt mehr Fälle ab als die Liste vorher, weil er sich an dein Projekt anpasst statt an einen erfundenen Durchschnittsfall.

Eine Einordnung, die man dazusagen muss: Die 80 Prozent aus dem Blogpost beziehen sich auf den System-Prompt von Claude Code, nicht auf eine CLAUDE.md. Die Zahl ist ein Ergebnis, kein Zielwert, und eine ohnehin schlanke Datei gibt so viel gar nicht her. Gewachsene CLAUDE.md-Dateien haben allerdings dieselbe Krankheit, nämlich eine neue Regel nach jedem Vorfall und Zusammenfassungen von Dingen, die längst woanders stehen. Bei denen sind Kürzungen zwischen der Hälfte und vier Fünfteln der Normalfall.

Warum lange Regeln jetzt schaden

Jede Regel, die du in deine CLAUDE.md schreibst, nimmt dem Modell eine Entscheidung ab. Bei einer guten Regel ist das ein Gewinn, weil du etwas weißt, was Claude nicht wissen kann. Bei einer schlechten Regel verlierst du zweimal: Das Modell hätte es besser gewusst, und der Platz im Kontext ist trotzdem weg.

Anthropic beschreibt in dem Beitrag sechs Verschiebungen, die alle in dieselbe Richtung gehen. Links steht, was ausgedient hat, rechts, was an seine Stelle tritt:

Was das im Einzelnen heißt: Statt Detailvorschriften gibst du eine Richtung vor. Statt drei Beispielsätzen im Prompt sorgt eine klare Auswahl im Werkzeug selbst für das richtige Ergebnis. Details gehören nicht in den Haupttext, sondern in Skills, die erst bei Bedarf geladen werden. Dieselbe Anweisung steht nur an einer Stelle, nicht doppelt in Datei und Werkzeug-Beschreibung. Claude merkt sich Relevantes inzwischen selbst, statt dass du alles händisch nachträgst. Und statt zu beschreiben, wie eine Seite aussehen soll, gibst du ihm gleich das fertige Mockup oder eine echte Testdatei.

Überall dieselbe Richtung. Weniger vorschreiben, mehr zeigen und den Rest dem Urteil des Modells überlassen.

Was in deine CLAUDE.md gehört

Die Prüffrage ist simpel. Sieht Claude das selbst, wenn es sich die Dateien anschaut? Wenn ja, fliegt es raus.

Das kann raus:

• Beschreibungen der Ordnerstruktur, die man beim Reinschauen sofort sieht
• Welche Programmiersprache oder welches Framework das Projekt nutzt
• Allgemeine Ratschläge wie “schreib sauberen Code” oder “achte auf Fehlerbehandlung”
• Lange Stilvorgaben, die im vorhandenen Code ohnehin schon sichtbar sind
• Anweisungen, die woanders schon stehen, etwa in einem Skill oder einer Werkzeug-Beschreibung
• Alles, was du vor Monaten “für alle Fälle” reingeschrieben hast und seitdem nie geprüft hast

Das gehört rein:

• Eigenheiten, die von außen nicht erkennbar sind, etwa dass ein Ordner anders heißt, als sein Inhalt vermuten lässt
• Fallen, in die schon mal jemand getappt ist, etwa ein Skript, das vor dem Deployen zwingend zuerst laufen muss
• Befehle, die man nicht raten kann, also die echten Zeilen zum Starten, Testen und Ausrollen
• Harte Verbote mit echter Konsequenz, etwa Dateien, die nie verändert werden dürfen
• Ein Satz dazu, worum es in dem Projekt überhaupt geht

Was überhaupt alles in deinem Kontext liegt

Bevor du anfängst zu streichen, hilft ein Blick darauf, wie viele Stellen es überhaupt gibt. Die CLAUDE.md ist nur eine davon, und ein guter Teil dessen, was Leute dort hineinschreiben, gehört woanders hin.

Bei jedem Start liest Claude mit:

  System-Prompt           laut Anthropic für Opus 5 um über 80 % gekürzt
  CLAUDE.md (global)      gilt für alle deine Projekte
  CLAUDE.md (Projekt)     gilt nur für dieses eine Projekt
  Werkzeug-Beschreibungen  was jedes Werkzeug kann und wann es passt
  Auto-Memory             was Claude sich selbst gemerkt hat

Kommt erst dazu, wenn es gebraucht wird:

  Skills                  laden sich, wenn die Aufgabe dazu passt

Alles in der oberen Hälfte kostet dich bei jeder einzelnen Sitzung Platz. Alles in der unteren Hälfte kostet nur dann etwas, wenn es wirklich relevant ist. Das ist der ganze Grund, warum lange Anleitungen besser in Skills wandern.

Danach wird die Frage “wo schreibe ich das hin?” einfach:

Die letzte Zeile ist die wichtigste. Der größte Teil dessen, was in gewachsenen CLAUDE.md-Dateien steht, fällt genau in diese Kategorie.

Und daraus folgt die Messgröße: Zähl nicht deine CLAUDE.md, zähl alles, was automatisch mitlädt. Also beide CLAUDE.md-Ebenen plus jede Datei, die per Import oder als Regel-Datei dranhängt. Sonst schiebst du Text aus der Hauptdatei in eine importierte und freust dich über eine kleinere Datei, während die Sitzung genauso viel liest wie vorher. Bei meinem eigenen Projekt waren es 31.500 Zeichen über zwölf Dateien, von denen die CLAUDE.md selbst nur ein Viertel ausmachte.

Der schnelle Weg: ein Befehl

Bevor du irgendetwas von Hand machst: Claude Code bringt für genau diese Aufgabe einen eigenen Befehl mit. Du tippst in einer Sitzung

/doctor

und bekommst einen Setup-Check. Für deine CLAUDE.md macht er laut Befehlsreferenz drei Dinge: Er gleicht deine lokale Datei gegen die eingecheckte ab und entfernt Doppeltes. Er kürzt die eingecheckte Datei um alles, was Claude aus dem Projekt selbst ableiten kann, also Verzeichnisstruktur, Abhängigkeitslisten, Architektur-Überblicke. Und er verschiebt die dauerhaft geladenen Anweisungen, die übrig bleiben, in Skills und untergeordnete CLAUDE.md-Dateien, die erst bei Bedarf laden. Behalten wird, was du nicht ableiten kannst: Fallstricke, Begründungen und Konventionen, die vom üblichen Standard abweichen.

Nebenbei zeigt er dir Skills, MCP-Server und Plugins, die du nicht nutzt, gemessen an dem Platz, den sie im Kontext kosten. Dazu prüft er deine Installation auf doppelte Reste und kaputte Konfigurationsdateien, sucht langsame Hooks, gleicht deine Version ab und fragt am Ende, ob er zwei Berechtigungs-Einstellungen setzen darf. Geändert wird nichts, bevor er dir die Befunde gezeigt und du zugestimmt hast.

Bei mir hat der erste Lauf einen Abschnitt gefunden, der zweimal in derselben Datei stand, und einen Verzeichnisbaum, den ein einzelner Befehl im Terminal genauso ausgibt. Zusammen ein Fünftel der Datei, in jeder Sitzung mitgelesen.

Falls dir der Befehl unter dem Namen /checkup bekannt vorkommt: Das ist derselbe, nur der Zweitname. Was dabei im Detail passiert, steht im Guide zum Setup-Aufräumen.

Der Prompt, der beides verbindet

/doctor nimmt dir die Fleißarbeit ab, deckt aber nicht alles ab. Ich habe ihn laufen lassen und mir angeschaut, was er im Einzelnen prüft: Installation, ungenutzte Erweiterungen, beide CLAUDE.md-Ebenen, Hooks, Version und zwei Berechtigungs-Einstellungen. Deine gespeicherten Erinnerungen sind in keinem dieser Punkte enthalten. Also das, was Claude sich über die Monate selbst über dich und dein Projekt gemerkt hat. Da sammelt sich genauso Altlast an wie in der Datei, nur schaut da nie jemand rein.

Deshalb dieser Prompt. Er startet mit /doctor, sammelt dessen Vorschläge ein, misst danach den gesamten geladenen Kontext, geht die Erinnerungen durch und legt dir alles als eine Liste vor. Der Vorteil dieser Reihenfolge: Den Befehl pflegt Anthropic weiter, er wird also mit jeder Version besser, während ein fest geschriebener Prompt stehen bleibt.

Der Prompt dreht dabei die Beweislast um, und das ist der eigentliche Trick. Die naheliegende Frage „was kann hier weg?” führt zu höflichen Ergebnissen, weil Behalten nichts kostet und Streichen eine Begründung braucht. Andersherum funktioniert es: Jeder Abschnitt fliegt, außer du kannst begründen, warum er bleiben muss. Ich habe beide Fassungen an meiner eigenen Datei ausprobiert. Die höfliche kam auf sechs Prozent.

Kürz meine CLAUDE.md radikal. Ändere nichts ohne meine Freigabe, aber dein
Vorschlag soll die harte Fassung sein, nicht die höfliche.

Hintergrund: Anthropic hat laut eigenem Blogpost die Anleitung für Claude
Code um über 80 Prozent gekürzt, ohne messbaren Verlust. Der Grund: Jede überflüssige
Regel macht dich schlechter, nicht sicherer. Behandle meine Datei genauso.

Schritt 1: /doctor + Bestandsaufnahme
Führ /doctor aus und sammle seine Vorschläge ein, ohne sie schon
umzusetzen. /doctor ist der Anfang, nicht das Ergebnis.
Miss danach den echten Ballast: Liste alle Dateien auf, die bei mir in
JEDER Sitzung automatisch mitgeladen werden, also Projekt-CLAUDE.md,
globale CLAUDE.md und alles, was per Import oder als Regel-Datei
dranhängt. Jeweils mit Zeichenzahl, darunter die Summe. Diese Summe ist
unsere Messgröße, nicht die eine Datei.

Schritt 2: Beweislast umdrehen
Geh die Dateien Abschnitt für Abschnitt durch, Überschrift für
Überschrift, nicht Zeile für Zeile. Die Grundannahme ist: Der Abschnitt
fliegt. Er bleibt nur, wenn beide Fragen ein Ja bekommen:
1. Steht hier etwas, das du weder aus den Projektdateien noch aus einer
   anderen ohnehin geladenen Datei bekommst?
2. Brauchst du es in JEDER Sitzung, nicht nur bei einer bestimmten
   Aufgabe?
Nein bei Frage 1 → streichen. Nein bei Frage 2 → auslagern: in einen
Skill (lädt nur, wenn die Aufgabe passt) oder in die Datei, auf die der
Abschnitt sowieso verweist. Fasst ein Abschnitt nur zusammen, was in
einer verlinkten Datei steht, fliegt die Zusammenfassung und der Verweis
bleibt, eine Zeile. Steht ein Datum oder ein „Stand" drin, ist es ein
gemerkter Fakt und gehört in dein Gedächtnis, nicht in die Datei.

Schritt 3: Erinnerungen prüfen
Geh deine gespeicherten Erinnerungen über mich und dieses Projekt durch:
veraltet, widerspricht dem heutigen Stand oder doppelt eine CLAUDE.md?
Dann mit auf die Liste.

Schritt 4: Entscheidungsliste + Bilanz
Gib mir drei Dinge:
a) Eine nummerierte Liste, ein Eintrag pro Abschnitt: Nummer ·
   Überschrift · Zeichenzahl · Urteil (STREICHEN / AUSLAGERN NACH … /
   KÜRZEN AUF EINEN SATZ / BEHALTEN / ERINNERUNG VERALTET) · Begründung
   in einem Halbsatz. Für jedes BEHALTEN gilt die Beweislast: ein Satz,
   warum es Frage 1 UND Frage 2 besteht. Fehlt der Satz, ist das Urteil
   STREICHEN.
b) Die Bilanz: Zeichen vorher und nachher, für jede Datei und für die
   Gesamtsumme, falls ich alles annehme.
c) Die komplette neue CLAUDE.md als Vorschau.
Liegt die neue Fassung nicht deutlich unter der Hälfte, begründe das
Abschnitt für Abschnitt. „Stand schon immer drin" zählt nicht.
Ich antworte mit Nummern oder „alle". Erst dann änderst du etwas.

Der wichtigste Teil ist der letzte: Claude legt dir eine Liste vor und wartet. Du entscheidest, was wirklich verschwindet. Erfahrungsgemäß landen mehr Zeilen auf der Streichliste, als einem lieb ist.

Wenn du es eilig hast, reicht /doctor allein für die Datei. Den ganzen Prompt nimmst du, wenn du die Erinnerungen mitprüfen und jede Entscheidung einzeln sehen willst.

Was das im Alltag ändert

Am deutlichsten merkst du es bei Aufgaben, die nicht genau in eine deiner Regeln passen. Früher hat sich Claude an den Buchstaben gehalten, auch wenn es an der Stelle unsinnig war. Mit weniger Vorschriften entscheidet es näher an dem, was du eigentlich wolltest.

Der zweite Effekt ist banal, aber real. Was nicht in der Datei steht, belegt keinen Platz im Kontext. Bei langen Sitzungen ist das der Unterschied zwischen “kennt noch den Anfang” und “hat vergessen, worum es ging”.

Ehrlich dazugesagt: Das ist kein Wundermittel. Wenn deine Ergebnisse schlecht sind, weil deine Aufgaben unklar formuliert sind, ändert eine kürzere CLAUDE.md daran nichts. Wie du Aufgaben so stellst, dass Claude selbstständig bis zum Ziel arbeitet, steht im Tutorial zu Loops statt Prompten. Und wenn du speziell mit Fable 5 arbeitest, lohnt sich der Blick auf die Eigenheiten beim Prompten dieses Modells.

Mein Tipp für den Anfang: Geh einmal Zeile für Zeile mit der Prüffrage von oben durch die eigene Datei. Die unangenehme Erkenntnis dabei ist meistens, dass ausgerechnet die Regeln, an denen man am längsten gefeilt hat, die sind, die Claude ohnehin selbst weiß.

Newsletter

Willst du mitkriegen, welche Änderungen an Claude wirklich etwas an deinem Alltag ändern, bevor du sie selbst durchtestest? Im Newsletter schicke ich dir die ehrliche Auswahl, ohne Hype.

👉 Zum Newsletter anmelden