Caveman: Warum Agenten lernen müssen, weniger zu reden

Caveman klingt zuerst wie ein Witz. "Why use many token when few token do trick" ist absichtlich plump, fast kindisch, und genau deshalb bleibt es hängen. Ein Agent soll weniger labern. Weniger Floskeln, weniger Zusammenfassungen, weniger "Gerne helfe ich dir dabei". Einfach sagen, was Sache ist.

Das wäre als Stil-Plugin schon ganz nett. Aber Caveman ist inzwischen grösser als dieser Witz.

Hinter dem Meme steckt eine ziemlich nüchterne Beobachtung: Moderne Coding-Agenten verbrennen einen grossen Teil ihres Budgets nicht beim Denken, sondern beim Wiederlesen. Sie schicken Systemprompts, Tool-Schemas, Chatverlauf, Log-Ausgaben, JSON, Diffs und Terminal-Rauschen immer wieder an das Modell. Bei langen Sessions bezahlt man nicht nur für neue Arbeit, sondern für das ständige Mitschleppen von altem Kontext.

Caveman versucht genau dort anzusetzen. Nicht mit einem neuen Frontier-Modell. Nicht mit einer weiteren IDE. Sondern mit einer Effizienz-Schicht rund um Agenten: kürzere Antworten, komprimierte Eingaben, lokale Wiederherstellung, Browser-Snapshots mit weniger Token und später ein Cloud-Gateway, das Kosten und Einsparungen sauberer messbar machen soll.¹

Das ist interessanter, als es auf den ersten Blick wirkt.

Der erste Trick: weniger Antwort-Müll

Der sichtbarste Teil ist die Caveman Skill. Sie funktioniert in Claude Code, Codex, Gemini, Cursor, Windsurf, Cline und weiteren Agenten. Die Idee ist brutal einfach: Der Agent soll knapp antworten, aber Code, Befehle, Fehlermeldungen und andere exakte Artefakte unverändert lassen.²

Das ist wichtig, weil nicht jede Kürzung gleich harmlos ist. Bei menschlicher Prosa kann man viel streichen. Bei einem Stacktrace, einem SQL-Fehler oder einem git diff kann ein einzelnes Zeichen entscheidend sein. Caveman verkauft deshalb nicht "mach alles kurz", sondern eher: entferne die Luft, nicht die Substanz.

Die Demo zeigt genau dieses Muster. Aus einer langen höflichen Erklärung wird eine knappe Diagnose: neue Objekt-Referenz pro Render, Inline-Object-Prop, deshalb Re-Render, useMemo verwenden. Das ist kein poetischer Verlust. Es ist das, was viele Entwickler eigentlich wollten.

Trotzdem ist der Skill allein nicht die ganze Story. Caveman selbst dokumentiert den Haken offen: Der Antwort-Skill reduziert nur Output. Input, Kontext und Reasoning bleiben unangetastet, und der Skill selbst kostet pro Turn zusätzlich Kontext. Auf sehr knappen Workloads kann das sogar netto teurer werden.³

Diese Ehrlichkeit macht Caveman glaubwürdiger. Viele AI-Tools verkaufen Prozentzahlen, als wären sie Naturgesetze. Caveman sagt sinngemäss: Miss es. Wenn es bei deinem Workflow nicht spart, schalte es ab.

Der zweite Trick: Agenten lesen zu viel

Der spannendere Teil ist Caveman 2, also Proxy und Engine.

Ein Coding-Agent arbeitet nicht wie ein Mensch, der einmal ein Log liest und sich den relevanten Teil merkt. Er baut eine Sequenz von Modellaufrufen. Jeder Schritt bekommt wieder Kontext. Das ist praktisch, aber teuer. Und es wird schlimmer, je länger die Session läuft.

Caveman Proxy setzt sich lokal zwischen Agent und Provider. Der Agent bleibt derselbe, die API bleibt im Idealfall dieselbe, aber der Datenstrom läuft durch eine lokale Engine. Diese Engine erkennt typische Kontextsorten: Logs, JSON, Tabellen, Code, Diffs, Suchresultate, Terminalausgaben, HTML. Dann versucht sie, diese Nutzlast kleiner zu machen.⁴

Der entscheidende Punkt ist die Wiederherstellung. Caveman speichert die Originalbytes lokal, bevor es etwas verlustbehaftet ersetzt. Wenn der Agent später das exakte Detail braucht, kann er es über einen Recovery-Handle zurückholen.⁴

Das ist die richtige Architekturintuition. Ein Agent braucht oft nicht die volle 90-KB-Logdatei. Er braucht zuerst die Fehlermeldungen, die Stacktraces, die ersten und letzten Zeilen, Pfade, Versionsnummern und auffällige Muster. Aber manchmal braucht er doch die exakte Zeile 7342. Dann darf die Kompression nicht zur Sackgasse werden.

Caveman versucht also nicht, Information einfach wegzuwerfen. Es baut einen Kurztext und legt das Original daneben.

Warum das mehr ist als Kostenoptimierung

Token-Effizienz klingt nach CFO-Thema. Rechnung kleiner, alle glücklich. Bei Agenten greift das zu kurz.

Zu viel Kontext macht Modelle nicht automatisch besser. Lange, verrauschte Kontexte können Entscheidungen verschlechtern. Ein Agent, der dauernd alte Logs, redundante Tool-Ausgaben und überholte Zwischenstände mitschleppt, wirkt zwar informiert, aber er kann genau dadurch den Fokus verlieren.

Das ist der eigentliche Caveman-Punkt: Die teuersten Token sind oft auch die schlechtesten Token. Nicht immer. Aber oft genug, dass man sie als eigenes Engineering-Problem behandeln muss.

Für Entwickler fühlt sich das sehr vertraut an. Wir haben dasselbe Problem bei Logs, Monitoring, Tests und Dokumentation. Mehr Daten sind nicht automatisch mehr Signal. Ein gutes System reduziert Rauschen, ohne die Spur zur Quelle zu verlieren.

Caveman überträgt diese Denkweise auf Agenten.

Die Benchmark-Zahlen sind interessant, aber nicht magisch

Im README behauptet Caveman für den Proxy eine kontrollierte Benchmark-Reduktion von 33.2 Prozent bei provider-gemeldeten Input-Tokens in einer gepinnten Claude-Code-Suite.⁵ Die Benchmark-Doku beschreibt 18 gepaarte Läufe über sechs deterministische Tool-Output-Workloads. Caveman bestand alle exakten Antwort-Checks; ein HTML-Fall wurde sogar schlechter und bleibt sichtbar in der Auswertung.⁵

Das ist genau die Art von Zahl, die man ernst nehmen kann, ohne sie zu überhöhen.

Sie ist nicht "deine Kosten sinken immer um ein Drittel". Sie ist: In dieser Suite, mit diesen Fixtures, diesem Agenten, diesem Modell und dieser Messmethode sank der gemeldete Input bei gehaltener Antwortqualität. Das ist ein guter Beleg für Potenzial. Es ist kein Naturgesetz.

Noch interessanter ist fast, wie Caveman über Messung spricht. Die Produktseite unterscheidet zwischen lokalen Schätzungen, inferred savings, provider-gemeldeter Nutzung und verifizierten Einsparungen.⁶ Unknown models werden nicht heimlich als 0 Dollar gerechnet, sondern sichtbar als unpriced markiert.⁷ Das klingt trocken, ist aber zentral.

Wenn AI-Agenten produktiv werden, reicht "ungefähr billiger" nicht mehr. Man muss wissen, was gemessen wurde, auf welcher Grundlage, und ob Qualität dabei gehalten wurde.

Caveman Cloud: der heikle Teil

Der lokale Proxy ist relativ leicht zu mögen. Eigene Maschine, eigene Keys, lokale Recovery, kein Account nötig. Caveman Cloud ist ambitionierter: ein verwaltetes Gateway, das Provider-Nutzung, Katalogpreise, Cache-Hinweise, eval-gated Rollouts und später weitere Optimierungen wie semantisches Caching oder Routing zusammenbringen soll.⁷

Das kann wertvoll sein, weil Unternehmen nicht nur weniger Tokens wollen. Sie wollen wissen, welche Agenten welche Arbeit erledigen, welche Modelle wofür eingesetzt werden, wo Cache-Hits möglich sind, welche Prompts sich wiederholen und wo Kosten ohne Qualitätsverlust verschwinden können.

Aber genau dort liegt auch die Vertrauensfrage. Ein Gateway sitzt an einer empfindlichen Stelle. Caveman betont, dass Prompts und Antworten beim lokalen Setup direkt zum Provider gehen und Cloud-Telemetrie nur Token Counts, Modellnamen und Einsparungszahlen enthalten soll; Enterprise soll sogar Zero Data Retention bieten.¹⁶

Das ist die richtige Ansage. Ob es in Teams, Governance, Compliance und echten Produktionspipelines hält, muss sich im Betrieb zeigen. Bei Effizienz-Infrastruktur zählt am Ende nicht nur, wie gut sie komprimiert, sondern ob sie beweisbar nicht die falschen Dinge sieht, speichert oder verändert.

Caveman Browse zeigt die Richtung

Ein kleiner, aber sehr aufschlussreicher Baustein ist Caveman Browse. Es positioniert sich als token-effizientere Alternative zu Playwright MCP für Coding-Agenten. Statt riesige Browser-Snapshots in den Kontext zu kippen, liest es den echten Accessibility Tree, komprimiert ihn und hält die Originaldaten über den Recovery-Store abrufbar.⁸

Die Produktseite nennt 297 Token Tool-Katalog statt 3'422 für Playwright MCP und 4'507 für Chrome DevTools MCP, gemessen am 14. August 2026. Ein fokussierter Query auf einer 200-Zeilen-Seite soll ungefähr 98 Token statt eines kompletten ARIA-Dumps kosten.⁸

Auch hier ist der Punkt nicht nur Sparsamkeit. Browser-Automation für Agenten ist oft deshalb mühsam, weil der Agent zu viel Oberfläche auf einmal sieht. Gute Automatisierung braucht nicht das ganze DOM-Gewitter. Sie braucht die relevanten Interaktionspunkte, Zustände und Fehlermeldungen. Alles andere ist Lärm.

Was Caveman richtig verstanden hat

Caveman trifft einen Nerv, weil Agenten gerade an einer unbequemen Grenze stehen. Sie werden mächtiger, aber ihre Arbeitsweise ist verschwenderisch. Sie lesen zu viel, reden zu viel, wiederholen zu viel und messen zu wenig.

Der Markt reagiert darauf meistens mit grösseren Kontextfenstern und billigeren Tokens. Das hilft, löst aber nicht das Strukturproblem. Wenn ein System bei jeder Schleife unnötige Masse mitschleppt, macht ein grösseres Fenster die Verschwendung nur komfortabler.

Caveman sagt: Behandle Kontext als Ressource. Nicht nur als Platz im Prompt, sondern als Material, das sortiert, verdichtet, gemessen und bei Bedarf wieder exakt hergestellt werden muss.

Das ist eine starke These.

Der ehrliche Eindruck

Caveman ist kein Zauberstab. Der Skill kann netto verlieren. Kompression kann Details entfernen, die später wichtig werden. Benchmarks bleiben Workload-abhängig. Ein Cloud-Gateway muss Vertrauen verdienen. Und die Website selbst ist sehr selbstbewusst in Ton und Zahlensprache.

Aber genau deshalb ist Caveman interessant. Es ist ein frühes Werkzeug aus einer Welt, in der Agenten nicht mehr als Chatfenster verstanden werden, sondern als laufende Systeme mit Budget, Kontext, Telemetrie, Qualitätssicherung und Governance.

Wenn diese Welt kommt, wird Token-Effizienz nicht die langweilige Sparte am Rand sein. Sie wird Teil der Agenten-Architektur.

Der Caveman-Witz funktioniert, weil er primitiv klingt. Die eigentliche Idee ist das Gegenteil: Agenten brauchen weniger Höflichkeit, weniger Ballast und bessere Buchhaltung. Nicht weil kurze Antworten schöner sind, sondern weil gute Systeme wissen, was sie weglassen dürfen.

Quellen