Skip to main content
Claude CodeCLAUDE.mdоптимизация токенов

Warum ich CLAUDE.md nach einem Release überarbeite

Nach jedem neuen Claude-Modell überprüfe ich CLAUDE.md wie Code nach einem API-Update. Alte Regeln, die einst nötig waren, verschwenden jetzt nur Tokens und verwirren das Modell. Durch Kürzen wird die KI-Integration vorhersehbarer und hilft Teams, unnötiges Context Burning zu vermeiden – selbst ohne offizielle Dokumentation zu „Fable“-Modellen.

Technischer Kontext

Ich würde daraus keine Mythologie machen, aber der Rat ist vernünftig: Nach dem Release eines neuen Claude-Modells lese ich CLAUDE.md fast immer noch einmal durch. In der echten KI-Automatisierung ist das ein Arbeitsartefakt wie ein System-Prompt, ein Routing oder ein Satz Tool Calls. Wird das Modell cleverer, stören einige alte Krücken nur noch.

Genau da bremse und kürze ich gnadenlos. Haben sich im Datei lange Verbote, wiederholte Regeln und Mikroanweisungen für alle Lebenslagen angesammelt, verbraucht das Modell Kontext nicht für die Aufgabe, sondern für die Pflege alter Teamängste.

Wichtiger Vorbehalt: Ich habe keine offizielle Anthropic-Dokumentation gefunden, die explizit verlangt, CLAUDE.md nach jedem Release neu zu schreiben. Und schon gar keine bestätigte öffentliche Aussage zu irgendwelchen „Fable Models“. Vermutlich handelt es sich um einen internen Namen oder eine lokale Terminologie.

Die praktische Schlussfolgerung ändert sich dadurch nicht. In Projekten sehe ich immer wieder dasselbe: Ein neues Modell interpretiert alte Anweisungen anders, und ein aufgeblähtes CLAUDE.md löst zusätzliche Runden, Nachfragen und Doppelprüfungen aus. Das ist keine Theorie mehr, sondern reine Kontextfenster-Mechanik.

Was ich normalerweise prüfe: Welche Regeln verhindern wirklich Fehler und welche wiederholen nur den gesunden Menschenverstand des Modells. Kann eine Zeile ohne Folgen gelöscht werden, lösche ich sie. Architekturdetails, Tests und Domänenfälle verschiebe ich in separate Dateien und lasse in CLAUDE.md nur ein kurzes Grundgerüst.

Ein weiterer nützlicher Test: Nach dem Modellwechsel lasse ich 2–3 typische Aufgaben laufen und schaue, wo es stolpert. Erst nach einem echten Ausfall füge ich eine neue Anweisung hinzu. Nicht früher.

Auswirkungen auf Business und Automatisierung

Fürs Geschäft ist das keine Philosophie, sondern handfeste Effekte. Erstens: weniger unnötig verbrauchte Tokens, vor allem wenn das Team Claude häufig in IDE, CI oder internen Assistenten nutzt. Zweitens: weniger merkwürdige Verhaltensabweichungen nach einem Modell-Update.

Gewinner sind Teams mit vielen wiederholbaren Engineering-Szenarien: Code, Review, Support, interne Knowledge Agents. Verlierer sind jene, die CLAUDE.md zur Abladestation von Unternehmenswünschen machen.

In der KI-Lösungsentwicklung würde ich solche Dateien als lebendigen Teil des Systems behandeln und nicht als Notiz, die man einmal schreibt und dann vergisst. Bei Nahornyi AI Lab analysieren wir genau diese Engpässe: wo ein kurzes Gerüst reicht, wo ein Skill gefragt ist, wo eine separate KI-Architektur sinnvoll ist und wo eine Anweisung nur Kosten aufbläht. Wenn du das Gefühl hast, dass Claude bei dir anfängt, im Kreis zu laufen und Kontext zu verbrennen, können wir deinen Workflow schnell durchleuchten und eine sauberere KI-Automatisierung aufbauen, die zu deinem tatsächlichen Prozess passt.

Wir haben bereits einen Fall besprochen, bei dem Anthropic heimlich die Antworten von Claude verschlechterte und Nutzer zwang, ihre Anweisungen zu überprüfen. Dieser Vorfall macht überdeutlich, warum das Aktualisieren von claude.md direkt nach dem Release eines neuen Modells zu einer kritischen Praxis geworden ist.

Diesen Artikel teilen