KI-News · Werkzeuge
RTK oder Headroom:
Eingabe-Kompression im Vergleich.
EN Read in English
Beide Werkzeuge setzen an derselben Stelle an: bevor eine Werkzeugausgabe, ein Log oder eine Datei das Modell erreicht. RTK ist ein in Rust geschriebener Shell-Hook, den ich seit Monaten produktiv einsetze. Headroom ist ein größerer, ML-gestützter Proxy von einem ehemaligen Netflix-Ingenieur. Ich habe beide installiert und mit echten Zahlen verglichen.
audit-reads benutzt, der ohne laufenden Proxy auskommt und
reale Claude-Code-Transkripte auswertet. Beide Datensätze sind also echt gemessen, nur an
unterschiedlichen Stellen der jeweiligen Werkzeuge.
Was beide Werkzeuge tun
| RTK | Headroom | |
|---|---|---|
| Form | Shell-Hook (Rust), rewritet Kommandos transparent | Library, lokaler Proxy oder MCP-Server (Python) |
| Ansatz | Regelbasierte Kürzung pro Kommando (Bash, Grep, Read, Git …) | ML-gestützte Kompression: Embeddings, semantisches Caching, Kompressoren pro Inhaltstyp |
| Betrieb | leichtgewichtig, kein eigenes Modell | eigener Dienst mit ONNX-Embedder, optional Code-Graph-Indexierung |
| Herkunft | separates Tool, im Einsatz seit Monaten | Open Source, ehemaliger Netflix-Ingenieur |
| Beworbene Ersparnis | 60–90 % je nach Kommando | 60–95 % bei JSON, rund 20 % bei Coding-Agenten allgemein |
RTK: die echten Produktionszahlen
Transparente Kürzung pro Kommando
Rust-CLI-Proxy · wird per Hook transparent vor Bash-Kommandos geschaltet
RTK ersetzt Kommandos wie git status oder npm test automatisch
durch eine gefilterte Variante, ohne dass ich das im Alltag bewusst aufrufe. Die
Gesamtbilanz über alle Projekte, zum Zeitpunkt dieses Beitrags:
| Kennzahl | Wert |
|---|---|
| Kommandos gesamt | 7.253 |
| Eingespart | 1,1 Mio. Tokens (38,3 %) |
rtk read | 809 Aufrufe, Ø 9,9 % gespart |
rtk grep | 1.154 Aufrufe, Ø 17,5 % gespart |
rtk vitest run | 13 Aufrufe, Ø 94,0 % gespart |
rtk git diff HEAD~3 HEAD | 1 Aufruf, 90,6 % gespart |
Ein konkretes Beispiel aus der Praxis: ein ausführlicher Testlauf im PlantWiz-Backend
(vitest run --reporter=verbose, 205 Tests in 27 Dateien, jeder mit eigener
Ergebniszeile) erzeugte 25.259 Zeichen Rohausgabe. RTK kürzte automatisch auf rund 2.000
Zeichen, mit einem Verweis auf die vollständige Logdatei für den Fall, dass die Details doch
gebraucht werden:
Ein realer Testlauf, automatisch gekürzt
PlantWiz-Backend, ohne dass danach gefragt wurde.
Headroom: audit-reads als sicherer Einstieg
Kompressionsschicht mit eigenem Modell
PyPI-Paket headroom-ai, Version 0.37.0 · CLI mit über 30 Unterbefehlen
Headroom ist deutlich mehr als ein Kompressor: headroom --help listet Befehle
für Memory-Management, Kosten-Budgets, semantisches Caching, Code-Graph-Indexierung und
einen Lernmodus, der aus vergangenem Traffic Muster extrahiert. Die eigentliche Kompression
läuft über headroom proxy, einen Dienst, der sich zwischen Client und
Anthropic- oder OpenAI-API schaltet (ANTHROPIC_BASE_URL=http://localhost:8787
claude). Für einen unabhängigen Zahlenvergleich auf Kommandoebene, wie bei RTK oben,
bräuchte es diesen Dienst im Dauerbetrieb, das war für diesen Beitrag nicht der Rahmen.
Headroom bringt aber einen zweiten, leichtgewichtigen Befehl mit, der ohne laufenden Proxy
auskommt: headroom audit-reads liest ausschließlich lokale Claude-Code-Transkripte
und schätzt, wie viele Bytes pro Werkzeug anfallen und wie viel davon adressierbar wäre. Ein
eigenes PlantWiz-Transkriptverzeichnis existiert nicht, weil ich dort über ein zusätzliches
Arbeitsverzeichnis arbeite statt über eine eigene Sitzung, der Befehl hat deshalb alle 216
lokal gespeicherten Sitzungen projektübergreifend ausgewertet:
| Werkzeug | Anteil an Tool-Bytes |
|---|---|
| Bash | 45,5 % (5,5 MB, ca. 1.372K Tokens) |
| Read | 20,1 % (2,4 MB, ca. 607K Tokens) |
| WebSearch | 13,6 % (1,6 MB, ca. 409K Tokens) |
| Browser-Automation | 7,7 % (929 KB, ca. 232K Tokens) |
| WebFetch | 3,9 % (465 KB, ca. 116K Tokens) |
Bash-Ausgaben sind mit 45,5 % klar der größte Brocken, genau die Kommandos, die RTK bereits
abfängt. Bei den Read-Aufrufen fand audit-reads eine Lücke, die RTK
nicht schließt: 44,9 % der gelesenen Bytes stammen aus stale reads, Dateien, die
gelesen und danach bearbeitet wurden, deren alte Version aber weiter im Kontext steht. RTK
kürzt einzelne Kommandoausgaben, verfolgt aber nicht, ob eine frühere Datei durch eine spätere
Bearbeitung veraltet ist.
Direkter Vergleich
| RTK | Headroom | |
|---|---|---|
| Betriebsaufwand | leichtgewichtiger Hook, kein eigenes Modell | voller Proxy mit ONNX-Embeddings, eigener Dienst |
| Messgrundlage | echter Produktionsbetrieb, 7.253 Kommandos | eigener Analysebefehl auf 216 Sitzungen, ohne Live-Proxy |
| Größte gemessene Ersparnis | −94,0 % bei Testläufen | keine eigene Kompressionsrate gemessen, nur Verteilung |
| Bekannte Lücke | keine Read-Lifecycle-Verfolgung | Live-Betrieb aufwendiger als ein Shell-Hook |
| Reichweite | alles, was über die Shell läuft | zusätzlich Library/MCP-Modus für Nicht-Shell-Pfade, z. B. API-Antworten direkt im Code |
Wann welches Werkzeug
Noch kein Kompressions-Hook im Einsatz
RTK oder ein vergleichbarer, leichtgewichtiger Shell-Hook lohnt sich zuerst, weil er genau die größte Kostenstelle trifft: Bash-Ausgaben, ohne zusätzlichen Betriebsaufwand.
Ein Shell-Hook läuft bereits
Headrooms Read-Lifecycle-Funktion (veraltete Reads erkennen) ist die konkrete Lücke, die ein reiner Kommando-Hook nicht schließt. Vor der Installation des vollen Proxys lohnt die Frage, ob diese eine Funktion den Betriebsaufwand rechtfertigt.
Kontexte außerhalb der Shell
API-Antworten, die direkt im eigenen Code verarbeitet werden, etwa JSON von einer externen Schnittstelle, erreicht ein Shell-Hook nicht. Dafür wäre Headroom als Library der naheliegendere Ansatz, RTK bleibt dort ungenutzt.
Welche Werkzeuge für Ihr Team wirklich nötig sind?
Ich prüfe Token-Werkzeuge und Claude-Code-Konfigurationen an echtem Projektcode, bevor ein Team dafür bezahlt. 30 Minuten Erstgespräch, kostenlos.