Zwingt man KI zum Höhlenmenschen? Das Claude-Plugin zur Vermeidung von langatmigen Antworten wird viral. Internetnutzer: "Wir haben es satt, von KI mit unnötigen Worten bombardiert zu werden."
In letzter Zeit hat ein Claude Code - Plugin namens „caveman“ (Höhlenmensch) auf Hacker News für Furore gesorgt.
Schauen wir uns zunächst ein Bild an.
Aus der Wachstumskurve der GitHub - Sterne geht hervor, dass „JuliusBrussee/caveman“ in einem langen Anfangszeitraum nur langsam anstieg und dann plötzlich stark nach oben schoss:
Innerhalb von nur etwa einem halben Tag stieg die Anzahl der Sterne von einigen Dutzend auf 500 und hat inzwischen die 20.000 überschritten!
Die Fähigkeit von „Höhlenmensch“ zur Token - Einsparung ist heiß geworden!
Hinter dem plötzlichen Ruhm von caveman verbirgt sich eigentlich eine typische Resonanz der Communitystimmung.
Es bedeutet, dass das Problem des „AI - Geschwätzes“ (wortreicher Unsinn), das zwar klein aussieht, aber bereits zahlreiche Menschen über den Rand gebracht hat, erneut präzise aufgedeckt wurde.
Schon bald nannten einige Internetnutzer caveman die „besten Prompt - Tricks von 2026“ und sagten, dass es die Tokens einsparen kann, die für höfliche Einleitungen wie „Ich helfe Ihnen gerne“ verschwendet werden.
Das, was dieses Plugin tut, ist eigentlich sehr einfach: Es lässt den AI - Agenten wie ein Höhlenmensch sprechen.
Es löscht „the“, „please“, „thank you“ … all das, was keine technische Bedeutung hat, aber die Tokens verschlingt, also die „menschlichen Höflichkeiten“.
https://github.com/JuliusBrussee/caveman
Das Projekt stammt vom Entwickler Julius Brussee, und das GitHub - Repository heißt „JuliusBrussee/caveman“.
Die zentrale Frage, die Julius in der README - Datei stellt, ist sehr direkt: Warum sollte man so viele Tokens verwenden, wenn man das Gleiche mit weniger Tokens sagen kann?
Dies ist ein Skill/Plugin, das sowohl für „Claude Code“ als auch für „Codex“ kompatibel ist.
Der Kerngedanke besteht darin, dass der Agent wie ein „Urmensch“ spricht. Ohne die technische Genauigkeit zu opfern, wird die Ausgabe so stark wie möglich komprimiert, und es wird behauptet, dass der Tokenverbrauch um etwa 75 % reduziert werden kann.
Damit ergeben sich auch Fragen: Kann man wirklich drei Viertel der Kosten sparen, indem man Artikel und höfliche Ausdrücke entfernt?
Wenn man die SKILL.md durchsucht, sind die Netizens fassungslos. Das hier?
Wie spart caveman überhaupt „Tokens“?
Wenn man die Kern - Datei SKILL.md öffnet, ist der Inhalt tatsächlich nicht lang.
https://raw.githubusercontent.com/JuliusBrussee/caveman/main/skills/caveman/SKILL.md
Die Frontmatter der Datei definiert es direkt als „Ultra - komprimierter Kommunikationsmodus“.
Und es wird geschrieben:
Indem man wie ein Höhlenmensch spricht, soll das Ziel sein, den Tokenverbrauch so niedrig wie möglich zu halten, ohne die technische Genauigkeit zu verlieren.
Es wird aktiviert, wenn der Benutzer „caveman mode“, „talk like caveman“, „use caveman“, „less tokens“, „be brief“ sagt oder „/caveman“ aufruft.
Es kann auch automatisch ausgelöst werden, wenn der Benutzer explizit eine höhere Token - Effizienz fordert.
Die Regeln zur Token - Einsparung sind sehr einfach und brutal: Keine Artikel, kein Geschwätz, keine Höflichkeiten; technische Begriffe und Code - Blöcke bleiben erhalten, alles andere kann gelöscht werden.
Folgendes wird gelöscht: Artikel, Füllwörter, Höflichkeiten, zögerliche Ausdrücke.
Kurze Sätze und Satzfragmente sind erlaubt.
Es werden lieber kürzere Synonyme verwendet, z. B. „groß“ anstatt „riesig“ und „reparieren“ anstatt „eine Lösung implementieren“.
Technische Begriffe müssen exakt bleiben.
Code - Blöcke werden nicht geändert.
Fehlermeldungen müssen wörtlich zitiert werden.
Empfohlene Satzstruktur: [Problem][Aktion][Grund]. [Nächster Schritt].
Beispielsweise soll man nicht so schreiben: „Natürlich! Ich helfe Ihnen gerne. Das Problem, das Sie haben, wird wahrscheinlich durch … verursacht …“
Sondern so: „Fehler in der Authentifizierungsmiddleware. Die Token - Ablaufprüfung verwendet < anstatt <=. Ändern Sie hier:“
Es unterstützt drei Intensitätsstufen: lite, full (Standard), ultra.
lite: Füllwörter und zögerliche Ausdrücke entfernen. Vollständige Sätze und normale schriftliche Form bewahren. Professionell und prägnant;
full: Weitere Komprimierung der Ausdrücke, einige Funktionswörter können weggelassen werden, Satzfragmente sind erlaubt, kurze Wörter werden anstelle längerer verwendet. Typischer Höhlenmensch - Stil;
ultra: Viele Abkürzungen, wie DB, auth, config, req, res, fn, impl; Verbindungswoerter werden so weit wie möglich entfernt; Kausalität wird mit Pfeilen ausgedrückt, z. B. „X → Y“; wenn ein Wort reicht, werden nicht zwei verwendet.
Hier ein Beispiel:
lite: „Der Verbindungspool wiederverwendet bereits geöffnete Datenbankverbindungen anstatt bei jeder Anfrage eine neue zu erstellen, um so die Kosten für wiederholte Handshakes zu vermeiden.“
full: „Verbindungspool wiederverwendet geöffnete DB - Verbindungen. Keine neue Verbindung bei jeder Anfrage. Handshake - Kosten sparen.“
ultra: „Verbindungspool = DB - Verbindungen wiederverwenden. Handshake überspringen → Schneller bei hoher Last.“
Natürlich hat bei Sicherheitswarnungen, Bestätigungen für irreversible Aktionen, mehrstufigen Prozessen oder wenn der Benutzer offensichtlich verwirrt ist, die klare Ausdrucksweise Vorrang. Dies ist auch die Ausnahmelogik, die in der SKILL.md explizit geschrieben ist.
Ohne Änderungen an der Modellarchitektur und ohne Komprimierung auf der Ebene des Inferences - Mechanismus ist caveman im Wesentlichen ein sorgfältig geschriebener System - Prompt, der den Ausgabestil der KI einschränkt.
Wichtig ist auch: Der Autor Julius Brussee hat in einem HN - Diskussionsbeitrag selbst erklärt, dass dieser Skill nicht auf versteckte Denk - Tokens und Überlegungs - Tokens angewendet wird.
Der Prozess, in dem das Modell im Hintergrund „denkt“, wird durch caveman nicht automatisch kürzer. Es komprimiert hauptsächlich den endgültigen Ausgabeteil.
In der offiziellen Anthropic - Dokumentation wird auch erwähnt, dass der Name und die Beschreibung von Skills selbst den Kontext - Budget verbrauchen.
Mit anderen Worten, das Laden des caveman - Skills verbraucht selbst Tokens.
Deshalb ist die tatsächliche Kostenersparnis von Ende zu Ende möglicherweise nicht gleich der auffälligen „75 %“ in der README - Datei.
Daher komprimiert caveman wahrscheinlich die sichtbare Ausgabelänge erheblich, aber dies sollte nicht direkt als gleicher Anteil an Gesamtkostenreduktion verstanden werden.
Wie zuverlässig ist die 75 % - Angabe in der README?
Aus den öffentlichen Inhalten des Repositories geht hervor, dass der Autor tatsächlich ein Benchmark - Skript zur Verfügung gestellt hat, und in der README werden auch die Token - Vergleiche für mehrere Aufgaben aufgelistet, die zwischen 22 % und 87 % liegen, im Durchschnitt 65 %.
Bis jetzt ist im öffentlichen Repository nur das Testskript und eine Beispieltabelle direkt sichtbar. Die Außenwelt hat es immer noch schwer, anhand der aktuellen Inhalte des Repositories die Replikationskette für jedes Ergebnis vollständig zu überprüfen.
Der Autor hat in einem HN - Beitrag angegeben, dass dies nur ein erster Test und kein strenger Benchmark ist.
Allerdings hat die akademische Welt sich tatsächlich mit der Frage beschäftigt, ob prägnante Ausdrücke die Leistung der KI beeinträchtigen.
https://arxiv.org/pdf/2401.05618
Eine Studie aus dem Jahr 2024 mit dem Titel „The Benefits of a Concise Chain of Thought on Problem - Solving in Large Language Models“ zeigt:
Wenn die Forscher das Modell aufforderten, eine prägnantere Denk - Kette zu verwenden, sank die durchschnittliche Antwortlänge von GPT - 3.5 und GPT - 4 um 48.70 %, und die Gesamtleistung bei Problemlösungen nahm fast nicht signifikant ab. Bei mathematischen Aufgaben sank die Leistung von GPT - 3.5 jedoch im Durchschnitt um 27.69 %.
Eine Studie aus dem Jahr 2026 mit dem Titel „Brevity Constraints Reverse Performance Hierarchies in Language Models“ geht noch einen Schritt weiter und zeigt:
Bei einigen Benchmarks kann die Genauigkeit um 26 Prozentpunkte gesteigert werden, wenn man großen Modellen prägnante Beschränkungen auferlegt. Dies kann sogar die ursprüngliche Leistungsreihenfolge zwischen Modellen unterschiedlicher Größe ändern.
https://arxiv.org/pdf/2604.00025
Diese beiden Studien bieten einen Forschungshintergrund für die These, dass Prägnanz nicht unbedingt die Leistung beeinträchtigt.
Aber es muss klar sein: Sie untersuchen die Wirkung von Prägnanz