Caveman: Warum es sich lohnt, wenn die KI wie ein Höhlenmensch spricht

Yabba-Dabba-Doo! Erinnern Sie sich an Fred Feuerstein? Er wohnte in Steintal, fuhr ein Auto, das mit bloßen Füßen angetrieben wurde, hatte einen Dinosaurier als Kran und einen Flugsaurier als Plattenspieler. Und doch besaß diese Steinzeit-Zivilisation bei genauerem Hinsehen bereits alles, was für ein komfortables modernes Leben nötig war: funktionierende Geräte, effiziente Technologie, praktische Lösungen. Es fehlte nur der glänzende Anstrich des Fortschritts. Vielleicht hätten wir schon damals verstehen sollen, dass das Wesentliche ausreicht und dass zunehmende Komplexität nicht unbedingt einen Mehrwert bedeutet.

Julius Brussee, ein niederländischer Entwickler, scheint diese Lektion mit neuen Augen gelesen zu haben. Sein Projekt Caveman, das auf GitHub unter der MIT-Lizenz verfügbar ist, tut nur eines: Es zwingt das Modell dazu, wie ein Höhlenmensch zu antworten. Keine Artikel, keine Höflichkeitsfloskeln, keine Aufwärmsätze. Nur der technische Kern, so direkt wie möglich ausgedrückt.

Das Problem, das Caveman zu lösen versucht, ist real und jeder, der mit kostenpflichtigen Sprachmodellen arbeitet, kennt es gut. Jede Antwort eines LLM kostet Token, die Elementareinheiten, in die das Modell Sprache zerlegt und wieder zusammensetzt – etwas zwischen Silbe und Wort. Über die API sind Output-Token in der Regel teurer als Input-Token, und moderne Modelle neigen dazu, großzügig mit Worten umzugehen: Sie leiten jede Antwort mit Höflichkeitsformeln ein, präzisieren das Offensichtliche, wiederholen den bereits bekannten Kontext und schließen mit einer Zusammenfassung dessen ab, was sie gerade gesagt haben. Es ist eine systemische Weitschweifigkeit, die jahrelang durch menschliches Feedback trainiert wurde, das oft scheinbare Vollständigkeit über echte Prägnanz stellte.

Nehmen wir ein konkretes Beispiel, das so auch in der offiziellen Projektdokumentation aufgeführt ist. Die Standardantwort von Claude auf ein Re-Rendering-Problem in React klingt etwa so: "The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object." Neunundsechzig Token. Im Caveman-Modus wird dieselbe Information zu: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`." Neunzehn Token. Gleiche Diagnose, gleiche Lösung, dreieinhalbmal weniger Worte.

Wie es funktioniert

Technisch gesehen ist Caveman eine .md-Datei, die mit einem einzigen Befehl in der Umgebung des gewählten Agenten installiert wird.

Einmal installiert, wird das Tool auf Anfrage aktiviert, entweder durch den Befehl /caveman oder $caveman auf Codex, oder durch Sätze wie „talk like caveman“, „caveman mode“ oder einfach „less tokens please“. Deaktiviert wird es mit „stop caveman“ oder „normal mode“. Es handelt sich um eine Reihe von Kontextanweisungen, die das Verhalten des Modells innerhalb einer Sitzung ändern, ohne es neu zu trainieren oder seine internen Parameter zu verändern.

Ergänzt wird dies durch ein zweites Tool, /caveman:compress, das auf der Gegenseite ansetzt: Anstatt die Antworten des Modells zu komprimieren, komprimiert es die Kontextdateien. Claude lädt diese beispielsweise bei jeder Sitzung, typischerweise CLAUDE.md und Projektnotizdateien. Der Befehl schreibt diese Dateien im Höhlenmensch-Stil um und speichert automatisch eine lesbare Kopie als Backup (CLAUDE.original.md). Alles Technische – Codeblöcke, URLs, Dateipfade, Befehle, Header, Daten, Versionsnummern – bleibt unverändert; nur die beschreibende Prosa wird komprimiert. Die Benchmarks des Projekts mit fünf Arten von echten Dateien zeigen eine durchschnittliche Reduzierung der Input-Token pro Sitzung um 46 %, mit einem Spitzenwert von 59,6 % bei Einstellungsdateien.

Das Herzstück des Mechanismus ist eine Reihe von grammatikalischen und stilistischen Einschränkungen, die ein Nutzerkommentar auf Hackaday präzise zusammengefasst hat: Bestimmte und unbestimmte Artikel werden eliminiert, Füllwörter (just, really, basically, actually) unterdrückt, Höflichkeitsfloskeln (sure, certainly, of course, happy to) gelöscht, kurze Synonyme bevorzugt (big statt extensive, fix statt implement a solution for), und die Verwendung von Zögerlichkeitsformen (it might be worth considering) ist untersagt. Satzfragmente sind akzeptabel. Das Subjekt ist nicht erforderlich, wenn es implizit ist. Die Fachterminologie bleibt hingegen intakt: polymorphism bleibt polymorphism, Codeblöcke werden normal geschrieben, Fehlermeldungen wortwörtlich zitiert. Wie es im README des Projekts selbstironisch heißt: "Caveman not dumb. Caveman efficient."

Diese Unterscheidung ist grundlegend, um zu verstehen, was Caveman wirklich tut. Es ist kein Kompressor, der Antworten in der Mitte abschneidet, und auch kein Werkzeug, das Konzepte vereinfacht, um sie leichter verdaulich zu machen. Es ist ein Filter, der den kommunikativen Überschuss eliminiert – jene Sätze, die Modelle nicht produzieren, weil sie nützliche Informationen enthalten, sondern weil ihr Training, das auf menschlichen Bewertungen basiert, die oft ausführliche und höfliche Antworten belohnen, sie in diese Richtung gedrängt hat. Caveman verhält sich wie ein strenger Lektor, der alles löscht, was keinen technischen Mehrwert bietet, und nur das auf dem Papier lässt, was wirklich gebraucht wird.

Das Projekt hat inzwischen eine Granularität hinzugefügt, die es anpassungsfähiger macht, als es die Höhlenmensch-Prämisse zunächst vermuten ließ. Es stehen drei Intensitätsstufen zur Verfügung, die über spezielle Trigger ausgewählt werden können: /caveman lite lässt die Grammatik intakt und eliminiert nur Füllwörter, was zu einer professionellen, aber knappen Ausgabe führt, die für Kontexte geeignet ist, in denen die Form noch eine Rolle spielt; /caveman full ist der Standardmodus, der Artikel entfernt, Satzfragmente akzeptiert und ohne Umschweife auf den technischen Kern zielt; /caveman ultra treibt die Komprimierung auf die Spitze, mit einem telegraphischen Stil, der alles Komprimierbare abkürzt.

Die gewählte Stufe bleibt für die gesamte Sitzung bestehen, bis sie explizit geändert wird. Die unerwartetste Überraschung ist jedoch eine andere: Das README des Projekts dokumentiert auch einen Modus in klassischem literarischem Chinesisch, dem Wenyan (文言文) – der Schriftsprache, die in China über zweitausend Jahre lang bis ins 20. Jahrhundert verwendet wurde und für eine semantische Dichte bekannt ist, die in modernen Sprachen ihresgleichen sucht. Die Idee ist nicht folkloristisch: Wenyan ist objektiv eines der Token-effizientesten Schriftsysteme, die die Menschheit je erfunden hat, und Brussee hat es mit der gleichen progressiven Logik wie die lateinischen Stufen integriert: von /caveman wenyan-lite, das die Grammatik beibehält, aber Überflüssiges eliminiert, bis zu /caveman wenyan-ultra, den das README mit einer gewissen Ironie als den Modus des antiken Gelehrten mit knappem Budget beschreibt. Sicherlich ist die Ersparnis bei Wenyan extrem, aber man muss dann auch verstehen, was da geschrieben steht...

Die auf der Projektseite veröffentlichten Benchmark-Daten zeigen je nach Art der Aufgabe unterschiedliche Reduzierungen: von 87 % bei React-Re-Rendering-Problemen über 83 % beim Debugging von Authentifizierungs-Middleware, 81 % bei Race-Conditions in PostgreSQL bis hin zu 58 % für Erklärungen zu git rebase vs merge und 41 % für Sicherheitsüberprüfungen bei Pull-Requests. Der angegebene Durchschnitt liegt bei einer Reduzierung der Output-Token um etwa 65 %. Es ist wichtig zu beachten, dass sich diese Zahlen ausschließlich auf die Output-Token beziehen, nicht auf die gesamte Sitzung: Die Input-Token – also die für den Kontext, die Systemanweisungen und die Tool-Aufrufe – bleiben unverändert und können einen erheblichen Teil der Gesamtkosten ausmachen, insbesondere in langen Sitzungen oder bei vielen Aufrufen externer Tools. Bild von juliusbrussee.github.io/caveman

Die Wissenschaft des Schweigens

Bis hierher könnte man Caveman als netten Trick abtun, als eines jener Mikroprojekte, die ein paar Tage lang auf GitHub kursieren und dann wieder verschwinden. Was es aus einer breiteren Perspektive interessant macht, ist seine Verbindung zu einer aufstrebenden wissenschaftlichen Literatur, die das Verhältnis zwischen Kürze und der Leistung von Sprachmodellen untersucht. Die Ergebnisse dieser Literatur sind, gelinde gesagt, kontraintuitiv.

Das Referenzpapier ist "Brevity Constraints Reverse Performance Hierarchies in Language Models", das am 11. März 2026 von MD Azizul Hakim auf arXiv veröffentlicht wurde. Die Studie geht von einer anomalen Beobachtung aus: Bei einer Teilmenge von 7,7 % der bewerteten Probleme, verteilt auf fünf verschiedene Datensätze, schneiden größere Sprachmodelle um sage und schreibe 28,4 Prozentpunkte schlechter ab als kleinere Modelle, obwohl sie über 10- bis 100-mal mehr Parameter verfügen.

Der als Ursache identifizierte Mechanismus ist das, was das Papier als scale-dependent verbosity bezeichnet – eine Weitschweifigkeit, die mit zunehmender Modellgröße wächst. Größere Modelle neigen dazu, Antworten zu überarbeiten, indem sie Gedankengänge, Qualifizierungen und Abschweifungen hinzufügen, die die endgültige Antwort nicht verbessern, sondern oft verschlechtern, da durch die übermäßige Verarbeitung Fehler eingeschleust werden. Wenn man große Modelle zwingt, prägnant zu antworten, verbessert sich ihre Genauigkeit um 26,3 Prozentpunkte, wodurch sich der Abstand zu kleinen Modellen um 67 % verringert. Kleine Modelle hingegen erleiden unter der gleichen Einschränkung einen Rückgang von nur 3,1 Prozentpunkten.

Das überraschendste Ergebnis betrifft spezifische Benchmarks. Bei GSM8K, dem Datensatz für mathematisches Denken, und bei MMLU-STEM, dem für wissenschaftliche Erkenntnisse, kehren Kürze-Beschränkungen die Leistungshierarchie komplett um: Große Modelle, die unter normalen Bedingungen schlechter abschnitten als kleine, übertreffen diese schließlich um 7,7 bis 15,9 Prozentpunkte. Mit anderen Worten: Die überlegene Fähigkeit war bereits vorhanden, wurde aber durch die Tendenz, übermäßig laut zu denken, verdeckt. Kürze komprimiert das Denken nicht, sondern befreit es aus der weitschweifigen Hülle, die es erstickt.

Es muss jedoch eine Einschränkung festgehalten werden, die die Studie selbst ehrlich einführt: Bei BoolQ, dem Datensatz, der die Integration von Informationen erfordert, die über mehrere Sätze verteilt sind, vergrößern Kürze-Beschränkungen den Abstand geringfügig, anstatt ihn zu verringern (von 23,5 % auf 24,3 %). Bei dieser Art von Problemen ist eine ausführliche Verarbeitung funktional, nicht übermäßig: Ein Kürzen verschlechtert das Ergebnis. Es handelt sich also nicht um ein universelles Ergebnis, sondern um ein kontextabhängiges, und diese Nuance ist entscheidend, um die Aussagen des Papiers nicht misszuverstehen.

Die von den Autoren vorgeschlagene Hypothese zur Erklärung der Tendenz zur Weitschweifigkeit bei großen Modellen lautet, dass der Prozess der Ausrichtung durch menschliches Feedback (RLHF) diese Modelle unbeabsichtigt auf eine übermäßige Verarbeitung trainiert hat. Menschliche Bewerter neigen dazu, lange und scheinbar vollständige Antworten zu belohnen, was zu einem systematischen Bias führt, der mit der Größe des Modells skaliert. Dies ist eine plausible Erklärung, die mit anderen bekannten Phänomenen beim Modelltraining übereinstimmt, auch wenn sie eine Interpretationshypothese bleibt, die weiter überprüft werden muss.

Das Mammut im Raum

Die Daten zeigen: Caveman funktioniert, zumindest in bestimmten Kontexten. Die angegebene Ersparnis ist real und messbar, die wissenschaftliche Grundlage existiert und ist nicht trivial, der technische Mechanismus ist transparent und für jeden überprüfbar. Aber eine ehrliche Analyse erfordert es, auch die Vorbehalte auf den Tisch zu legen, und davon gibt es mehrere.

Der erste Vorbehalt betrifft die Qualität der Antworten bei komplexen Aufgaben. Ist eine kürzere Antwort immer eine bessere Antwort? Das Papier von Hakim sagt für bestimmte Arten von Problemen ausdrücklich nein, und diese Intuition ist in der täglichen Praxis überprüfbar. Wenn man an einem obskuren Bug arbeitet, an einem Architekturproblem mit vielen Variablen oder an schlecht dokumentiertem Legacy-Code, hat eine Antwort, die den Gedankengang Schritt für Schritt erklärt, einen Wert, der über die rein notwendige Informationsmenge hinausgeht: Sie hilft zu verstehen, zu verifizieren und ein mentales Modell aufzubauen. Diese Erklärung im Namen der Effizienz zu streichen, kann zu mehr Iterationen, mehr Klärungsfragen und mehr Zeitverlust führen, was die anfängliche Ersparnis zunichtemacht.

Dies führt zum zweiten Vorbehalt, der die differenzierte Nutzererfahrung betrifft. Für einen Senior-Entwickler, der einen Agenten als Beschleuniger nutzt, der den Code kennt, an dem er arbeitet, und eher schnelle Bestätigungen als Erklärungen benötigt, ist Caveman wahrscheinlich ein Nettogewinn. Für einen Junior, der den Assistenten auch zum Lernen nutzt, für jemanden, der sich in ein neues technisches Gebiet einarbeitet, oder für diejenigen, die Agenten in Kontexten jenseits des reinen Codings einsetzen – wie technisches Schreiben, Sicherheitsanalysen oder Unterstützung bei Architektur-Entscheidungen –, kann die übermäßige Zusammenfassung die kognitive Belastung erhöhen und eher Verwirrung als Klarheit stiften.

Schließlich sollte man bedenken, dass die verfügbaren wissenschaftlichen Belege zwar das Prinzip der Kürze als nützliche Einschränkung stützen, aber Caveman nicht spezifisch als Implementierung validieren. Das Papier von Hakim wurde auf arXiv veröffentlicht, befand sich zum Zeitpunkt des Verfassens dieses Artikels noch in der Pre-Print-Phase und wurde noch keiner formalen Prüfung durch die akademische Gemeinschaft unterzogen. Das Tool von Brussee hat mit 33,5k Sternen auf GitHub innerhalb weniger Tage die Aufmerksamkeit der Tech-Community auf sich gezogen, was nicht unterschätzt werden darf, aber es war nicht Gegenstand einer unabhängigen und systematischen Bewertung durch Dritte. Dies sind Zeichen für echtes Interesse, nicht für eine zertifizierte Validierung.

Schlussstein oder Meteoro?

Die interessanteste Frage, die Caveman aufwirft, ist nicht technischer, sondern methodischer Natur. Wenn die leistungsfähigsten Sprachmodelle strukturell dazu neigen, weitschweifiger zu antworten, und wenn diese Weitschweifigkeit oft sowohl für die Kosten als auch – überraschenderweise – für die Qualität der Antworten bei bestimmten Arten von Problemen schädlich ist, dann ist das Problem nicht Caveman: Es liegt in der Art und Weise, wie diese Modelle trainiert und bewertet werden.

Das Papier von Hakim schlägt einen Ansatz vor, den es problem-aware routing nennt: kleine Modelle für Aufgaben zu verwenden, in denen sie natürlicherweise glänzen oder in denen Kürze-Beschränkungen den großen Modellen nicht helfen, und große Modelle mit Kürze-Beschränkungen für Aufgaben zu verwenden, in denen sie überlegene latente Fähigkeiten besitzen, aber zu übermäßiger Verarbeitung neigen. Dieser Ansatz, so die Autoren, kann gleichzeitig Genauigkeit und Kosten verbessern. Das ist keine Science-Fiction: Es ist eine Form des Prompt-Engineerings, die sich der Modellskalierung bewusst ist – eine Idee, die in professionellen agentenbasierten Workflows gängige Praxis werden könnte.

In diesem Sinne ist Caveman nicht einfach nur ein Trick, um ein paar Cent bei der API zu sparen. Es ist eine praktische Demonstration eines Prinzips, das die Forschung gerade zu formalisieren beginnt: Dass Systemanweisungen nicht dekorativ sind, dass die Art und Weise, wie ein Modell abgefragt wird, nicht nur die Form, sondern auch die Qualität der Antwort verändert, und dass die Optimierung der Mensch-Maschine-Schnittstelle messbare Folgen für die Leistung des Gesamtsystems hat.

Legitime Fragen bleiben offen. Überträgt sich das Muster wirklich auf alle Arten von Aufgaben oder nur auf die strukturierten Aufgaben des Codings? Wie misst man den Netto-ROI, wenn man die Kosten für zusätzliche Iterationen in die Rechnung einbezieht, die eine zu knappe Antwort verursachen kann? Wie sehr beeinflusst die Vertrautheit des Nutzers mit dem technischen Gebiet, ob Kürze ein Vorteil oder ein Nachteil ist? Und um zur großen Kernfrage zurückzukehren: Wenn Kürze die Leistung verbessert, warum werden Modelle dann nicht nativ darauf trainiert, prägnanter zu antworten?

Letzteres ist vielleicht die wichtigste Frage, und die im Papier von Hakim implizierte Antwort ist unbequem: Weil das menschliche Feedback, auf dem die Ausrichtung dieser Modelle basiert, oft Länge der Präzision und Höflichkeit der Informationsdichte vorzieht. Wir sind es – als Bewerter, als Nutzer, als Auftraggeber –, die die Modelle auf Weitschweifigkeit trainiert haben. Caveman ist im Grunde ein handwerklich hergestelltes Korrektiv für ein systemisches Problem, das viel weiter vorne entsteht.

Fred Feuerstein hatte wahrscheinlich schon alles verstanden. Kleine Höhle, wesentliche Werkzeuge, großes Ergebnis. Der Rest ist nur zusätzlicher Stein, den man mitschleppt.