Universal Claude.md – Reduzierung der Claude-Ausgabe-Token

 (github.com/drona23)
2 Punkte von GN⁺ 29 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Konfigurationsdatei, die unnötige Einleitungen, Abschlüsse und Wiederholungen aus Claude-Modellantworten entfernt, um Verschwendung von Ausgabe-Token zu reduzieren
  • Durch Hinzufügen von CLAUDE.md im Projekt-Root sofort ohne Codeänderungen anwendbar, mit einer durchschnittlichen Token-Einsparung von 63 %
  • Strafft Antworten mit 12 Regeln, darunter nur ASCII-Ausgabe, kein Raten und Beschränkung auf den angefragten Umfang
  • Besonders wirksam zur Kostensenkung in Umgebungen mit hohem Ausgabevolumen wie Automatisierungs-Pipelines, Codegenerierung und Agenten-Loops, kann bei einzelnen Anfragen jedoch ineffizient sein
  • Unter der MIT-Lizenz veröffentlicht und ermöglicht profilbasierte Regelverwaltung nach Team oder Aufgabe sowie Community-Beiträge

Problemüberblick

  • Bei Claude Code verursacht jedes erzeugte Wort Token-Kosten, und in der Standardeinstellung ist es für Nutzer schwer, das Antwortformat zu steuern
  • Standardmäßig werden automatisch höfliche Einleitungen wie „Sure!“ oder „Great question!“, formelhafte Abschlüsse wie „I hope this helps!“, Wiederholungen der Frage und unnötige Vorschläge eingefügt
  • Außerdem werden Zeichen wie em dashes, typografische Anführungszeichen und Unicode-Zeichen verwendet, die Parser beschädigen können, sowie übermäßige Code-Abstraktion oder falsche Zustimmungsausdrücke
  • Dadurch entsteht Token-Verschwendung, obwohl der tatsächliche Informationswert nahezu null ist

Lösung

  • Wenn im Projekt-Root eine Datei CLAUDE.md hinzugefügt wird, liest Claude Code sie automatisch ein und ändert das Ausgabeverhalten sofort
  • Funktioniert ohne Codeänderungen oder zusätzliche Konfiguration und reduziert den Verbrauch von Ausgabe-Token um etwa 63 %
  • Beispielstruktur 
    your-project/
└── CLAUDE.md

Wann der Einsatz sinnvoll ist und wann nicht

  • Sinnvolle Fälle

    • Automatisierungs-Pipelines, Agenten-Loops und Codegenerierung mit hohem Ausgabevolumen

      • Wenn sich Claudes ausführliche Standardantworten bei wiederholten und strukturierten Aufgaben aufsummieren
      • In Teamumgebungen, die konsistente Ausgabeformate über Sitzungen hinweg benötigen

  • Weniger sinnvolle Fälle

    • Bei einzelnen kurzen Anfragen oder einmaliger Nutzung kann CLAUDE.md die Eingabe-Token pro Anfrage erhöhen und damit die Kosten sogar steigern
    • Keine Wirkung bei tiefgreifender Problemlösung wie Korrektur von Halluzinationen oder Behebung architektonischer Fehler
    • In Pipelines, die für jede Aufgabe eine neue Sitzung öffnen, entfällt der Einsparungseffekt durch persistente Sitzungen
    • Für Parser-Zuverlässigkeit im großen Maßstab sind JSON-Modus oder schema-basierte Tools besser geeignet
    • Bei explorativen oder diskussionsorientierten Aufgaben kann es sich einschränkend anfühlen

  • Praktischer Kompromiss

    • Da CLAUDE.md selbst Eingabe-Token verbraucht, entsteht ein Netto-Vorteil nur bei ausreichend großem Ausgabevolumen
    • Bei geringer Nutzung können die Kosten höher sein als die Einsparungen

Benchmark-Ergebnisse

  • Getestet mit denselben 5 Prompts
    Test Standard Optimiert Reduktion
    Erklärung zu async/await 180 Wörter 65 Wörter 64 %
    Code-Review 120 Wörter 30 Wörter 75 %
    Erklärung einer REST API 110 Wörter 55 Wörter 50 %
    Korrektur von Halluzinationen 55 Wörter 20 Wörter 64 %
    Gesamt 465 Wörter 170 Wörter 63 %
  • Rund 295 Wörter eingespart, ohne Informationsverlust
  • Allerdings ist dies nur ein Richtungsindikator; statistische Kontrolle oder wiederholte Experimente wurden nicht durchgeführt
  • Ein Netto-Einsparungseffekt entsteht nur bei hohem Ausgabevolumen

  • Beispiel für Einsparungen bei großem Einsatz

    Nutzung Tägliche eingesparte Token Monatliche Einsparung (Sonnet-Basis)
    100 Mal/Tag ca. 9.600 ca. $0.86
    1.000 Mal/Tag ca. 96.000 ca. $8.64
    3 Projekte ca. 288.000 ca. $25.92

Vorher-/Nachher-Beispiel

  • Standardantwort bei Code-Review (120 Wörter)

    • Enthält ausführliches Lob, Erklärungen und Vorschläge

  • Nach Anwendung von CLAUDE.md (30 Wörter)

    • Vermittelt nur den Kern im Stil von „Bug: <= causes an off-by-one error…“, mit 75 % weniger Token

Was geändert wird

Nr. Problem Art der Korrektur
1 Schmeichelnde Einleitungen Verboten – Antwort beginnt ab der ersten Zeile
2 Leere Abschlüsse Verboten – „I hope this helps!“ wird entfernt
3 Wiederholung der Frage Verboten – sofort zur Ausführung
4 em dashes, typografische Anführungszeichen, Unicode Nur ASCII-Ausgabe erzwingen
5 Formulierungen wie „As an AI…“ Verboten
6 Unnötige Haftungsausschlüsse Nur bei echten Sicherheitsrisiken erlaubt
7 Vorschläge außerhalb der Anfrage Verboten – nur im angefragten Umfang arbeiten
8 Übermäßige Code-Abstraktion Nur der einfachste funktionierende Code erlaubt
9 Halluzinierte unsichere Fakten „Ich weiß es nicht“ explizit angeben, kein Raten
10 Nutzerkorrekturen ignorieren Korrekturen werden als sitzungsbezogene Fakten fixiert
11 Dateien mehrfach lesen Erneutes Lesen derselben Datei verboten
12 Umfang ausweiten Keine Codeänderungen außerhalb der Anfrage

Community-Tipps

  • Regeln anhand realer Fehlermuster zu schreiben ist am effektivsten
    • Beispiel: Wenn Claude Pipeline-Fehler verschluckt -> Regel hinzufügen: „Bei Schrittfehlern sofort abbrechen und den vollständigen Fehler samt Traceback melden“

  • CLAUDE.md-Dateien können hierarchisch zusammengeführt werden

    • Global (~/.claude/CLAUDE.md): allgemeine Regeln (Ton, ASCII usw.)
    • Projekt-Root: projektspezifische Einschränkungen (z. B. Änderungen an /config verboten)
    • Unterverzeichnisse: aufgabenspezifische Detailregeln
    • So lassen sich Regeln verteilt verwalten und übergroße Dateien vermeiden

Profilkonfiguration

  • Je nach Projekttyp kann ein anderer Komprimierungsgrad gewählt werden
    Profil Geeignet für
    CLAUDE.md Allgemein
    profiles/CLAUDE.coding.md Entwicklung, Code-Review, Debugging
    profiles/CLAUDE.agents.md Automatisierung, Multi-Agenten-Systeme
    profiles/CLAUDE.analysis.md Datenanalyse, Research, Reporting

Verwendung

Override-Regeln

  • Nutzeranweisungen haben immer Vorrang

    • Wenn der Nutzer ausdrücklich etwa „Bitte ausführlich erklären“ verlangt, folgt Claude dem unverändert
    • CLAUDE.md unterdrückt nicht die Absicht des Nutzers

Beitragen

  • Wenn veränderbares Verhalten gefunden wird, ein Issue eröffnen
    1. Problematisches Standardverhalten
    2. Prompt, der es ausgelöst hat
    3. Vorgeschlagene Korrekturregel
  • Vorschläge aus der Community werden in die nächste Version übernommen und mit Contributor-Credits versehen

Verifizierung und Referenzen

  • Die vollständigen Benchmark-Ergebnisse sind in BENCHMARK.md einsehbar
  • Das Projekt basiert auf realen Beschwerdefällen aus der Claude-Community
  • Zahlreiche verwandte Referenzen enthalten (GitHub-Issues, The Register, DEV Community, Medium, Anthropic Docs usw.)

Lizenz

  • MIT-Lizenz, freie Nutzung, Änderung und Verbreitung möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 29 일 전
Hacker-News-Kommentare

  • Der Benchmark hier ist auf einzelne beschreibende Tasks verzerrt und meiner Meinung nach nicht für Agenten-Schleifen wie Codegenerierung geeignet.
    Ich frage mich, ob Claudes weitschweifige Erklärungen bei laufenden Projekten nicht eher helfen, die Konsistenz und Fokussierung der Sitzung aufrechtzuerhalten.
    Die Regel „wiederhole keinen redundanten Kontext“ ist gut, aber ich denke eher, dass es hilfreich ist, mehr zielgerichtete Reasoning-Tokens zu verwenden.
    Es gibt noch zu wenig Daten dazu, ob dieser Ansatz beim echten agentischen Coding wirksam ist.

    • Ich habe einen Skill namens /handoff erstellt, der automatisch einen Markdown-Bericht erzeugt, bevor eine Sitzung an ihre Komprimierungsgrenze stößt.
      Diese Datei dient als dauerhaftes Protokoll der Sitzung und als eine Art „Tagesbericht“, sodass man später leicht darauf zurückgreifen oder sie mit dem Manager teilen kann.
      Um langfristige Konsistenz zu bewahren, halte ich eine solche zusammenfassende Dokumentationsmethode für besser.
      Die Installationsmethode habe ich hier gepostet.
    • Dank der Regel „erkläre nicht, was du tun wirst, sondern tu es einfach“ konnte ich sofort erkennen, wenn Claude in die falsche Richtung lief, und den Prompt anpassen.
    • Ich verstehe nicht, warum Leute keine Regel gegen unnötige Sprache in CLAUDE.md aufnehmen.
      Laut jüngerer Forschung helfen redundante Reasoning-Pfade (self-consistency) und Modell-Ensembling dabei, die Leistung zu verbessern.
    • Inference-Time-Scaling ist ebenfalls wichtig. Mehr Tokens bei der Suche nach einer Antwort können die Qualität sogar erhöhen.
      Sich auf minimale Länge zu versteifen, läuft dem RL-Trainingsziel zuwider.
    • Ich habe Coding-Tests mit mehreren Einstellungen durchgeführt, und insgesamt schnitt dieser Ansatz schlechter ab — über 30 Durchläufe hinweg.
      Den Testcode gibt es hier.

  • Der Planning Mode von Claude Code funktioniert nicht richtig, deshalb bin ich gegenüber dem .md-Datei-Ansatz skeptisch.
    Meiner Meinung nach sollte der Planning Mode einfach eine Funktion sein, die das Schreiben in Dateien deaktiviert.

  • Die Regel „Antwort immer in der 1. Zeile, das Reasoning danach“ ignoriert die autoregressive Natur von LLMs.
    Wenn die Antwort zuerst festgelegt wird, besteht das Risiko, dass das spätere Reasoning in einen Bestätigungsbias verfällt.

    • Die Idee dieses Ansatzes ist gut, aber die Umsetzung scheint falsch zu sein.
      Ein Verfahren zum Komprimieren des Reasonings wie im Paper zu Compressed Chain of Thought (CCoT) wäre effizienter.
      Es gibt zwar etwas Qualitätsverlust, aber Vorteile bei Geschwindigkeit und Kosten (Paper-Link).
    • In wichtigen Sitzungen füge ich einen Second-Pass-Prompt wie „sanity check“ hinzu, damit der frühe Plan noch einmal überprüft wird.
    • Reasoning-LLMs können intern Tausende von Reasoning-Tokens erzeugen, bevor sie eine Antwort schreiben.
      Das heißt, die Regel „Antwort zuerst“ verändert nur die Reihenfolge der Ausgabe, nicht die tatsächliche Reihenfolge des Denkens.
    • Claude Code hat keine „no thinking“-Option, und standardmäßig läuft es mindestens im Low-Thinking-Modus.

  • Dieser Benchmark ist bedeutungslos, weil er nur die Zahl der Ausgabetokens vergleicht, ohne die Genauigkeit zu berücksichtigen.
    Mit einem Prompt wie „antworte immer mit nur einem Wort“ könnte man die Punktzahl auch leicht erhöhen.
    Regeln wie „wenn der Nutzer auf einen Faktenfehler hinweist, akzeptiere das immer“ sind gefährlich.

    • Man sagt zwar „Prompt Engineering ist zurück?“, aber in den letzten ein bis zwei Jahren gab es mit Meta-Prompts kaum nennenswerte Verbesserungen.
    • Regeln nach dem Muster „mach keine Fehler“ sind nicht realistisch.

  • Ich glaube, bei solchen Universal-Solution-Dingen verliert man schnell das Interesse, oder sie werden am Ende in CC integriert.
    Den Workflow ständig zu ändern, ist zu anstrengend.
    Die Standardkonfiguration von Claude Code ist derzeit am stabilsten.

    • Ich sehe das ähnlich. Langfristig fühlt es sich besser an, beim Vanilla-Setup zu bleiben.
      Skills finde ich gut, aber MCP oder worktree nutze ich fast nie.
    • Anthropic optimiert das intern bereits durch Dogfooding, daher ist die Wahrscheinlichkeit hoch, dass die Standardeinstellungen am effizientesten sind.
      Es reicht völlig, CLAUDE.md wie einen groben Notizzettel für einen klugen Kollegen zu behandeln.
    • Ich stimme der Aussage zu, dass es „am Ende in CC integriert wird“.
      Wenn Anthropic eine Funktion nicht selbst eingebaut hat, dann wahrscheinlich, weil keine Leistungssteigerung nachgewiesen wurde.
    • Solche „Claude-Verbesserungs-Layer“ führen letztlich zu Workflow-Instabilität.
      Selbst wenn sie kurzzeitig nützlich sind, werden sie bald in Basisfunktionen integriert oder verschwinden wieder.
    • Auch Claude selbst bekommt laufend md-Optimierungsfunktionen.
      Daher kann man auch bei solchen experimentellen Skripten auf dem neuesten Stand bleiben, wenn man die md-Datei regelmäßig aktualisiert.

  • Auf die Frage „Ist es nicht Tokenverschwendung, wenn die Datei bei jeder Nachricht in den Kontext geladen wird?“ würde ich antworten,
    dass Claudes Personalisierungsfunktion diese Rolle bereits erfüllt.
    Ich halte Knappheit nur dann für sinnvoll, wenn sie die Qualität verbessert.
    Verwandte Tools, die ich auf Reddit gesehen habe, sind ebenfalls interessant:
    Headroom komprimiert den Kontext um 34 %,
    RTK komprimiert CLI-Ausgaben um 60–90 %,
    und MemStack bietet persistenten Speicher, um unnötiges erneutes Einlesen von Dateien zu vermeiden.

  • Ich habe das Gefühl, dass solche Versuche eher auf einem Missverständnis der grundlegenden Prinzipien von LLMs beruhen.
    „Antwort zuerst, Reasoning später“ ignoriert die autoregressive Struktur von Transformern.
    Da das RL-Training bereits die optimale Balance zwischen Länge und Qualität abstimmt, können übermäßige Eingriffe zu Leistungseinbußen führen.

    • Wenn man die Antwortlänge gewaltsam reduziert, leiden Reasoning-Qualität und Konsistenz, und die Halluzinationswahrscheinlichkeit steigt.
      Das Modell wurde darauf trainiert, mehrstufiges Reasoning auf Englisch durchzuführen.
    • Die Regel „Antwort zuerst“ verändert die tatsächliche Reihenfolge des Denkens nicht. Das Modell hat intern bereits nachgedacht, bevor es die Antwort ausgibt.
    • Der Autor kennt Transformer vermutlich durchaus, versucht aber einfach einen Hack zur Senkung der Tokenkosten.
      Es ist ein experimenteller Ansatz, der eher auf Effizienz als auf Qualität abzielt.
    • Die meisten APIs bieten bereits Optionen zur Steuerung der COT-Länge. Ich halte es für besser, solche API-Einstellungen zu nutzen als derartige Workarounds.
    • Letztlich halte ich von Anthropic entwickelte Tools für am vertrauenswürdigsten.
      Deshalb nutze ich nur First-Party-Tools statt Drittanbieter wie OpenCode.

  • Wie in Karpathys Video zu sehen war, steigt die Genauigkeit tendenziell, je mehr Tokens das Modell verwendet.
    Dieser Ansatz könnte das Modell eher verschlechtern.

    • Wenn das Ziel hier jedoch darin besteht, Ausgaben mit geringem Mehrwert zu reduzieren, etwa schmeichlerische Sätze oder Formatierungsrauschen, dann könnte das in Ordnung sein.
      Wenn man das Modell aber ohne Reasoning direkt zur Antwort zwingt, besteht das Risiko eines Bias durch zu frühe Festlegung.
    • Redundante Ausgaben dienen dazu, die Richtung zu verstärken; wenn man sie entfernt, kann die Mehrdeutigkeit zunehmen.

  • Ich verstehe nicht, warum solche sinnlosen Projekte auf HN zu Trends werden.
    Wirklich sinnvolle Tools zur Reduzierung des Tokenverbrauchs sind claude-mem und lumen.

    • Der Grund ist einfach: Der Trend-Algorithmus von HN ist eher auf Engagement als auf Genauigkeit optimiert.

  • Früher hat man neue Hash-, Verschlüsselungs- und Kompressionsalgorithmen erforscht,
    und jetzt ist es ironischerweise unsere Realität, zu erforschen, wie man einer KI sagt, sie solle einfach still sein.