Caveman 3.0 für Claude Code: Lokale Input-Kompression, Recovery und Benchmarks

Geprüft am 2. Oktober 2026. Produktbaseline: Caveman 3.0.0, Runtime bin-v2.0.0, SDK 1.2.0 und Middleware 1.0.0. Das ist eine Quellen- und Benchmark-Methodenprüfung, kein Wavect-Produktionsbenchmark. Caveman-3.0.0-Release

Caveman 3.0 ist aus einem anderen Grund interessant als wegen des Memes, das das Projekt bekannt gemacht hat. Die ursprüngliche Idee war simpel: Ein Coding-Agent soll mit weniger Wörtern antworten. Die neuere Architektur adressiert die teurere Seite langer Agent-Sessions, nämlich das, was das Modell immer wieder liest. Ein lokaler Proxy kann große Tool-Ergebnisse vor dem nächsten Modellaufruf komprimieren und gleichzeitig die exakten Originaldaten für Recovery behalten. Caveman-3.0-README

Damit gehört dieser Artikel zu einer engeren Suchintention als unser allgemeiner Guide zur Token-Optimierung bei Coding-Agents, der Caching, Routing und Context-Reduktion als Gesamtstack behandelt. Er ist auch enger als unser Guide zu Tool-Output-Kompression, der die Kategorie erklärt. Hier geht es gezielt um Caveman 3.0, Claude-Code-Input-Kompression, Recovery, lokalen Betrieb und die Evidenz hinter den veröffentlichten Aussagen.

Was hat sich mit Caveman 3.0 geändert?

Caveman 3.0.0 wurde am 30. September 2026 veröffentlicht. Das Release verbindet mehrere zuvor getrennte Produktentscheidungen zu einer klareren Deployment-Story. Release Notes.

Bei der Lizenzänderung lohnt sich Präzision. Vor 3.0.0 standen Teile des Repositorys unter MIT, während Engine-nahe Runtime-Komponenten BSL-1.1 nutzten. Ab 3.0.0 steht das Repository unter Apache-2.0, ohne Hosted-Service-Restriction oder Change Date für diesen Code. Ältere Releases behalten die Lizenzbedingungen, mit denen sie veröffentlicht wurden. Caveman Cloud ist ein separates Hosted-Produkt und nicht von der Repository-Lizenz umfasst. Caveman Licensing Notes

Bei Agent-Sessions ist oft das wiederholte Lesen teurer als die finale Antwort

Ein Coding-Agent bezahlt nicht nur für seine Schlussantwort. Lange Sessions tragen Instruktionen, vorige Nachrichten und Tool-Ergebnisse immer wieder in spätere Requests. Wenn ein Testbefehl einmal 80 KB Output erzeugt, kann dieser Output mehrere spätere Requests belasten, sofern das Framework ihn in der Conversation-History mitführt. Dasselbe gilt für JSON-Payloads, YAML-Konfigurationen, Diffs und Suchergebnisse.

Caveman trennt zwei Konzepte, die leicht miteinander verwechselt werden:

• Der Response-Skill fordert den Agent auf, knapper zu schreiben. Er reduziert Output-Verbosity.
• Proxy und Middleware transformieren geeigneten Kontext vor der Inferenz. Sie reduzieren Input-Volumen.

Der zweite Punkt ist architektonisch interessanter. Das Modell braucht für die Diagnose eines einzelnen Stacktraces nicht jede INFO-Zeile aus einem Log. Blindes Abschneiden wäre aber riskant, weil genau die entfernte Zeile die Antwort enthalten könnte. Cavemans Design ist deshalb komprimieren plus wiederherstellen, nicht einfach verwerfen. Projektarchitektur.

Wie der lokale Caveman-Proxy funktioniert

Der grobe Datenpfad ist einfach:

Claude Code / Codex / anderer Agent
        |
        | Request + Tool-Ergebnisse
        v
lokaler Caveman-Proxy
        |-- geeigneten Inhalt erkennen
        |-- verrauschte Blöcke durch kürzere Repräsentationen ersetzen
        |-- exakte Originale lokal speichern
        |-- Recovery-Handles bereitstellen
        v
vom Agent gewählter Modell-Provider

Der Proxy leitet die Inferenz weiterhin an den Provider weiter, den der Agent bereits verwendet. Caveman lokal zu betreiben bedeutet daher nicht, dass Claude, GPT oder ein anderes Hosted Model dadurch lokal wird. Ihr kontrolliert die Transformations- und Recovery-Schicht. Wenn das Upstream-Modell eine Cloud-API bleibt, erhält der Provider weiterhin den resultierenden Modell-Request. Cavemans Security-Dokumentation trennt diese Datenflüsse ausdrücklich. Security- und Privacy-Modell

Für Teams mit eigenen Agents wendet Middleware 1.0 dieselbe Idee an, ohne das Framework zu ersetzen. Der Adapter kopiert einen Outbound-Request, projiziert geeigneten Tool-Result-Text in die komprimierte Kopie und lässt die ursprüngliche Conversation-History der Anwendung unverändert. Kompression wird nur auf Integrationspfaden aktiviert, die ein echtes Recovery-Tool registrieren können. Falls Recovery nicht gebunden werden kann, soll der dokumentierte Pfad den Inhalt unverändert durchreichen, statt ihn verlustbehaftet zu kürzen. TypeScript Middleware 1.0 Python Middleware 1.0

Was der 33,2%-Claude-Code-Benchmark tatsächlich zeigt

Die stärkste öffentliche Evidenz im Repository ist nicht die Aussage, dass jeder einzelne Block um 98 oder 99 Prozent schrumpft. Es ist ein gepaarter Benchmark auf Agent-Ebene, der provider-gemessene Input-Tokens erfasst, nachdem sich das gesamte Session-Verhalten abgespielt hat. CaveBench Wrap Benchmark

Über alle 18 Direct-vs-Caveman-Paare summiert der Report 885.793 direkte Input-Tokens gegenüber 591.673 mit Caveman, also 33,2 Prozent weniger. Alle 18 exakten Antwortchecks bestanden. Das gemeldete case-clustered 95%-Intervall liegt zwischen 14,6 und 48,5 Prozent. Die negative HTML-Zeile bleibt im Gesamtwert enthalten, weil dort keine nützliche Kompression griff, während Caveman trotzdem Overhead verursachte. Benchmark-Report und Methode.

Diese rote Zeile ist wichtig. Sie zeigt, warum eine Kompressionsrate für einen einzelnen Payload nicht mit Einsparungen über eine gesamte Session gleichgesetzt werden darf. Ist ein Workload bereits kompakt, nicht unterstützt oder von anderem Kontext dominiert, kann eine zusätzliche Schicht sogar mehr Tokens kosten.

Es gibt außerdem eine Evidenzgrenze. Das Repository veröffentlicht Benchmark-Tabelle, Methode und Provenance-Hashes, weist aber ausdrücklich darauf hin, dass Raw Harness und Run-Artefakte nicht enthalten sind. Der Benchmark ist daher als gepinnter Projektbericht zu behandeln, nicht als vollständig aus dem öffentlichen Checkout reproduzierbarer Benchmark. Reproduction Availability.

Die Launch-Kommunikation enthält zusätzlich sehr starke Einzelbeispiele für Log-, CSV-, YAML- und Test-Output-Kompression. Solche Blockwerte sind für einen Smoke Test interessant, aber wir würden aus ihnen keine Kostenprognose ableiten. Der öffentlich dokumentierte Agent-Level-Benchmark ist die stärkere Basis für eine Planungsentscheidung.

Warum 98% weniger Tool-Output nicht 98% weniger AI-Kosten bedeutet

Ein einzelnes Tool-Ergebnis ist nur ein Teil des Requests. System-Prompt, Repository-Instruktionen, History, weitere Tool-Ergebnisse und Cache-Verhalten bleiben bestehen. Außerdem kann der Agent Recovery aufrufen, wenn die komprimierte Darstellung nicht ausreicht. Deshalb sollte ein Pilot mindestens folgende Größen getrennt messen:

• provider-gemessene Input-Tokens pro kompletter Aufgabe,
• Cache-Read- und Cache-Write-Tokens,
• Output-Tokens,
• Recovery-Aufrufe und nachgeladene Bytes,
• Retries und zusätzliche LLM-Calls,
• akzeptierte Task-Qualität.

Das richtige Ziel ist nicht die maximal beeindruckende Kompressionszahl, sondern niedrigere Kosten pro akzeptierter Aufgabe.

caveman learn: Erst messen, wo die Tokens hingehen

caveman learn analysiert lokale Session-History und Setup-Dateien, um wiederkehrende Token-Senken zu finden. Die Dokumentation nennt unter anderem immer geladene Instruktionen, ungenutzte Skills, wiederholten Text, Context-Tiefe und Memory-Probleme. Die Analyse läuft lokal und die resultierenden Zahlen werden ausdrücklich als inferred, also geschätzt, gekennzeichnet. caveman learn Dokumentation

Das ist relevant, weil der günstigste Kontext oft der Kontext ist, den ihr gar nicht erst laden müsst. Eine 400-Zeilen-CLAUDE.md, Skill-Beschreibungen, die nie verwendet werden, oder dieselbe Procedure in jeder Session können ein strukturell größeres Problem sein als ein einzelner lauter Testlauf. Learn kann diese Muster sichtbar machen, bevor ihr noch einen Optimizer in den Stack einbaut.

caveman learn --plain --since 7d --sources claude,codex
caveman learn --all
caveman learn implement

Version 3.0 ergänzt außerdem einen Autopilot, der nach Sessions im Hintergrund neu scannen kann, höchstens einmal alle sechs Stunden. Laut Release Notes benötigen vorgeschlagene Änderungen weiterhin Zustimmung, werden nachgemessen und zurückgenommen, wenn sie Nachrichten nicht kleiner machen. Der Background-Refresh lässt sich mit caveman learn autopilot off deaktivieren. 3.0 Release Notes.

Lokal bedeutet nicht, dass Data-Policy-Arbeit entfällt

Der lokale Modus entfernt einen Caveman-Drittdienst aus dem Inference-Pfad. Trotzdem sollten drei getrennte Datenräume geprüft werden.

1. Der Modell-Provider erhält weiterhin den Modell-Request

Wenn Claude Code weiterhin Anthropic nutzt, geht der komprimierte Request an Anthropic. Wenn eure Anwendung OpenAI nutzt, geht er weiterhin an OpenAI. Caveman ändert die Rolle des Providers nicht, nur weil die Kompression vorher lokal stattfindet. Für vollständig lokale Inferenz braucht ihr zusätzlich einen lokalen oder selbst betriebenen Modell-Endpunkt.

2. Recovery-Originale sind sensible lokale Daten

Die Runtime speichert exakte Tool-Result-Originale, damit der Agent sie wieder abrufen kann. Ab bin-v2.0.0 gehören Middleware-Originale zu ihrem Scope, Retention kann diese Originale einbeziehen und das Löschen einer Session kann die gespeicherten Originale ebenfalls löschen. Verschlüsselung at rest ist verfügbar, wenn ein Encryption Key konfiguriert wird. Ohne Key verlässt sich der Store auf Dateisystemschutz. Die Security-Dokumentation weist ausdrücklich darauf hin, dass der Lifecycle vor bin-v2.0.0 schwächer war. Pinnt daher die Runtime, wenn Retention-Anforderungen relevant sind. Runtime Storage Lifecycle.

3. CLI-Telemetrie ist standardmäßig aktiviert

Der Standalone-Skill sendet für sich nichts. CLI und Agent Hooks von 3.0 verwenden jedoch Opt-out-Telemetrie. Release und Security-Dokumentation nennen unter anderem eine zufällige Install-ID, Token-Aggregate und die Sender-IP. Prompts, Code, Dateipfade, Tool-Argumente und Tool-Ergebnisse sollen nicht enthalten sein. Das Projekt bezeichnet diese Telemetrie richtigerweise als pseudonym statt anonym. CI sendet standardmäßig nicht. Telemetry Details.

caveman telemetry status
caveman telemetry off
# oder
export DO_NOT_TRACK=1

Für einen Enterprise-Pilot sollte diese Entscheidung vor dem ersten produktionsnahen Lauf getroffen werden, nicht erst nachträglich.

Ein sinnvoller Caveman-3.0-Pilot für Claude Code

Aktiviert Kompression nicht sofort für alle Entwickler. Baut einen gepaarten Test, in dem ein Qualitätsverlust sichtbar und messbar wäre.

Schritt 1. Version pinnen und prüfen, was tatsächlich läuft

npm install -g @caveman-ai/[email protected]
caveman setup
caveman telemetry off   # falls das zu eurer Policy passt

Das 3.0-Release ordnet CLI 2.0.0 der Runtime bin-v2.0.0 zu. Version-Pinning ist wichtig, weil Retention-Verhalten, Middleware-Verträge und Adapter sich ändern können. Versionsmatrix.

Schritt 2. Zuerst die eigenen Token-Senken messen

caveman learn --plain --since 7d

Wenn der größte Waste aus immer geladenen Instruktionen kommt, behebt dieses Problem zuerst. Sonst könnte Proxy-Kompression fälschlicherweise als Lösung für alles erscheinen.

Schritt 3. Aufgaben mit exakten Acceptance Criteria auswählen

Geeignete Pilotaufgaben sind zum Beispiel: eine FATAL-Zeile in einem großen Log finden, einen konkreten JSON-Config-Drift identifizieren, den fehlschlagenden Test isolieren oder einen bestimmten CSV-Outlier extrahieren. Jede Aufgabe sollte einen Oracle haben, den ein separates Skript verifizieren kann. Bewertet Qualität nicht nur danach, ob eine Antwort plausibel klingt.

Schritt 4. Direkten und komprimierten Arm ausführen

Modell, Agent-Version, Test-Fixtures, Tool-Rechte und Startzustand des Repositorys müssen gleich bleiben. Messt provider-gemessene Input-Tokens, Cache Reads, Cache Writes, Output-Tokens, Latenz, Retries und Recovery-Aufrufe. Rotiert die Reihenfolge der Läufe, damit Warm-Cache- und Zeiteffekte weniger verzerren.

Schritt 5. Rollout nach Economics pro akzeptierter Aufgabe gaten

Caveman Middleware 1.0 im eigenen Agent verwenden

Bei Custom Agents ist die wichtigste Designfrage, ob die Framework-Integration Recovery binden kann. Die TypeScript-Middleware dokumentiert zertifizierte Kompressionspfade für Vercel AI SDK, OpenAI, Anthropic und LangChain. Weitere Adapter sind als experimentell markiert. Python dokumentiert zertifizierte Pfade für LangChain, OpenAI, Anthropic und LiteLLM. Nicht unterstützte Versionen und Runtime-Fehler verhalten sich standardmäßig fail-open. Der Original-Request läuft dann unverändert weiter und ein Grund wird geloggt. TypeScript Compatibility Contract Python Compatibility Contract.

Ein guter Rollout verwendet drei Modi:

• record, um die Integration zu validieren, ohne den Modell-Input zu verändern.
• compress für den Treatment-Arm.
• off als expliziten Rollback-Pfad.

Die offiziellen Quickstarts sind besonders nützlich, weil ihre Standard-Demos keinen Provider-Request senden. Sie testen zuerst die echte lokale Runtime, Kompression und exakte paginierte Recovery. Bezahlte Provider-Inferenz bleibt ein optionaler separater Schritt. Das ist die richtige Reihenfolge für einen Infrastruktur-Pilot.

Bedeutet Apache-2.0, dass ihr eure AI jetzt „besitzt“?

Teams bekommen damit deutlich mehr Kontrolle über diese Schicht. Ihr könnt Caveman 3.0s öffentliche Runtime inspizieren, forken, verändern und einbetten, ohne die frühere BSL-Service-Restriction. Für interne Plattformen und Teams, die keinen proprietären Optimizer in jedem Agent-Request haben möchten, ist das relevant. Lizenzumfang.

Ownership hat aber mehrere Ebenen. Ihr könnt den Kompressionsproxy besitzen und das Modell trotzdem mieten. Ihr könnt das Modell selbst hosten und weiterhin von proprietären Developer Tools abhängen. Ihr könnt beides besitzen und Telemetrie oder Browserdaten trotzdem über externe Services routen. Die nützlichere Frage lautet: Welche Teile von Inferenz, Kontext, Memory, Tooling und Observability können wir selbst inspizieren, ersetzen und betreiben?

Caveman 3.0 verbessert diese Antwort für die Context-Efficiency-Schicht. Den Rest löst es nicht automatisch.

Wann sich ein Caveman-Test lohnt und wann nicht

Für den breiteren Ablauf startet unser Token-Usage-Playbook mit Cacheability und Routing vor Kompression. Für einen breiteren Vergleich der Kategorie nutzt unseren Guide zu Tool-Output-Kompression. Für modellgesteuerten Kontext statt Proxy-Kompression siehe Context Language Models versus Compaction.

FAQ

Ist Caveman 3.0 vollständig Open Source?

Das öffentliche Repository steht ab Version 3.0.0 unter Apache-2.0, einschließlich Engine, Proxy, CLI, SDKs und Middleware. Ältere Releases behalten ihre ursprünglichen Lizenzen. Caveman Cloud ist separate kommerzielle Software und nicht von der Repository-Lizenz umfasst. Lizenzdetails.

Reduziert Caveman Claude-Code-Input-Tokens?

Im veröffentlichten Benchmark mit sechs Workloads verwendete der gewrappte Claude-Code-Arm aggregiert 33,2 Prozent weniger provider-gemessene Input-Tokens als direkter Claude Code und bestand 18/18 exakte Antwortchecks. Das Ergebnis gilt für diesen Workload und die Raw-Run-Artefakte sind nicht öffentlich. Es sollte daher als kontrolliertes, vom Projekt veröffentlichtes Ergebnis verstanden werden, nicht als universelle Einspargarantie. Benchmark.

Sendet Caveman meinen Code an Caveman-Server?

Lokaler Proxy und Framework-Middleware benötigen keinen Caveman-Account und senden Prompt- oder Tool-Result-Inhalte nicht an Caveman-Server. Der gewählte Modell-Provider erhält den Inference-Request weiterhin. Die CLI hat separate Opt-out-Telemetrie mit Nutzungsmetadaten und IP-Adresse, jedoch laut Dokumentation ohne Prompts, Code oder Dateipfade. Security-Modell.

Kann der Agent wegkomprimierte Inhalte wieder abrufen?

Ja. Unterstützte Kompressionspfade speichern exakte Originale und binden einen Recovery-Mechanismus. Middleware-Pfade, die Recovery nicht binden können, sollen den Inhalt unverändert durchreichen, statt ihn zu komprimieren. Recovery-Handles sind gescoped und können gemäß Runtime-Retention ablaufen. Middleware-Recovery-Vertrag.

Ist caveman learn lokal?

Die Learn-Analyse liest lokale Session-History und Dateien und dokumentiert, dass dabei nichts gesendet wird. Die Reports enthalten lokale Schätzwerte. Davon getrennt existiert die CLI-Telemetrie, die sich mit caveman telemetry off oder DO_NOT_TRACK=1 abschalten lässt. Learn-Dokumentation Telemetry-Dokumentation.

Ist Caveman dasselbe wie Prompt Caching?

Nein. Prompt Caching verwendet Provider-seitig bereits berechnete Zustände für wiederholte Präfixe. Caveman verändert geeigneten Kontext, bevor der Request gesendet wird. Beides kann sich ergänzen, aber Kompression kann auch Cache-Verhalten verändern. Deshalb sollten Cache-Read- und Cache-Write-Counter im selben Pilot gemessen werden.

Unterstützt Caveman Middleware LiteLLM?

Die Python-Middleware-1.0-Dokumentation führt LiteLLM als zertifizierte Adapterfamilie für unterstützte Async- und Proxy-Pfade auf. Es gelten explizite Recovery-Anforderungen und bei bestimmten Sync-Routen Provider-Limits. Pinnt die getesteten Paketversionen und führt die Compatibility-Checks vor Produktion aus. Python-Middleware-Matrix.

Quellen und Verifikationshinweise

• Caveman 3.0.0 Release Notes, Versionen, Apache-2.0-Umstellung, Learn Autopilot und Middleware 1.0.
• LICENSING.md bei v3.0.0, Repository- und Cloud-Lizenzgrenzen.
• CaveBench Wrap Benchmark, Provider-Input-Totals, exakte Antwortchecks, Konfidenzintervall, negativer HTML-Fall und Reproduktionsgrenzen.
• SECURITY.md bei v3.0.0, Datenflüsse, lokaler Recovery-Store und Telemetrie.
• caveman learn Dokumentation, lokale Inputs, Outputs, Commands und Evidenzlabels.
• TypeScript Middleware 1.0 README, Recovery- und Fail-open-Verhalten.
• Python Middleware 1.0 README, zertifizierte Adapter einschließlich LiteLLM und Recovery-Anforderungen.
• Caveman 3.0 README, Produktarchitektur und Installation.