Kurz gesagt
- Caveman kürzt, was ein Coding-Agent sagt. Ponytail verkleinert, was er baut. Beide arbeiten auf verschiedenen Ebenen und lassen sich kombinieren.
- Beworben: Caveman 65 % weniger Tokens, Ponytail 54 % weniger Code und 20 % weniger Kosten. Unabhängig gemessen: Caveman 8,5 % weniger Output-Tokens, Ponytail 15,4 % weniger Code und 10,3 % weniger Kosten, bei beiden ohne Qualitätsverlust.
- Weniger reden spart kaum etwas, weil der Output eines Agenten vor allem aus Code, Diffs und Tool-Aufrufen besteht. Die fasst Caveman nicht an.
- Prüf, ob ein Skill überhaupt aktiv wird, und miss auf 50 oder mehr Aufgaben. Nur installiert, sprang Ponytail in unabhängigen Tests kein einziges Mal an.
- Der größte Hebel liegt oft auf der dritten Ebene: kompakter, typisierter Kontext statt Seiten, die der Agent lesen muss.
Zwei der beliebtesten Claude-Code-Skills 2026 versprechen dasselbe: eine kleinere Rechnung. Caveman lässt den Agenten reden wie ein Höhlenmensch und wirbt mit 65 % weniger Tokens. Ponytail lässt ihn bauen wie einen faulen Senior Engineer und wirbt mit 54 % weniger Code und 20 % weniger Kosten. Unabhängige Tests haben von beiden Versprechen nur einen Bruchteil gemessen. Die Lücke zwischen den Zahlen sagt dir mehr darüber, wohin das Geld eines Agenten fließt, als jedes README.
Was Ponytail und Caveman wirklich verändern
Sie wirken wie Konkurrenten, weil beide als Token-Sparer auftreten. Sind sie nicht. Jeder komprimiert eine andere Ebene dessen, was ein Coding-Agent produziert, und die Ebene bestimmt, wie viel es zu sparen gibt.
| Caveman | Ponytail | |
|---|---|---|
| Komprimiert | Was der Agent sagt | Was der Agent baut |
| Mechanik | Knappe Prosa, Füllwörter fliegen raus | Eine Entscheidungsleiter: Muss es existieren, gibt es das schon in der Codebasis, deckt die Standardbibliothek oder eine native Plattformfunktion es ab, erst dann der minimale Code |
| Lässt in Ruhe | Code, Fehlermeldungen, Dateipfade, Sicherheitswarnungen | Prosa und alles, was Validierung, Fehlerbehandlung, Sicherheit oder Barrierefreiheit betrifft |
| Modi | lite, full, ultra, dazu Varianten auf klassischem Chinesisch | lite, full, ultra |
| Lizenz | MIT (Skill), BSL 1.1 (Proxy-Engine) | MIT |
Beide sind kostenlos, beide installierst du mit einem Befehl, und das README von Ponytail empfiehlt ausdrücklich, sie zusammen zu nutzen: „Caveman shrinks what the agent says; ponytail shrinks what it builds.“
Darunter liegt eine dritte Ebene: der Kontext, den der Agent liest. Tools wie Headroom und RTK komprimieren Tool-Output, Logs und JSON, bevor das Modell sie sieht. Auf diese Ebene kommen wir am Ende zurück, weil die meisten Teams sie vernachlässigen.
Was die READMEs versprechen
Caveman titelt „cuts 65% of tokens by talking like a caveman“. Das Vorzeigebeispiel ist eine Chat-Antwort: Die Erklärung eines React-Re-Render-Bugs schrumpft von 69 auf 19 Tokens.
Ponytail titelt „~54% less code (up to 94%), ~20% cheaper, ~27% faster, 100% safe“. Fairerweise hat diese Zahl schon eine öffentliche Korrektur überstanden. Die erste Version des Benchmarks verglich mit einem nackten, geschwätzigen Modell und meldete 80 bis 94 % weniger Code. Colin Eberhardt kritisierte, dass die Vergleichsbasis ihre Antworten mit Prosa und Optionen aufblähte. Der Autor baute den Benchmark neu auf: echte Claude-Code-Sessions ohne Oberfläche auf einem echten FastAPI- und React-Repository, derselbe Agent ohne Skill als Basis. Veröffentlicht hat er dann die kleinere Zahl.
Dieser neue Benchmark ist zugleich der einzige direkte Vergleich beider Skills, weil Caveman darin als Kontrollgruppe läuft. Vom Autor selbst gemessen, Haiku 4.5, 12 Feature-Aufgaben, je vier Durchläufe:
| gegen Basis ohne Skill | Codezeilen | Tokens | Kosten | Zeit | Sicher |
|---|---|---|---|---|---|
| Ponytail | -54 % | -22 % | -20 % | -27 % | 100 % |
| Caveman | -20 % | +7 % | +3 % | +2 % | 100 % |
| Prompt „Follow YAGNI, prefer one-liners“ | -33 % | -14 % | -21 % | -30 % | 95 % |
Zwei Details zählen. Caveman machte die Sessions etwas teurer statt günstiger. Und der Prompt aus sieben Wörtern hielt bei Kosten und Zeit mit Ponytail mit, schwankte aber bei der Codemenge und schrieb als einzige Variante eine unsichere Funktion: Bei einer Aufgabe zum Zusammensetzen von Pfaden ließ er in einem von vier Läufen die Prüfung auf Path Traversal weg.
Was unabhängige Tests gemessen haben
JetBrains hat beide Skills durch einen sauberen Testaufbau geschickt: Aufgaben aus SkillsBench in Docker-Sandboxes, Claude Code im Headless-Modus, gepaarte Läufe mit und ohne Skill, Signifikanztests. Die Ponytail-Runde lief mit claude-sonnet-5 auf 80 gepaarten Aufgaben, 251 abgerechneten Durchläufen und 246 $ API-Kosten.
| Versprechen | Beworben | Von JetBrains gemessen |
|---|---|---|
| Caveman, Output-Tokens | -65 % | -8,5 %, Qualität unverändert |
| Ponytail, Codezeilen | -54 % | -15,4 % (p = 0,088) |
| Ponytail, Kosten | -20 % | -10,3 % (p = 0,004) |
| Ponytail, Zeit | -27 % | -11 % |
| RTK (Terminal-Filter), Kosten | -60 bis -90 % | +7,6 % |
Bei der Qualität schnitt Ponytail in 65 von 80 Aufgaben gleich ab, in neun etwas schlechter und in sechs etwas besser: statistisch nicht zu unterscheiden. JetBrains nannte es „the first tool in this series that clearly saved money“. Das README von Caveman zitiert inzwischen das eigene Ergebnis von 8,5 % neben der Schlagzeile mit 65 %. So ehrlich ist Tool-Marketing selten.
Zwei Ergebnisse dieser Reihe verdienen mehr Aufmerksamkeit als die Schlagzeilen.
Installiert heißt nicht aktiv. Nur installiert, hat sich Ponytail kein einziges Mal selbst aktiviert. JetBrains musste es über einen SessionStart-Hook einspielen, damit es überhaupt etwas tat. Hast du einen Skill installiert und nie geprüft, ob er anspringt, zahlst du womöglich für nichts.
Kleine Stichproben lügen in beide Richtungen. Ein Probelauf mit zehn Aufgaben ergab: Ponytail kürzt den Code um 3 %, macht Läufe 9,6 % teurer und senkt die mittlere Punktzahl von 0,51 auf 0,31. Achtzig Aufgaben kehrten jede dieser Schlussfolgerungen um. Ponytails eigener Benchmark wäre ähnlich fast danebengegangen: Sein Hook feuerte auch in der Vergleichsgruppe, und die Lücke sah nach 4 % aus, bis der Autor die Gruppen sauber trennte.
Warum weniger reden kaum etwas spart
Weil der Output eines Agenten größtenteils kein Gerede ist. Die 65 % von Caveman stimmen für Chat-Antworten, in denen Prosa den Großteil ausmacht. In einer agentischen Session bestehen die meisten Output-Tokens aus Code, Diffs und Tool-Aufrufen, und die lässt Caveman bewusst Byte für Byte unangetastet. Es kann nur die Erzählung zwischen den Tool-Aufrufen kürzen, und die ist ein kleiner Teil der Rechnung. Daher 8,5 % und im Benchmark des Autors sogar ein leichtes Plus.
Ponytail greift den teuren Teil an. Jede Zeile, die ein Agent schreibt, kostet jetzt Output-Tokens und danach Input-Tokens in jeder Runde, die die Datei wieder liest. Dazu kommen Review, Tests und Wartung. Die größten Gewinne im Benchmark kamen nicht aus cleverer Kompression, sondern aus einer anderen Entscheidung: Die Basis baute einen Datepicker mit 404 Zeilen von Hand, Ponytail nahm <input type="date"> und schrieb 23. Dasselbe beim Farbwähler (287 auf 23 Zeilen) und bei der Dropzone für Dateien (251 auf 95). Bei Backend-CRUD-Aufgaben, wo der Code schon minimal war, lagen alle Varianten gleichauf. Ponytail erfindet keine Ersparnis, wo nichts zu kürzen ist. Deshalb liegt der unabhängige Schnitt (-15 %) so weit unter dem besten Fall (-94 %).
Unser eigener Vorbehalt betrifft die Übertragbarkeit. Das Benchmark-Repository hat keine Komponentenbibliothek, also gewinnt „nimm das native Input“ leicht. In einer Codebasis mit festem Design-System ist dessen Wiederverwendung die richtige Antwort. Die Stufe „gibt es das schon in der Codebasis?“ sollte dort hinführen, gemessen hat das aber niemand.
Welchen Skill du nehmen solltest
| Situation | Nimm | Warum |
|---|---|---|
| Agenten bauen Features in einer bestehenden Codebasis | Ponytail | Als einziger mit unabhängig signifikanter Kostensenkung, Qualität unverändert |
| Lange interaktive Sessions, in denen du jede Antwort liest | Caveman | Schneller gelesen; du sparst eher Aufmerksamkeit als Geld |
| Beide zusammen | Passt | Verschiedene Ebenen, keine Überschneidung, vom Autor von Ponytail empfohlen |
| Zugriffsrechte, Zahlungen, Löschungen, Migrationen | Keinen im ultra-Modus | Mehrdeutigkeit kostet hier mehr als Tokens, wie kt.team argumentiert |
| Jeder dieser Fälle | Miss nach | Prüf, ob der Skill aktiv wird, und vergleich die Kosten pro Aufgabe auf 50 oder mehr Aufgaben, nicht auf 10 |
Wenn du nur eine Sache änderst, dann das, was der Agent baut, nicht wie er redet. Und egal, was du wählst: Prüf es auf deinem eigenen Repository. Die beworbenen Zahlen lagen hier bis zum Achtfachen über den gemessenen.
Der Kontext, den der Agent liest
Die dritte Ebene ist der Input. Jede Datei, jedes Log, jedes Suchergebnis und jede API-Antwort, die ein Agent liest, wird in jeder Runde abgerechnet, in der sie im Kontext bleibt. In langen agentischen Sessions übersteigen die Input-Tokens den Output meist um ein Vielfaches. Kontext-Kompressoren wie Headroom setzen genau hier an. Der JetBrains-Test von RTK, einem Filter für Terminal-Output, zeigt allerdings, dass Kompression auch Aufwand hinzufügen kann, statt ihn zu senken.
Der günstigste Kontext ist der, der von Anfang an kompakt war. Ein Agent, der eine gerenderte Webseite liest, zahlt für Markup, Navigation und Skripte, nur um ein paar Felder herauszuziehen. Ein Agent, der eine API aufruft, bekommt genau diese Felder als typisiertes JSON, und wenn etwas schiefgeht, einen maschinenlesbaren Fehler statt eines Screenshots zum Deuten. Weniger und dichtere Tokens pro Schritt summieren sich: Sie senken die Kosten jeder späteren Runde, die sie mitträgt. Curviate wendet das auf LinkedIn an: typisierte Aktionen über eine CLI oder MCP. Mit --fields kürzt du eine Antwort auf die Felder, die der Agent braucht, und ein wiederholter Profilabruf kommt aus einer gespeicherten Kopie. So fließen die Tokens in die Aufgabe statt in die Seite.
