30 Punkte von GN⁺ 24 일 전 | 2 Kommentare | Auf WhatsApp teilen
  • Eine Technik, die Antworten in Urmenschen-Sprechweise erzwingt und so im Schnitt 65–75 % der Output-Token einspart
  • Die Kompressionsstärke lässt sich in drei Stufen Lite · Full · Ultra regeln und erzeugt kurze, effiziente Antworten, ohne die technische Genauigkeit zu verlieren
  • In realen Benchmarks sank bei Erklärungen zu React, PostgreSQL und Git der Token-Verbrauch jeweils auf weniger als die Hälfte
  • Bietet gleichzeitig etwa 3× schnellere Antwortzeiten, bessere Lesbarkeit und geringere Kosten
  • Lässt sich in Claude Code und Codex mit einfachen Befehlen installieren und bleibt über die gesamte Sitzung hinweg aktiv

Überblick über Caveman

  • Ein Plugin für Claude Code und Codex, das LLM-Antworten in „Urmenschen-Sprechweise (caveman-speak)“ umwandelt und so den Token-Verbrauch um rund 75 % senkt
  • Entfernt unnötige Wörter, während die technische Genauigkeit erhalten bleibt, und erzeugt so kurze, effiziente Antworten
  • Die Installation ist mit einem Ein-Zeilen-Befehl möglich und bleibt in allen Sitzungen dauerhaft nutzbar
  • Nur Output-Token werden reduziert — Denk-/Reasoning-Token bleiben unbeeinflusst
  • Wird entfernt:
    • Begrüßungen/Einleitungen: "Sure, I'd be happy to help" (8 verschwendete Token)
    • Einleitende Begründungen: "The reason this is happening is because" (7 Token)
    • Empfehlungsausdrücke: "I would recommend that you consider" (7 Token)
    • Überflüssige Einstiege: "Sure, let me take a look at that for you" (10 Token)
  • Beibehalten werden: Code-Blöcke, Fachbegriffe (z. B. polymorphism), Fehlermeldungen, git-Commit- und PR-Nachrichten

Vorher-/Nachher-Beispiele

  • Dieselbe technische Erklärung wird in kurze Sätze komprimiert
    • Erklärung der Ursache für React-Komponenten-Re-Rendering: 69 Token → 19 Token
    • Erklärung eines Bugs in Authentication-Middleware: über 75 % Token-Einsparung
  • Die Kompressionsstärke ist in drei Stufen Lite / Full / Ultra regelbar
    • Lite (/caveman lite): Entfernt unnötige Formulierungen, Grammatik bleibt erhalten — professionell, aber ohne Ballast
    • Full (/caveman full): Standard-Caveman-Modus — Artikel weggelassen, kurze und fragmentarische Sätze
    • Ultra (/caveman ultra): Maximale Kompression — Telegrammstil, alles verkürzt

Benchmarks

  • Vergleich echter Token-Nutzung über die Claude API zeigt durchschnittlich 65 % Einsparung
  • Einsparungsbereich: 22 % bis 87 %
    • Erklärung eines React-Re-Rendering-Bugs: 1.180 → 159 Token (87 % Einsparung)
    • PostgreSQL-Connection-Pool-Konfiguration: 2.347 → 380 Token (84 % Einsparung)
    • Docker-Multistage-Build: 1.042 → 290 Token (72 % Einsparung)
    • Erklärung von git rebase vs merge: 702 → 292 Token (58 % Einsparung)
    • Refactoring von Callback → async/await: 387 → 301 Token (22 % Einsparung, geringster Effekt)
  • Nur Output-Token werden reduziert, Denk-/Reasoning-Token bleiben unverändert
  • Die wichtigsten Vorteile sind bessere Lesbarkeit und höhere Antwortgeschwindigkeit; geringere Kosten sind ein Nebeneffekt

Wissenschaftliche Grundlage

  • Papier vom März 2026 "Brevity Constraints Reverse Performance Hierarchies in Language Models": Wenn große Modelle zu knappen Antworten gezwungen wurden, stieg auf bestimmten Benchmarks die Genauigkeit um 26 Prozentpunkte, und die Leistungsrangfolge kehrte sich um
  • "Verbose not always better. Sometimes less word = more correct"
    • Kürzere Antworten können in manchen Fällen genauer sein als ausführliche

Installation

  • Ein-Zeilen-Installation: npx skills add JuliusBrussee/caveman
  • Claude-Code-Plugin: claude plugin marketplace add JuliusBrussee/caveman
  • Codex: Repository klonen und anschließend im /plugins-Menü nach Caveman suchen und installieren
  • Trigger: /caveman, "talk like caveman", "caveman mode", "less tokens please"
  • Deaktivieren: "stop caveman" oder "normal mode"
  • Einmal installieren → gilt danach für die gesamte Sitzung

Verwendung

  • Trigger-Befehle: /caveman, $caveman, “talk like caveman”, “caveman mode”, “less tokens please”

  • Beenden-Befehle: “stop caveman”, “normal mode”

  • Stärke anpassen

    Level Trigger Merkmale
    Lite /caveman lite Grammatik bleibt erhalten, unnötige Wörter werden entfernt
    Full /caveman full Standardmodus, Artikel und Ballast werden entfernt
    Ultra /caveman ultra Maximale Kompression, Ausdruck vor allem über Abkürzungen
  • Die Einstellung bleibt bis zum Sitzungsende aktiv

  • MIT-Lizenz / Python 100 % / Plugin-Support für Claude Code & Codex

2 Kommentare

 
joyfui 24 일 전

Spartanischer Tonfall hier..? Haha

 
GN⁺ 24 일 전
Hacker-News-Kommentare
  • Ich bin der Autor. Einige Leute widerlegen stärkere Behauptungen als das, was dieses Repository tatsächlich behauptet. In Wirklichkeit ist das als Witz entstanden und kein Kommentar auf Forschungsniveau.
    Bei diesem Skill geht es nicht darum, versteckte Reasoning-Token zu verringern, sondern darum, überflüssigen Ballast im Ausgabetext zu reduzieren. Auf den Code selbst hat das keinen Einfluss.
    Ich denke, die Anthropic-Modelle sind durch RL so stark getunt, dass es schwer ist, ihre Leistung absichtlich massiv zu verschlechtern.
    Die Angabe „~75 %“ im README basierte auf vorläufigen Tests und hätte vorsichtiger formuliert werden sollen. Derzeit bereite ich ein formelles Benchmarking vor.
    Der Skill ist nicht kostenlos und verbraucht beim Laden einen Teil des Kontexts. Eine echte Bewertung muss daher Input-/Output-Token, Latenz und Qualität gemeinsam berücksichtigen.
    Es gibt auch Forschung dazu, dass knappe Prompts die Antwortlänge reduzieren können, ohne die Qualität zu verschlechtern (Link zum Paper).
    Unterm Strich ist es also eine interessante Idee, aber es gab viele überzogene Interpretationen, und bis zur formellen Auswertung sollte das README genauer formuliert sein.

    • Klingt vernünftig. Online-Diskussionen laufen oft genau so. Trotzdem ist dieser Thread besser als der Durchschnitt, auch wenn er gelegentlich enttäuschend ist.
    • Wenn du Benchmarks willst, würde ich adam-s/testing-claude-agent empfehlen.
    • Kurz gesagt: „Das ist ein Witz. Seid mir nicht böse. Aber irgendwie funktioniert es ein bisschen?“
    • Ich hatte mit LLMs auch schon ähnliche Gespräche und erklärt, dass sie auf kurze Fragen eher kurz antworten und auf höfliche Bitten eher informationsreiche Antworten geben. Letztlich beeinflusst die Art der Frage den Stil der Antwort.
      (Und ich verstehe nicht, warum solche verwandten Kommentare ständig downgevotet werden.)
    • Die Aussage „Anthropic-Modelle sind fürs Coden optimiert, deshalb kann man sie nicht zu schlechterer Leistung zwingen“ ist etwas verwirrend.
      Wenn man einen Prompt wie „verhalte dich dumm“ anhängt, kann man die Leistung natürlich verschlechtern. Die eigentliche Frage ist, wie stark ein bestimmter Ausgabestil tatsächlich wirkt.
  • Ich habe immer gedacht, dass die Schlussfolgerungsfähigkeit eines LLM nachlässt, wenn man es zwingt, anders als in seinem Standardstil zu sprechen.
    Denn einige Layer des Modells müssen sich zwangsläufig entweder darauf konzentrieren, „was gesagt werden soll“ oder „wie es gesagt werden soll“.
    Bei Experimenten mit kollaborativem Schreiben oder Rollenspiel habe ich gesehen, dass es dem Modell umso schwerer fällt, den Stil beizubehalten, je mehr Fakten es berücksichtigen muss.

    • Umgekehrt steigt die Ausgabe stark an, wenn man sagt: „Sprich gesprächig.“ Persönlichkeits-Anweisungen haben tatsächlich großen Einfluss.
    • Ich sehe das ähnlich. Am Ende hat das Modell nur ein begrenztes Attention-Budget, also ist auch begrenzt, wie viel es gleichzeitig leisten kann.
  • Die Idee ist interessant. Aber ich würde auch gern eine Richtung sehen, die nicht auf einfache Token, sondern auf reichhaltige Token setzt.
    Zum Beispiel statt „make good“ eher etwas wie „improve idiomatically“. Sprache ist ein Modulator, der die Realität justiert, daher könnte ein feinerer Einsatz bessere Ergebnisse liefern. Ich bin auf die Benchmarks gespannt.

    • Dieser „caveman“-Stil erinnert mich an den alten Telegramm-Stil. Könnte das Modell „reichhaltige Token“ lernen, also komprimierte Information wie in einem Telegramm-Abkürzungsbuch, und ein Browser könnte sie wieder decodieren? Link zum Telegramm-Abkürzungsbuch
    • Das wirkt fast wie die Debatte RISC vs. CISC. So wie Einfachheit bei der Skalierung gewonnen hat, entwickeln sich LLMs vielleicht ebenfalls in Richtung einfacher, orthogonaler Konzepte beim Denken.
    • Es wurde vorgeschlagen, Prompts wie „MILSPEC prose register. Max per-token semantic yield.“ auszuprobieren.
  • Ich habe mit Claude im Caveman-Stil gesprochen, aber das Verständnis war schlechter und es gab viele Missverständnisse. Ich musste eher mehr erklären, und bei Tippfehlern geht viel Kontext verloren.
    Am Ende fühlt es sich an, als bräuchte man sogar mehr Wörter. Es scheint auch, als würde das LLM weniger Information aus seinen eigenen vorherigen Antworten ziehen.

    • Auch in allgemeinen Foren wie Twitter oder Reddit beschweren sich Leute, dass LLMs dumm seien, aber wenn man ihre Schreibweise anschaut, versteht man warum.
    • Früher, in den Anfangszeiten von ChatGPT, habe ich einmal nur in s-Expressions kommuniziert, und das Modell antwortete ebenfalls in s-Expressions. Der Inhalt war chaotisch, aber die Klammern stimmten. Heute passiert das nicht mehr.
    • „Warum viele Wort? Wenig Wort spart Zeit. Meer Welt.“
    • Die meisten Daten für diesen „caveman“-Stil stammen wohl nicht aus wissenschaftlichen Gesprächen, daher kann das Modell diesen Kontext offenbar nicht gut vorhersagen.
  • Ich habe einen Text gesehen, in dem ein Grug brained developer auf AI-Tooling trifft (grugbrain.dev).

    • Ich nutze Grug auch oft als Beispiel, wenn ich ein LLM bitte, Konzepte zu erklären.
  • Die Idee ist interessant. Aber in meiner Firma wird Leistung nach Tokenverbrauch bewertet. Gibt es vielleicht auch einen Skill, mit dem man Claude absichtlich wortreicher macht?

    • Lass es in jeder Schleife eine Erklärung im ELI5-Stil nach /tmp schreiben.
    • Ist das ernst gemeint oder ein Witz? Arbeitest du zufällig bei Nvidia?
  • Nette Idee, aber in der Praxis sind Input-Token der Flaschenhals.
    Das Modell liest Unmengen an Dateien, Tool-Ausgaben und Verzeichnisbäumen, aber als Ausgabe kommen nur ein paar hundert Zeilen Code und eine kurze Erklärung.

    • Für einen einzelnen Turn stimmt das, aber über viele Turns hinweg kann die Optimierung der Ausgabe sinnvoll sein.
      Übrigens kommt dieselbe Aussage auch ohne „Nette Idee, aber“ rüber (Link).
    • Außerdem hat dieser Skill keinen Einfluss auf Thinking-Token. Im Gegenteil: Um alles in Caveman-Stil umzuschreiben, könnte sogar mehr internes Reasoning nötig sein.
  • Dazu passend gibt es auch die Studie „Brevity Constraints Reverse Performance Hierarchies in Language Models“ (2026).

  • Interessant. Man könnte die Ausgabe vielleicht auch mit einem 2B-Modell dekomprimieren.

  • Entweder hat das schon jemand versucht, oder ich überlege, es selbst zu bauen.
    Wenn LLMs statt menschlicher Sprache in einer nichtmenschlichen Sprache kommunizieren, könnte das effizienter sein.
    Ein kleines lokales Modell würde menschliche Eingaben in eine LLM-freundliche Sprache übersetzen, das große Modell würde in dieser Sprache „denken“ und anschließend zurückübersetzen.
    Modelle mit kleinem Kontextfenster wie Apple Fundamental Models könnten als solche Übersetzungsschicht dienen.
    Mit Reinforcement Learning könnte man das System diese Sprache vielleicht sogar selbst entdecken lassen. Das wäre ein wirklich spannendes Projekt.

    • Ich hatte einen ähnlichen Gedanken. Es wäre großartig, eine eigene LLM-Sprache zu entwickeln und Modelle darauf zu trainieren, aber dafür bräuchte man vermutlich 60 bis 100 Millionen Dollar.
      Man müsste schließlich eine komplett neue Sprache und Trainingsmethode entwickeln. Wenn jemand dafür VC-Geld einsammelt, wäre ich trotzdem gern dabei.