Caveman, Tokenökonomie und minimalistisches Coding

Du prüfst Caveman immer gegen drei klar getrennte Ebenen:

• Skill (Prompt): „antworte wie ein Höhlenmensch". Reduziert NUR Output-Token, NICHT Reasoning oder Input-Token. Das sagt das Repo selbst explizit ([CAV-02], [CAV-03]).
• Code-Agent (Tooling): Caveman Code ist ein separater Coding-Agent. Herstellerclaim: 1,93× weniger verbrauchte Token als Codex CLI (524.703 vs. 1.010.185 tokens_fresh; NICHT „1,93× schneller" — die Wall-Clock-Zeit variiert task-abhängig) — keine unabhängige Bestätigung ([CAV-07]).
• Prinzip (Token-/Code-Minimalismus): Der übergeordnete Leitfaden zum sparsamen Umgang mit Tokens und Code.

Die häufigste Falle: Die Hersteller-Zahl „65% Output-Reduktion" ([CAV-04]) wird als harter Fakt gelesen. Sie ist ein Projektclaim, gemessen an nur 10 Prompts mit einer Spanne von 22–87%. Unabhängig reproduziert wurde eher ~31% statt 65–75% ([CAV-05], cipherfoxie, 5 Modelle).

Miniübung: Lies die Projekt-Bewerbung und ordne jede Zahl einer der drei Ebenen zu. Markiere jede Zahl als „Hersteller-Messung", „unabhängig reproduziert" oder „ungeprüft".

Auf Level 2 geht es um die echten Fakten — strikt zwischen Hersteller-Claim und unabhängiger Bestätigung getrennt.

Echte Fakten zum Caveman-Skill

• Reduziert NUR Output-Token, nicht Reasoning, nicht Input ([CAV-02], [CAV-03]). Das Repo dokumentiert diesen Mechanismus in HONEST-NUMBERS.md selbst.
• Herstellerclaim: 65% Output-Reduktion ([CAV-04]). Gemessen an 10 Prompts, Spanne 22–87%. Nur Projektclaim.
• Unabhängig reproduziert: ~31% statt 65–75% ([CAV-05], cipherfoxie Discussion #520, 5 Modelle). Die einzige verfügbare unabhängige Mehr-Modell-Messung.
• Bei Coding-Anwendungen vernachlässigbar bis negativ. Coding ist cache-dominiert — Cache-Reads machen ~97% der Token aus. Dort hat Caveman keinen positiven Effekt auf die Rechnung. Das Repo räumt das in HONEST-NUMBERS.md selbst ein ([CAV-06], romainfjgaspard + Issue #550).
• arXiv 2604.00025 „Brevity Constraints Reverse Performance Hierarchies" ([CAV-08], Hakim, eingereicht 2026-03-11, Preprint): Brevity-Constraints verbessern Accuracy um 26 Prozentpunkte über 31 Modelle (0,5B–405B) und 1.485 Probleme. Hinweis: Preprint, noch kein Peer-Review.

Fakten zu Caveman Code (Code-Agent)

• Herstellerclaim: 1,93× vs. Codex CLI ([CAV-07]). 25 Tasks, Modell gpt-5.5, Schwierigkeit xhigh.
• Genau hingeschaut: 14/25 vs. 15/25 resolved — das ist NICHT „gleiche Genauigkeit". Es ist ein leichter Genauigkeitsverlust zugunsten von Geschwindigkeit.
• Keine unabhängige Bestätigung gefunden.

Token-Minimalismus-Leitfaden (10 Ebenen)

1. Auftrag: Klare, kompakte Aufgabenstellung statt offener Essays.
2. Kontext: Nur relevante Quellen, unnötige Historie entfernen.
3. Suche: Gezielt statt breit, Treffer begrenzen.
4. Antwort: Längenbegrenzung, kompakte Antwortformate.
5. Code-Diffs: Nur geänderte Zeilen, kein vollständiger Re-Output.
6. Tools filtern: Nicht jedes Tool pro Schritt aufrufen.
7. Memory: Wiederverwenden statt neu erzeugen.
8. Caching: Cache-Reads nutzen, identische Abfragen vermeiden.
9. Model Routing: Kleine Aufgabe → kleines Modell.
10. Stop-Bedingung: Früh abbrechen, wenn Ziel erreicht.

Code-Minimalismus-Regeln

• Kleinster korrekter Patch: Nur ändern, was geändert werden muss.
• Keine unnötige Abstraktion/Dependency: Nicht jede Wiederholung rechtfertigt eine Klasse oder Lib.
• Keine zweite Source of Truth: Ein Datenpunkt lebt an einem Ort.
• Kommentare erklären das Warum, nicht das Was.
• Tests nach Risiko: Kritische Pfade zuerst, nicht „überall 100%".

Vorher solltest du LLM-Grundlagen und Prompt Engineering verstanden haben.

Auf Expertenniveau geht es um die Nachteile, die modellabhängige Wirkung und die Security.

Nachteile und Praxisfallen:

• Verlorene Nuance: Kompakter Output verliert oft Feinheiten, Einschränkungen und Warnungen.
• Übersehene Warnungen: Gerade in sicherheitskritischen Antworten ist „kurz" gefährlich, wenn Warnhinweise entfallen.
• Schlechtere Wartbarkeit: Komprimierter Code kann schwerer lesbar sein, weil Lokalität und Kommentare zurückgehen.
• Modellabhängig: Fable 5 produzierte in einer Messung 18% längere Outputs statt kürzere. Der Effekt ist kein Naturgesetz, sondern hängt vom Modell ab.
• Herstellerclaims kritisch lesen: 65% ([CAV-04]), 1,93× ([CAV-07]) und „production since late June 2026" sind Projektclaims — nicht mit unabhängig gemessenen Fakten ([CAV-05], [CAV-06]) gleichsetzen.
• Coding-Anwendungen: Weil Cache-Reads ~97% der Token ausmachen, ist der Effekt von Output-Reduktion auf die Rechnung bei Coding-Anwendungen „vernachlässigbar bis negativ" ([CAV-06]).

Security:

• Keine Telemetrie, nur lokale Dateien ([CAV-09], SECURITY.md). Datentechnisch unauffällig.
• Pipe-to-shell-Installationsrisiko: Ein curl … | bash oder vergleichbarer Installationspfad bleibt ein klassisches Supply-Chain-Risiko, auch wenn die Runtime selbst unauffällig ist.

Goldstandard: Du kannst einem Laien erklären, warum ein Prompt-Skill nicht mit einem Code-Agent zu verwechseln ist; du trennst Hersteller-Messung ([CAV-04], [CAV-07]) von unabhängiger Reproduktion ([CAV-05], [CAV-06]); du kennst den arXiv-Beleg-Stolperstein ([CAV-08]); und du erkennst, dass Token-Minimalismus nicht bei jedem Lastprofil spart.

Verwandte Begriffe für die Vertiefung: Modelle benchmarken, AI-Hardware für lokale Modelle, LLM-Grundlagen.