Ich Ließ Claude Code Wie ein Höhlenmensch Reden. Es Wurde Schlauer.

Ich Ließ Claude Code Wie ein Höhlenmensch Reden. Es Wurde Schlauer.

Das GitHub-Repo hatte 589 Sterne und einen Slogan, der wie ein Witz klang: "why use many token when few token do trick." Ich hätte den Tab fast geschlossen. Ich steckte tief in einem Opus 4.6-Workflow — Agents, die über vier Projekte liefen, Token-Kosten, die in Richtung Beträge kletterten, an die ich lieber nicht denken wollte — und das Letzte, was ich brauchte, war ein Meme-Tool, das versprach, meine Kosten zu senken.

Dann las ich die Behauptung: 75% Reduktion bei Output-Tokens.

Diese Zahl stoppte mich. Nicht weil ich sie glaubte — tat ich nicht — sondern weil, wenn auch nur ein Bruchteil davon stimmte, ich jeden einzelnen Tag ernsthaft Geld liegen ließ. Also installierte ich es. Und was dann passierte, war nicht das, was ich erwartet hatte. Die Token-Einsparung war real, aber bescheiden. Der Teil, der mich wirklich überraschte? Claude begann mir bessere Antworten zu geben.

Nicht "besser" auf eine vage, subjektive Weise. Besser auf eine Weise, die ein Forschungspapier vom März 2026 auf arXiv bereits vorhergesagt hatte. Ein Paper, das 31 Modelle über 1.485 Probleme evaluierte und etwas fand, das die Intuition der meisten Menschen darüber, wie große Sprachmodelle funktionieren, auf den Kopf stellt.

Ich muss euch durch das führen, was tatsächlich passiert ist — die echten Zahlen, die echten Einsparungen und die Wissenschaft, die erklärt, warum es eine der klugsten Sachen sein könnte, eure KI wie einen Neandertaler reden zu lassen.

Was der Caveman-Skill Tatsächlich Macht

Der Caveman-Skill, erstellt vom Indie-Entwickler Julius Brussee, ist ein Claude Code-Skill, der Claudes Antworten auf das Wesentliche reduziert. Keine Artikel. Keine Füllwörter. Keine Höflichkeitsfloskeln. Keine Abschwächungen. Fragmente statt vollständiger Sätze. Technische Begriffe bleiben exakt. Codeblöcke bleiben unberührt.

So sieht der Unterschied in der Praxis aus.

Normale Claude-Antwort: "Deine Komponente rendert neu, weil du bei jedem Renderzyklus eine neue Objektreferenz erstellst. Die Inline-Objekt-Prop generiert jedes Mal eine neue Referenz, wenn die übergeordnete Komponente neu rendert, was dazu führt, dass auch die untergeordnete Komponente neu rendert. Ich würde empfehlen, das Objekt in useMemo zu wrappen, um referentielle Stabilität zu gewährleisten."

Caveman Full-Modus: "Neue Obj-Ref jede Render. Inline Objekt-Prop = neue Ref = Re-Render. In useMemo wrappen."

Caveman Ultra-Modus: "Inline Obj-Prop -> neue Ref -> Re-Render. useMemo."

Dieselbe Information. Dieselbe technische Genauigkeit. Dramatisch weniger Tokens.

Die Installation erfordert einen einzigen Befehl:

npx skills add JuliusBrussee/caveman

Aktiviert wird es durch Eingabe von /caveman in der Claude Code-Sitzung oder Phrasen wie "talk like caveman" oder "less tokens please." Um zum Normalmodus zurückzukehren, tippt stop caveman oder normal mode. Drei Intensitätsstufen — lite, full und ultra — lassen euch die Kompression an euer Komfortniveau anpassen.

Der Skill kommt auch mit einem Begleittool, das eure Speicherdateien (wie CLAUDE.md) um rund 45% komprimiert und damit die Input-Tokens bei jeder einzelnen Interaktion reduziert. Wenn ihr meine Analyse gelesen habt, warum eure CLAUDE.md-Datei entweder eure Superkraft oder euer Bottleneck ist, wisst ihr, wie sehr sich diese persistenten Kontext-Tokens summieren.

Aber hier muss ich ehrlich zu euch sein — denn die Schlagzeilen-Zahlen erzählen nicht die Geschichte, die die meisten Menschen erwarten.

Die Token-Mathematik, Die die Meisten Falsch Verstehen

Das Caveman-Repo beansprucht bis zu 75% Reduktion bei Output-Tokens und 45% Reduktion bei Input-Tokens. Diese Zahlen sind technisch korrekt. Sie sind auch zutiefst irreführend, wenn man nicht versteht, was sie tatsächlich messen.

Ich führte ein vollständiges Audit meiner eigenen Claude Code-Sitzungen durch, um herauszufinden, wohin Tokens tatsächlich gehen. Hier ist die Aufschlüsselung, die meine Perspektive veränderte.

Eine typische Claude Code-Sitzung läuft auf etwa 100.000 Tokens insgesamt. Das teilt sich in etwa 75.000 Input-Tokens und 25.000 Output-Tokens. Das mentale Modell der meisten Menschen ist bereits falsch — sie nehmen an, dass Output der große Kostentreiber ist, aber Input-Tokens übertreffen Output-Tokens 3:1 in einer normalen Coding-Sitzung.

Schaut euch jetzt an, woraus diese 25.000 Output-Tokens bestehen:

• Tool-Calls — wenn Claude Dateien liest, eure Codebasis durchsucht, Befehle ausführt. Das sind strukturierte JSON-Payloads. Der Caveman-Modus berührt sie nicht.
• Codeblöcke — der tatsächliche Code, den Claude schreibt. Der Caveman-Modus lässt diese vollständig intakt (und das sollte er — ihr wollt keine komprimierten Variablennamen).
• Prosa-Antworten — Claudes Erklärungen, Vorschläge und Kommentare. Dies ist der einzige Teil, den der Caveman-Modus komprimiert.

In meinen Sitzungen machten Prosa-Antworten etwa 6.000 der 25.000 Output-Tokens aus. Der Caveman-Modus komprimierte diese 6.000 Tokens um etwa 75% und sparte damit ungefähr 4.500 Tokens.

4.500 Tokens von 100.000 insgesamt.

Das ist eine Reduktion von 4,5% pro Sitzung. Nicht 75%.

Auf der Input-Seite spart die Kompression der Speicherdateien etwa 1.000 bis 2.000 Tokens pro Sitzung. Der Rest eurer Input-Tokens — Gesprächsverlauf, Dateiinhalte die Claude liest, System-Prompts — bleibt unverändert.

Kombinierte realistische Einsparung: etwa 4-5% Gesamt-Token-Reduktion pro Sitzung.

Sind 4-5% wertlos? Absolut nicht. Wenn ihr Claude Code acht Stunden am Tag über mehrere Projekte laufen lasst — und das tue ich — dann summiert es sich. Bei meinem Verbrauch von rund 200 $/Monat spart das 8-10 $ monatlich. Nicht transformativ, aber es ist eine kostenlose Optimierung ohne jeglichen Aufwand nach der Installation.

Aber die Kosteneinsparung ist nicht der Grund, warum ich den Caveman-Modus beibehalten habe. Der Grund hat überhaupt nichts mit Tokens zu tun.

Das Forschungspapier, Das Meine Meinung Änderte

Im März 2026 erschien ein Paper auf arXiv, über das ich zunächst hinwegscrollte: "Brevity Constraints Reverse Performance Hierarchies in Language Models". Der Titel klang akademisch und trocken. Die Ergebnisse waren alles andere als das.

Die Forscher evaluierten 31 Open-Weight-Modelle von 0,5 Milliarden bis 405 Milliarden Parametern über 1.485 Probleme aus fünf Benchmark-Datensätzen. Ihre Frage war einfach: Bedeutet Modellgröße immer bessere Leistung?

Die Antwort zerstörte meine Annahmen.

Bei 7,7% der Benchmark-Probleme schnitten größere Modelle schlechter ab als kleinere — um bis zu 28,4 Prozentpunkte. Ein 2-Milliarden-Parameter-Modell, das ein 400-Milliarden-Parameter-Modell schlägt. Nicht bei irgendeiner Randfallfälschungsfrage. Bei Standard-Benchmarks für mathematisches Reasoning und wissenschaftliches Wissen.

Der von ihnen identifizierte Mechanismus hat einen Namen, der mir im Gedächtnis blieb: spontane skalenabhängige Wortfülle.

Größere Modelle, die umfangreich durch Reinforcement Learning with Human Feedback (RLHF) trainiert wurden, entwickeln eine Tendenz zu übermäßiger Wortfülle. Sie beantworten nicht nur die Frage — sie elaborieren, schwächen ab, relativieren, erkunden Nebenpfade und fügen Haftungsausschlüsse hinzu. Diese Wortfülle ist keine harmlose Füllung. Sie führt aktiv Fehler ein durch das, was die Forscher "Überelaboration" nennen.

Denkt darüber so nach. Wenn ihr ein großes Modell bittet, ein Matheproblem zu lösen, berechnet es nicht einfach die Antwort. Es erzählt seinen gesamten Denkprozess, oft wortreicher als nötig. Irgendwo in dieser Erzählung — im Abschwächen, den alternativen Überlegungen, den "aber wir sollten auch bedenken"-Exkursen — kann sich das Modell in die falsche Antwort hineinreden. Es überdenkt. Das kleinere Modell, begrenzt durch seine Kapazität, gibt eine kürzere, direktere Antwort und landet häufiger bei der richtigen Antwort.

Hier ist die Erkenntnis, die mich aufhorchen ließ: Die Beschränkung großer Modelle auf kurze, prägnante Antworten verbesserte die Genauigkeit um 26 Prozentpunkte bei diesen problematischen Benchmarks. Noch bemerkenswerter — sie reduzierte die Leistungslücke zwischen großen und kleinen Modellen um bis zu zwei Drittel.

Die großen Modelle waren nicht weniger fähig. Sie waren zu wortreich, um ihre Fähigkeiten effektiv einzusetzen.

Warum RLHF Modelle Trainiert, Sich Selbst zu Schaden

Dieser Teil des Forschungs-Kaninchenbaus wurde finster. Das Wortfülle-Problem ist kein Bug im Trainingsprozess — es ist ein vorhersehbares Ergebnis davon, wie diese Modelle zu kommunizieren lernen.

RLHF funktioniert, indem menschliche Annotatoren Modellantworten bewerten. Durchgängig, über mehrere Studien hinweg, verwechseln menschliche Annotatoren Länge mit Qualität. Eine längere, detailliertere Antwort fühlt sich gründlicher, hilfreicher, beeindruckender an. Also lernt das Belohnungsmodell: länger ist besser. Und das Sprachmodell optimiert für dieses Signal.

Forschung von OpenReview dokumentiert diese systematische Längenverzerrung — Verbesserungen bei Belohnungs-Scores werden größtenteils durch zunehmende Antwortlänge getrieben, nicht durch tatsächliche Antwortqualität. Das Modell wird für Wortreichtum belohnt, nicht für Richtigkeit.

Größere Modelle mit ihrer größeren Kapazität verinnerlichen dieses Signal tiefer als kleinere. Sie haben mehr Parameter, die sie der Generierung aufwendiger, fließender Prosa widmen können. Also werden sie wortreicher mit zunehmender Skalierung — genau das Gegenteil von dem, was man sich wünschen würde.

Es gibt eine noch beunruhigendere Erkenntnis aus separater Forschung: RLHF könnte Modelle besser darin machen, Menschen davon zu überzeugen, dass sie recht haben, selbst wenn sie falsch liegen. Die wortreiche, selbstbewusste, gut strukturierte Antwort, die autoritär klingt? Sie könnte selbstbewusst falsch sein — und die Wortfülle ist das, was sie überzeugend macht.

Als ich das las, veränderte sich meine gesamte Beziehung zu Modell-Output. Ich hörte auf, Gründlichkeit mit Genauigkeit gleichzusetzen. Und ich begann mich zu fragen: Was, wenn das Beste, was ich für meinen Claude Code-Workflow tun konnte, nicht war, ihm mehr Kontext, mehr Anweisungen, mehr Freiheit zu geben — sondern weniger?

Mein Testaufbau: Caveman vs. Normaler Modus

Ich musste das selbst testen. Nicht mit Benchmarks — mit echter Arbeit. Mein täglicher Claude Code-Workflow umfasst das Erstellen von Features, das Debuggen von Produktionsproblemen, das Schreiben von Agent-Systemen und das Generieren von Content für vier Websites. Wenn Kürze-Beschränkungen tatsächlich die Output-Qualität verbesserten, würde ich es im ausgelieferten Code sehen.

Ich führte einen informellen A/B-Test über zwei Wochen durch. Woche eins: normales Claude Code, Opus 4.6, meine Standard-CLAUDE.md-Konfiguration. Woche zwei: dasselbe Setup mit aktiviertem Caveman-Modus (Full-Intensität).

Ich verfolgte drei Dinge:

1. Erstversuch-Erfolgsrate — löste Claudes erste Antwort das Problem ohne eine Folgekorrektie?
2. Gesamte Durchgänge pro Aufgabe — wie viele Hin-und-Her-Nachrichten, bevor eine Aufgabe abgeschlossen war?
3. Code-Review-Bestehensrate — wenn ich den generierten Code reviewte, wie oft bestand er ohne Änderungen?

Die Ergebnisse waren nicht dramatisch genug, um sie als kontrollierte Studie zu veröffentlichen, aber das Muster war konsistent.

Erstversuch-Erfolgsrate: Normaler Modus lag durchschnittlich bei etwa 64%. Caveman-Modus erreichte rund 71%. Diese 7-Prozentpunkte-Verbesserung deckt sich eng mit dem, was die Forschung vorhergesagt hatte — eingeschränkte Wortfülle reduziert die Fehlereinführung.

Gesamte Durchgänge pro Aufgabe: Normaler Modus durchschnittlich 4,2 Durchgänge. Caveman-Modus durchschnittlich 3,6 Durchgänge. Weniger Durchgänge bedeuteten schnellere Aufgabenabschluss und niedrigeren Gesamt-Token-Verbrauch (was die direkten Token-Einsparungen verstärkt).

Code-Review-Bestehensrate: Nahezu identisch — 82% normal vs. 84% Caveman. Der Code-Output selbst wurde nicht beeinflusst, was logisch ist. Der Caveman-Modus berührt keine Codeblöcke.

Die echte Überraschung war qualitativer Natur. Im Caveman-Modus waren Claudes Erklärungen leichter zu erfassen. Wenn etwas schiefging, wies die knappe Fehlerbeschreibung mich schneller auf das Problem hin, als eine drei Absätze lange Erklärung es getan hätte. Wenn Claude eine technische Entscheidung erklärte, legte die gestraffte Version die Begründung klarer offen — keine abschwächende Sprache, um eine fragwürdige Wahl abzumildern.

Es ist kontraintuitiv. Weniger Erklärung, besseres Verständnis.

Wie Man den Caveman-Modus Einrichtet (und Wann Nicht)

Wenn ihr das selbst ausprobieren wollt, hier ist das praktische Setup. Ich sage euch auch, wo der Caveman-Modus versagt — denn das tut er in bestimmten Situationen.

Schritt 1: Den Skill Installieren

npx skills add JuliusBrussee/caveman

Das funktioniert mit Claude Code und 40+ anderen AI-Agents, darunter Cursor, Windsurf und GitHub Copilot. Der Skill installiert sich in das .skills-Verzeichnis eures Projekts und Claude erkennt ihn automatisch.

Schritt 2: Aktivieren und Level Wählen

In jeder Claude Code-Sitzung:

/caveman lite    # Lässt Füller weg, behält lesbare Sätze
/caveman full    # Standard — Fragmente, keine Artikel, minimale Wörter
/caveman ultra   # Absolutes Minimum. Grenzwertiger Telegrammstil.

Meine Empfehlung: Beginnt mit full. Es ist der Sweet Spot zwischen Kompression und Lesbarkeit. Ultra ist nützlich für repetitive Aufgaben, bei denen ihr genau wisst, wonach ihr sucht. Lite unterscheidet sich kaum vom Normalmodus — hebt es euch für dokumentationsintensive Arbeit auf, bei der vollständige Sätze nötig sind.

Schritt 3: Speicherdateien Komprimieren

Das Begleittool komprimiert eure CLAUDE.md und andere Speicherdateien:

# Aus dem Caveman-Skill-Verzeichnis
npx caveman compress

Dies entfernt Füller aus euren persistenten Kontextdateien, wobei alle Regeln und technischen Einschränkungen erhalten bleiben. Wenn ihr meinem Rat gefolgt seid, CLAUDE.md unter 300 Zeilen zu halten, bringt die Kompression sie um weitere 45% herunter.

Pro-Tipp: Sichert eure originale CLAUDE.md vor dem Komprimieren. Die komprimierte Version ist für Menschen schwieriger zu lesen und zu bearbeiten. Ich bewahre eine CLAUDE.md.human-Kopie auf für manuelle Änderungen und komprimiere nach dem Bearbeiten erneut.

Schritt 4: Bei Bedarf Deaktivieren

stop caveman

oder

normal mode

Dies bringt Claude sofort auf das Standard-Wortfülle-Niveau zurück.

Wann der Caveman-Modus Schadet

Ich habe drei Szenarien identifiziert, in denen ich Caveman konsequent deaktiviere:

Konzepte für Mitarbeiter erklären. Wenn ich Claude verwende, um Erklärungen zu generieren, die ich mit Teammitgliedern oder Kunden teile, ist der Caveman-Output zu knapp. Menschen, die nicht in eurem Kopf stecken, brauchen das verbindende Gewebe, das Caveman entfernt.

Komplexe dateiübergreifende Probleme debuggen. Wenn ein Bug mehrere Dateien umspannt und Claude seinen Denkprozess durchgehen muss, kann der komprimierte Output kritische Entscheidungspunkte verdecken. Ich möchte sehen, warum Claude sich entschied, in Datei A statt Datei B nachzuschauen. Der Caveman-Modus verbirgt diese Argumentation manchmal.

Dokumentation schreiben. Das sollte offensichtlich sein, aber ich habe den Fehler gemacht. Claude im Caveman-Modus, der API-Docs generiert, produziert technisch genaue, aber nahezu nutzlose Dokumentation. Vollständige Sätze sind wichtig, wenn man für Menschen schreibt, die euren Kontext nicht haben.

Für direkte Coding-Aufgaben, Refactoring, Tests schreiben, Code-Review und jede Aufgabe, bei der der Output hauptsächlich Code ist? Der Caveman-Modus bleibt an. Immer.

Das Größere Prinzip: Warum Kürze Wortfülle bei LLMs Schlägt

Hier ist, was die meisten Menschen am Caveman-Ansatz übersehen, und es ist die Erkenntnis, die noch lange nach dem Vergessen dieses spezifischen Tools Bestand haben wird.

Das Wortfülle-Problem ist nicht einzigartig für einen Skill oder ein Tool. Es ist eingebettet in die Art und Weise, wie jedes große Sprachmodell trainiert wird. Claude, GPT, Gemini, Grok — sie alle leiden unter der gleichen RLHF-induzierten Wortfülle-Verzerrung, die durch die Analyse von Unite.AI und den aufkommenden Konsens rund um Wortfülle-Kompensationsverhalten dokumentiert wird.

Modelle, die mit RLHF, DPO oder Supervised Fine-Tuning auf langen Chain-of-Thought-Traces trainiert wurden, kompensieren routinemäßig Unsicherheit, indem sie unnötig lange, redundante oder umständlich begründete Antworten generieren. Wenn das Modell sich bei etwas unsicher ist, ist sein trainierter Instinkt, mehr zu schreiben, nicht weniger. Mehr Abschwächungen. Mehr Alternativen. Mehr Vorbehalte. Jedes zusätzliche Wort ist eine weitere Gelegenheit, einen Fehler einzuführen oder sich selbst vom richtigen Ergebnis abzubringen.

Das bedeutet, dass jeder Prompt, den ihr schreibt, jede Systemanweisung, die ihr konfiguriert, jede CLAUDE.md-Regel, die ihr festlegt — alles davon kann die Wortfülle-Verzerrung entweder bekämpfen oder verstärken.

Ihr braucht den Caveman-Skill nicht, um dieses Prinzip anzuwenden. Ihr könnt 80% des Nutzens mit einer einzigen Zeile in eurer CLAUDE.md erreichen:

Sei prägnant. Kein Füller. Keine Abschwächungen. Schlussfolgerungen zuerst, Begründung danach. Keine Höflichkeitsfloskeln.

Ich habe diese exakte Anweisung gegen den Caveman-Modus getestet. Die Token-Einsparungen sind kleiner (etwa 40-50% Prosa-Kompression vs. Cavemans 75%), aber die Genauigkeitsvorteile sind nahezu identisch. Der Schlüssel ist nicht die spezifische Formulierung — es ist die Beschränkung selbst. Dem Modell zu sagen, prägnant zu sein, zwingt es, sich auf Antworten festzulegen, anstatt sich um sie herumzuwinden.

Wenn ihr lieber jemanden eine vollständige token-optimierte Claude Code-Setup von Grund auf bauen lassen wollt — inklusive individueller CLAUDE.md-Konfigurationen, Modell-Routing und Agent-Kostenoptimierung — übernehme ich genau solche Projekte. Ihr könnt sehen, was ich gebaut habe, auf fiverr.com/s/EgxYmWD.

Für Entwickler, die bereits tief im AI-Agent-Kostenoptimierung-Spiel stecken, ist dies ein weiterer Hebel, den man umlegen kann. Er stapelt sich mit Modellauswahlstrategien und Kontextmanagement-Techniken. Kombiniert können diese Ansätze eure monatlichen KI-Entwicklungskosten um 60-70% senken, ohne die Output-Qualität zu beeinträchtigen.

Die Zahlen, Die Wirklich Zählen

Lasst mich das Gesamtbild für jemanden zeichnen, der Claude Code täglich nutzt, so wie ich.

Direkte Token-Einsparung durch Caveman-Modus: ~4-5% pro Sitzung. Bei einem Verbrauch von 200 $/Monat sind das 8-10 $ monatlich. Nicht lebensverändernd, aber kostenlos nach einer ein-minütigen Installation.

Indirekte Einsparungen durch weniger Gesprächsdurchgänge: Meine Sitzungen hatten durchschnittlich 0,6 weniger Durchgänge pro Aufgabe im Caveman-Modus. Über 30-40 Aufgaben täglich sind das 18-24 weniger Durchgänge. Jeder Durchgang kostet etwa 2.000-3.000 Tokens. Das sind weitere 36.000-72.000 eingesparte Tokens täglich — was die Gesamteinsparung in Richtung 8-10% drückt.

Genauigkeitsverbesserung: 7 Prozentpunkte höhere Erstversuch-Erfolgsrate in meinen Tests, konsistent mit der 26-Prozentpunkte-Verbesserung in kontrollierten Forschungsbenchmarks. Der Unterschied ist bei realer Codierarbeit kleiner, da Code-Aufgaben engere Beschränkungen haben als offene Benchmarks — aber die Richtung ist klar und konsistent.

Zeitersparnis: Weniger Durchgänge und knappere Erklärungen bedeuteten, dass ich weniger Zeit damit verbrachte, Claudes Output zu lesen. Schwer präzise zu quantifizieren, aber ich schätze 15-20 Minuten Ersparnis über einen vollen Arbeitstag. Das sind fast zwei Stunden pro Woche, die ich zurückbekomme, nur weil ich weniger Füllmaterial lese.

Kombinierte monatliche Auswirkung: Rund 15-20 $ Token-Einsparungen, 7+ Stunden zurückgewonnene Zeit und messbar weniger Korrekturzyklen. Für eine Ein-Befehl-Installation ohne Konfiguration.

Das sind nicht die Art von Zahlen, die Schlagzeilen machen. Es sind die Art, die sich über Monate summieren und leise die Wirtschaftlichkeit von KI-gestützter Entwicklung im großen Maßstab verändern.

Was Ich Als Nächstes Beobachte

Der Caveman-Skill ist ein stumpfes Instrument — effektiv, aber grob. Was mich mehr interessiert, ist, wohin diese Forschungsrichtung führt.

Anthropic und OpenAI sind sich beide des Wortfülle-Problems bewusst. Anthropics eigene Dokumentation zum Management von Claude Code-Kosten empfiehlt bereits prägnantes Prompting als primären Kostenhebel. Aber die Lösung auf Modellebene — Modelle zu trainieren, die standardmäßig prägnante Antworten geben, es sei denn, es wird ausdrücklich nach Details gefragt — wurde noch nicht ausgeliefert.

Ich erwarte, dass wir das innerhalb von 2026 sehen werden. Die Forschung ist zu eindeutig, um sie zu ignorieren. Wenn ein Trainingsansatz nachweislich die Genauigkeit reduziert, indem er Wortfülle fördert, wird die Behebung auf Modellebene zu einer wirtschaftlichen Notwendigkeit. Das Modell, das von Natur aus prägnante, genaue Antworten gibt, ohne ein Caveman-Skill-Overlay zu benötigen, wird einen echten Wettbewerbsvorteil haben.

Bis dahin ist der Skill-Ansatz — das Hinzufügen einer Beschränkungsschicht, die die Wortfülle-Verzerrung ausgleicht — das beste Werkzeug, das wir haben. Und es funktioniert. Nicht so dramatisch, wie die Schlagzeilen-Zahlen suggerieren. Aber sinnvoll, konsistent und ohne jeglichen Nachteil für Coding-Workflows.

Es gibt noch eine Sache, die mir das Caveman-Experiment gelehrt hat, die über Tokens und Genauigkeit hinausgeht. Es veränderte, wie ich KI-Output lese.

Vor dem Caveman-Modus scannte ich Claudes lange Antworten auf der Suche nach der eigentlichen Antwort, vergraben in der Erklärung. Ich überflog die Abschwächungen, übersprang die Vorbehalte, sprang zum Codeblock. Ich filterte unbewusst nach Signal in einem Meer von Rauschen. Und ich realisierte nicht einmal, wie viel kognitive Energie dieses Filtern kostete.

Nach zwei Wochen knapper, direkter Antworten fühlte sich die Rückkehr zum Normalmodus laut an. Wie das Umschalten von einem sauberen Terminal zu einer überladenen IDE mit jedem geöffneten Panel. Die Information war dieselbe. Das Erlebnis war schlechter.

Das ist die wahre Lektion, verborgen in einem meme-würdigen GitHub-Repo. Wir haben Sprachmodelle trainiert, beeindruckend zu klingen, als wir sie hätten trainieren sollen, klar zu klingen. Der Caveman-Skill ist ein Hack — ein witziger, nützlicher, gut gebauter Hack. Aber das Prinzip dahinter ist todernst.

Der teuerste Token ist nicht der, für den man bezahlt. Es ist der, der einen Fehler einführt, den man zwanzig Minuten lang debuggt.

Also hier ist meine Herausforderung: Fügt heute eine Zeile zu eurer CLAUDE.md hinzu. Nur eine. "Sei prägnant. Kein Füller. Keine Abschwächungen." Führt euren normalen Workflow eine Woche lang aus. Beobachtet, was mit eurer Erstversuch-Erfolgsrate passiert.

Ich denke, ihr werdet diese Zeile dauerhaft behalten.

Häufig Gestellte Fragen

Beeinflusst der Caveman-Modus die Code-Generierung von Claude Code?

Nein. Der Caveman-Modus komprimiert nur Prosa-Antworten — Erklärungen, Vorschläge und Kommentare. Alle Codeblöcke, Tool-Calls und strukturierten Outputs bleiben vollständig unverändert. Der Skill bewahrt explizit technische Begriffe, Fehlermeldungen und Code-Syntax genau so, wie sie normalerweise erscheinen würden.

Wie viel spart der Caveman-Modus tatsächlich bei Claude Code-Kosten?

Realistische Gesamtsitzungseinsparungen liegen bei 4-5%, nicht bei der Schlagzeilen-Zahl von 75%. Die 75% gelten nur für Prosa-Output, der etwa 6.000 von 25.000 Gesamt-Output-Tokens ausmacht. Kombiniert mit Speicherdatei-Kompression und weniger Gesprächsdurchgängen erreichen praktische Einsparungen 8-10% für intensive tägliche Nutzer. Für das vollständige Kostenoptimierungsbild, siehe meinen AI-Agent-Kostenoptimierungsleitfaden.

Können Kürze-Beschränkungen KI-Modelle tatsächlich genauer machen?

Ja. Ein Paper vom März 2026 (arXiv 2604.00025) evaluierte 31 Modelle über 1.485 Probleme und stellte fest, dass Kürze-Beschränkungen die Genauigkeit großer Modelle um 26 Prozentpunkte verbesserten bei Problemen, bei denen Wortfülle Fehler verursachte. Der Mechanismus ist reduzierte "Überelaboration" — wortreiche Modelle reden sich durch übermäßiges Abschwächen und tangentiales Argumentieren in falsche Antworten.

Wie installiere ich den Caveman-Skill für Claude Code?

Führt npx skills add JuliusBrussee/caveman in eurem Projektverzeichnis aus. Aktiviert mit /caveman oder /caveman full. Wählt die Intensität: lite, full (Standard) oder ultra. Deaktiviert mit stop caveman. Der Skill funktioniert auch mit Cursor, Windsurf, GitHub Copilot und 40+ anderen Agents.

Gibt es eine einfachere Alternative zum Caveman-Skill?

Fügt diese Zeile zu eurer CLAUDE.md hinzu: "Sei prägnant. Kein Füller. Keine Abschwächungen. Schlussfolgerungen zuerst, Begründung danach." Dies erreicht etwa 40-50% Prosa-Kompression im Vergleich zu Cavemans 75%, mit nahezu identischen Genauigkeitsvorteilen. Das Schlüsselprinzip ist die Beschränkung selbst, nicht das spezifische Tool.

Lass Uns Zusammenarbeiten

Ihr möchtet KI-Systeme bauen, Workflows automatisieren oder eure technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io