99 % gespart und trotzdem nichts gemerkt - zwei Monate RTK

RTK - Rust Token Killer - bin ich über einen AI-Newsletter gestolpert, und bei den aktuellen Tokenkosten war die Neugier schnell größer als die Skepsis. Installiert, und dann zwei Monate lang verfolgt, was das Ding eigentlich tut: auf einem Linux-Rechner mit Claude Code, in meinen persönlichen Projekten. Alle Zahlen in diesem Artikel stammen aus diesem Setup. Am Ende steht ein Ergebnis, das ich so nicht erwartet hatte - aber nicht in die Richtung, die man vermuten würde.

Der Ausgangspunkt ist simpel: Wenn ein Coding-Agent den halben Tag im Terminal steht, zahlt man für jede Zeile Boilerplate mit. Für jedes git status mit elf Zeilen Porcelain-Output, für jeden Testlauf, bei dem 200 grüne Zeilen durchrauschen und genau eine rote interessant ist. Der Gedanke, da einen Filter dazwischenzuhängen, klingt erstmal offensichtlich richtig.

Was RTK eigentlich macht

Der Name ist ziemlich wörtlich gemeint. RTK ist ein CLI-Proxy: ein einzelnes Rust-Binary ohne Runtime-Abhängigkeiten, das sich zwischen dein Kommando und den Agent schiebt. Aus git status wird rtk git status. RTK führt das echte Kommando aus, komprimiert die Ausgabe und reicht nur noch das Verdichtete an den Agent weiter.

Das Charmante daran: Man muss nichts anders machen. Ein PreToolUse-Hook schreibt die Kommandos automatisch um, der Agent merkt davon nichts. Kein Account, keine API-Keys, keine Telemetrie, Apache 2.0 - der Code liegt auf github.com/rtk-ai/rtk.

Beworben wird das Ganze mit 60-90 % Tokenersparnis. Behalt die Zahl im Kopf, wir kommen darauf zurück.

Installation unter Linux

Der unspektakulärste Teil des Artikels, und das ist ein Kompliment. Binary geholt, in den PATH gelegt, fertig:

rtk --version

Bei mir läuft aktuell 0.37.2. Dann die Claude-Code-Integration:

rtk init --global

Das schreibt den Hook in die Claude-Code-Konfiguration. Claude Code einmal neu starten, und ab da läuft es. Keine Config, die man verstehen muss, kein Nachjustieren, nichts. Genau so soll ein Tool sein, das im Hintergrund arbeiten will.

Ab da lief RTK bei jedem Kommando mit - und ich hab die Statistik über die Wochen immer wieder angeschaut.

Dieselbe Einrichtung nutze ich auch auf meinem Windows-Rechner mit Claude Code: gleiches Binary, gleicher Befehl, gleiches Vorgehen. Die Zahlen weiter unten stammen aber ausschließlich vom Linux-System.

Die Zahlen nach zwei Monaten

768 Kommandos, 10,5 Millionen Input-Tokens, 10,4 Millionen gespart. 99,0 %. Der Efficiency-Balken leuchtet grün, und für ungefähr drei Sekunden fühlt man sich großartig.

Dann schaut man auf die Tagesaufstellung, und das Bild kippt.

Die 99 % sind ein einziger Tag. Am 15. Juni: 116 Kommandos, 9,9 Millionen Input-Tokens, 99,8 % gespart. Dieser eine Tag macht rund 95 % meiner gesamten Ersparnis aus. Alles andere - 14 weitere Tage, 652 Kommandos - kommt zusammen auf etwa 552.000 Input-Tokens und 460.000 gespart. Das sind 83 %.

Wohlgemerkt: 83 % sind ein guter Wert und liegen sauber im beworbenen Bereich. Es ist nur eben nicht dasselbe wie 99 %.

Die Streuung ist gewaltig. Meine Tageswerte gehen von 10,1 % über 22,1 % bis 98,4 %. Es gibt keinen typischen Tag. Es gibt Tage, an denen RTK ordentlich was rausholt, und Tage, an denen es praktisch nichts tut.

Und was ich am spannendsten finde: Die Kommandos, die ich am häufigsten laufen lasse, sind die, bei denen am wenigsten zu holen ist. rtk read steht mit 94 Aufrufen mit Abstand auf Platz eins der Nutzung - und spart im Schnitt 4,5 %. Bei rtk grep sind es über 53 Aufrufe im Mittel 7,7 %. Gespart wird bei den Ausreißern: ESLint mit 99,6 %, curl-Responses mit 99,4 %, Vitest mit 79 %.

Der Alltag bringt also wenig. Die Spitzen bringen alles.

Der 15. Juni

Was an diesem Tag konkret passiert ist, weiß ich beim besten Willen nicht mehr. Die Zahl ist mir aufgefallen, im Kalender steht aber nichts Besonderes, und rekonstruieren lässt sich der Arbeitstag im Nachhinein nicht mehr.

Was ich aus den Daten rekonstruieren kann: rtk grep steht mit 9,9 Millionen gesparten Tokens auf Platz eins der Kommando-Tabelle - bei einer Durchschnittsersparnis von 7,7 %. Das geht nur, wenn ein einzelner grep so absurd viel Output produziert hat, dass er alles andere in den Schatten stellt. Vermutlich über ein Verzeichnis, das ich hätte ausschließen sollen. node_modules, target, irgendwas in der Größenordnung.

Und genau das ist der Punkt, an dem ich RTK anders bewerte als vorher. Diese 9,9 Millionen Tokens hätten mein Kontextfenster nicht nur teuer gemacht - sie hätten die Session zerlegt. Kontext voll, Session vorbei, im Zweifel mitten in etwas Wichtigem.

RTK spart mir also nicht jeden Tag 80 %. Es fängt den einen Tag ab, an dem ein einzelnes Kommando alles gesprengt hätte. Das ist ein anderer Nutzen als der beworbene - aber nicht der kleinere.

Was die Zahlen nicht sagen

Hier muss man ehrlich sein: rtk gain misst, wie stark RTK den Terminal-Output komprimiert hat, den es angefasst hat. Das ist nicht dasselbe wie „meine Session kostet jetzt 99 % weniger“.

JetBrains hat im Juli einen gepaarten A/B-Benchmark mit Claude Code gefahren und kam auf ein ernüchterndes Ergebnis: bei niedrigem Reasoning-Effort war der Lauf mit RTK 7,6 % teurer, bei hohem Effort lag der Unterschied bei null. Die Qualität der Ergebnisse blieb in beiden Fällen unverändert.

Ein Widerspruch ist das nicht. Beide Zahlen können gleichzeitig stimmen. RTK komprimiert nachweislich stark - aber ob die Session dadurch billiger wird, hängt daran, welchen Anteil Terminal-Output überhaupt am Gesamtverbrauch hat und ob der Agent wegen der gekürzten Ausgabe nochmal nachfassen muss. Wenn er zweimal fragen muss, weil ihm die Information fehlt, ist der Vorteil weg.

Mein eigener Eindruck deckt sich damit: Im Alltag ist mir nichts aufgefallen. Keine spürbar längeren Sessions, kein Aha-Moment - und das, obwohl ich durchaus darauf geachtet habe. Was passiert, sieht man nur in der Statistik. Für ein Hintergrund-Tool ist das vielleicht sogar das beste Zeugnis, das man ausstellen kann - aber man sollte keine Wunder erwarten.

Die andere Baustelle: VS Code mit GitHub Copilot

Zweiter Strang, und der steht ausdrücklich noch im Experimentierstatus: RTK unter Windows mit VS Code und GitHub Copilot. Von diesem Setup stammt keine einzige der Zahlen oben - hier geht es bisher nur darum, ob ich es überhaupt zuverlässig ans Laufen bekomme.

Die Installation ist ebenfalls unkompliziert - Binary nach C:\Tools\RTK, Ordner in den User-PATH, neue PowerShell auf. Die Copilot-Integration läuft dann über einen eigenen Schalter:

rtk init --copilot --global --dry-run
rtk init --copilot --global

Der Dry-Run ist eine gute Idee und zeigt vorab, welche Dateien angelegt würden - bei mir ausschließlich unter %USERPROFILE%\.copilot. Danach VS Code komplett schließen und neu starten, sonst lädt Copilot die Konfiguration nicht.

Soweit die Theorie. In der Praxis war das der deutlich holprigere Teil. Die Integration in Claude Code war Welten einfacher, und gefühlt tut RTK dort auch mehr. Mit Copilot hatte ich dagegen Fälle, in denen RTK offenbar Requests an Copilot oder deren Responses blockiert hat - der Ablauf lief einfach nicht durch. Was genau da schiefgeht, hab ich noch nicht bis zum Ende auseinanderdividiert.

Interessant ist dabei: Claude Code läuft auf demselben Windows-Rechner ohne Auffälligkeiten. „Windows ist halt Windows“ greift als Erklärung also zu kurz - der Unterschied liegt eher bei der Copilot-Integration als beim Betriebssystem.

Unter Linux mit Claude Code läuft RTK seit zwei Monaten unauffällig. Mit Copilot steht es weiterhin auf der Werkbank.

Fazit

RTK ist ein gut gebautes Tool, das ein reales Problem angeht - nur nicht ganz das Problem, das im Marketing steht. Wer erwartet, dass die Rechnung ab morgen 80 % kleiner ist, wird enttäuscht. Wer es als Sicherheitsnetz gegen Output-Explosionen versteht, bekommt genau das.

Mit Claude Code bleibt es installiert - auf beiden Rechnern. Die Einrichtung kostet zwei Minuten, im Alltag stört es nicht, und der eine 15.-Juni-Moment rechtfertigt es für mich allein.

Mit GitHub Copilot ist es weiterhin ein Experiment. Installiert bleibt es, ich schraube noch daran - aber eine Empfehlung ist das in diesem Zustand nicht, und belastbare Zahlen gibt es von dort auch keine.

Und ein Nebeneffekt, den ich nicht erwartet hatte: rtk gain --daily ist ein überraschend ehrlicher Spiegel der eigenen Arbeitsweise. Man sieht schwarz auf weiß, an welchen Tagen der Agent sinnvoll gearbeitet hat und an welchen er hauptsächlich Dateien gelesen hat. Das allein macht das regelmäßige Draufschauen schon lohnend.