RTK AI: Was der Rust Token Killer macht

RTK steht für Rust Token Killer und ist ein CLI Proxy, der die Ausgabe von Kommandozeilen Befehlen komprimiert, bevor ein KI Coding Agent sie liest. Aus elf Zeilen git status werden drei, aus 200 Zeilen Testausgabe werden die zwei fehlgeschlagenen Tests.

Das Tool ist ein einzelnes Rust Binary, Apache 2.0 lizenziert und ohne Abhängigkeiten. Es klinkt sich über einen Hook in den Agenten ein und schreibt passende Bash Aufrufe transparent um. Das Modell merkt davon nichts, es bekommt nur die kürzere Ausgabe.

Unterstützt werden über 100 Kommandos, darunter git, npm, cargo, pytest, docker, kubectl, ls, cat und grep. Laut README lässt sich RTK in 17 Agents einbinden, darunter Claude Code, OpenCode, GitHub Copilot, Cursor, Gemini CLI, Codex, Cline und Windsurf, das inzwischen Devin Desktop heißt.

Das Versprechen im README lautet 60 bis 90 Prozent weniger Token. Eine 30 Minuten Session soll von rund 118.000 auf 24.000 Token fallen. Genau dieses Versprechen ist der spannende Teil, denn es hält einer sauberen Messung nicht stand.

Never Code Alone arbeitet täglich mit KI Coding Agents, mit Claude Code und OpenCode, mit Open Weight Modellen über Ollama und Z.AI und mit eigenen MCP Servern. Token Verbrauch ist für uns kein Randthema. Bei unserem eigenen Sulu CMS MCP Server haben wir den Verbrauch in typischen Content Workflows um rund 90 Prozent gesenkt und die Messung offengelegt. Wir wissen deshalb, wie schnell ein Tool Dashboard eine Ersparnis meldet, die auf der Rechnung nie ankommt.

Wir helfen Teams dabei, Token Kosten an der richtigen Stelle zu messen. Das beginnt beim Token Verbrauch in der Praxis senken und beim Context Window Management. Es geht weiter über die Optimierung von MCP Responses und die Auswahl passender Modelle im Vibe Coding Consulting. Für die Einordnung von Kostenversprechen ist unser KI Coding ROI der passende Einstieg, für die Modellseite der Kostenvergleich der KI Anbieter.

RTK sitzt zwischen Shell und Modell. Der Agent will einen Befehl ausführen, ein Hook fängt den Aufruf ab und schreibt ihn um. RTK führt das echte Kommando aus, filtert die Ausgabe und gibt nur die verdichtete Fassung zurück.

Der gleiche Effekt greift bei Testläufen. Statt der kompletten pytest Ausgabe bekommt das Modell eine Zusammenfassung mit den Zahlen und dem Text der fehlgeschlagenen Tests. Die Filter sind handgeschrieben, pro Kommando, und in vielen Fällen sauber gemacht.

Wichtig für das Verständnis: Der Hook greift nur bei Bash Aufrufen. Eingebaute Werkzeuge wie Read, Grep oder Glob laufen komplett daran vorbei. Was diese Tools an Text in den Kontext holen, sieht RTK nie. Das steht auch so in der eigenen Dokumentation.

Die Installation ist ein Einzeiler, per Homebrew, winget oder Installationsskript aus dem GitHub Repository rtk-ai/rtk. Danach registrierst du den Hook für deinen Agenten und startest ihn neu. Ab dann läuft die Umschreibung automatisch.

Ein Hinweis aus der Praxis: Auf crates.io gibt es ein zweites Projekt namens rtk, das Rust Type Kit heißt und etwas völlig anderes macht. Wenn rtk gain nicht existiert, hast du das falsche Paket installiert.

Zweiter Hinweis: Das Binary braucht eine aktuelle glibc. In älteren Container Images kann der Start scheitern. Wer RTK in einer CI/CD Pipeline testet, sollte das vorher prüfen. Die Grundlagen im Terminal zeigt unser curl Guide.

JetBrains hat RTK im Juli 2026 sauber gegen einen Standard Agenten getestet. Aufbau: Claude Code in fester Version, Claude Sonnet 5, der Benchmark SkillsBench mit 86 Aufgaben, gepaarte Läufe, einmal bei niedrigem und einmal bei hohem Reasoning Effort. Insgesamt 425 abgerechnete Durchläufe.

Das Ergebnis: keine Ersparnis. Bei niedrigem Reasoning Effort war der Lauf mit RTK im Median 7,6 Prozent teurer, bei einem p Wert von 0,004. Dazu kamen 13,8 Prozent mehr Runden und 14,3 Prozent mehr Cache Reads. Bei hohem Effort verschwand der Aufschlag, blieb aber bei null. Gespart hat RTK an keiner Stelle.

Der Grund liegt in der Rechnung vorab. Nur rund ein Drittel der Bash Aufrufe geht überhaupt durch den Hook, und diese tragen knapp 20 Prozent der Zeichen aus Tool Ergebnissen. Tool Ergebnisse sind wiederum nur ein Teil dessen, was eine Session als Input abrechnet, weil derselbe Kontext in jeder Runde neu gelesen wird. Selbst wenn RTK seinen Anteil um 70 Prozent zusammenstreicht, liegt die Obergrenze bei rund drei Prozent der Input Token.

Die Qualität hat nicht gelitten. Über die vollen Läufe lagen die Ergebnisse bei 5 besser, 4 schlechter, 71 unentschieden. Die Filter schneiden also nichts weg, das der Agent gebraucht hätte. Das Problem ist nicht Pfusch, sondern eine falsche Bezugsgröße.

Der spannendste Befund steckt im Vergleich zwischen Tool Statistik und Rechnung. Über den kompletten Lauf meldete rtk gain rund 96 Millionen gesparte Token, also 99,8 Prozent von allem, was es angefasst hat. Die tatsächliche Rechnung für dieselben Durchläufe stieg.

Drei Mechanismen erzeugen diese Lücke:

1. Falsche Vergleichsgröße: RTK rechnet die komplette Rohausgabe als Basis. Ein cat auf eine 1,2 MB große CSV wurde mit 320.000 gesparten Token verbucht, obwohl der Agent solche Ausgaben ohnehin abschneidet.
2. Grobe Schätzung: RTK schätzt Token als Zeichen geteilt durch vier. Der größte Teil der Input Kosten entsteht aber durch Cache Wiederholungen, die nur zu einem Bruchteil abgerechnet werden.
3. Blinder Fleck: Der Hook sieht den Löwenanteil des Kontexts gar nicht.

Daraus folgt eine Regel, die weit über RTK hinausgeht: Die selbst gemeldete Ersparnis eines Tools ist eine Aussage über seine Vergleichsgröße, nicht über deine Rechnung. Wer ein Kompressionstool bewertet, misst die gepaarte Abrechnung, nicht das Diff des Tools.

RTK ist sauber gebaute Software. Die Filter sind durchdacht, der Hook funktioniert wie beschrieben, die Qualität leidet nicht. Nur ist die Ersparnis eben keine.

Interessant bleibt es dort, wo der Kontext tatsächlich von Shell Ausgaben dominiert wird. Das sind Setups, in denen der Agent kaum eingebaute Lesewerkzeuge nutzt, sondern fast alles über die Bash Ebene abwickelt. Wer viel mit Docker Logs, kubectl Ausgaben oder langen Pipeline Protokollen arbeitet, kann den Effekt messen. Messen ist hier das entscheidende Wort.

Ein Detail für alle, die in Containern arbeiten: In einem der Benchmark Images startete das RTK Binary gar nicht, weil die glibc zu alt war. Der Durchlauf starb im Setup. Wer RTK in eine bestehende CI Umgebung schiebt, testet das Binary zuerst im Zielimage.

Die größere Wirkung liegt woanders:

• Kontext sauber schneiden statt Ausgaben nachträglich zusammenzupressen
• Modelle passend zur Aufgabe wählen
• MCP Responses schlank halten
• klare Regeln in rules.md und AGENTS.md
• Quality Gates, damit der Agent nicht in Schleifen Kontext verbrennt

Für uns gilt: RTK ist ein Werkzeug, das wir kennen und einordnen. In unserem eigenen Stack läuft KI Coding über Claude Code und OpenCode mit Open Weight Modellen. Die Token Disziplin holen wir aus dem Workflow, nicht aus einem Proxy.

RTK war Teil zwei einer Serie. JetBrains nimmt öffentlich beworbene Token Spar Werkzeuge und jagt jedes durch denselben gepaarten A B Benchmark. Derselbe Agent, dasselbe Modell, dieselben Aufgaben, einmal mit Tool und einmal ohne. Erst dieser Vergleich über drei Tools zeigt, wo die Ersparnis wirklich sitzt.

Teil eins war Caveman, ein Skill, der den Agenten in Telegrammstil sprechen lässt. Beworben mit 65 Prozent weniger Token, gemessen 8,5 Prozent. Teil zwei war RTK. Teil drei war Ponytail, ein Skill, der das Modell zwingt, weniger Code zu schreiben. Beworben mit 54 Prozent weniger Code, gemessen 15 Prozent weniger Code und 10,3 Prozent weniger Kosten pro Aufgabe bei einem p Wert von 0,004.

Ponytail ist damit das erste Tool der Serie mit einer belastbaren Ersparnis. Der Grund erklärt rückwirkend, warum RTK nichts gebracht hat. RTK setzt an der Eingabe an, also an dem, was der Agent liest. Diese Seite wird von Cache Wiederholungen dominiert, die ohnehin wenig kosten. Ponytail setzt an der Ausgabe an, also an dem, was das Modell schreibt. Dort liegt das Geld.

Ein zweites Muster zieht sich durch alle drei Teile: Kein Tool hat die Qualität verschlechtert. Nur ist ihre eigene Erfolgsmeldung eine Aussage über ihre Vergleichsgröße und nicht über deine Rechnung. Wer Kontext systematisch komprimieren will, findet in Headroom einen weiteren Ansatz, und in unserem Leitfaden zu weniger Tokens brauchen die Maßnahmen, die ohne Zusatzwerkzeug wirken.

Wir sehen in der Beratung immer wieder dasselbe Muster. Ein Team installiert ein Sparwerkzeug, das Dashboard meldet große Zahlen, die Rechnung bleibt gleich. Der Fehler liegt selten am Tool, sondern an der fehlenden Gegenprobe. Ohne gepaarte Messung weiß niemand, was ein Eingriff wirklich bewirkt.

Unser Vorgehen ist deshalb schlicht. Erst eine Basislinie über echte Aufgaben, dann eine Änderung, dann derselbe Satz Aufgaben noch einmal. Verglichen wird die Abrechnung, nicht die Schätzung eines Tools. Erst wenn ein Effekt mehrere Durchläufe überlebt, gilt er als Effekt.

Danach kommt der Teil, der wirklich Geld spart: sauberer Kontext, passende Modelle, schlanke Tool Antworten, klare Regeln für den Agenten. Wie das im Alltag aussieht, zeigen wir im Vibe Coding Training und im NCA Vibe Coding Consulting. Den Werkzeugkasten zeigt unsere Übersicht der Vibe Coding Tools, wiederverwendbare Bausteine die Seite zu Agent Skills.

Abgerechnet wird transparent minutengenau. Kein Festpreis, keine Pakete, keine Mindestlaufzeit. Das Kennenlernen ist kostenlos, den Aufwand schätzen wir vorher gemeinsam.

Die wichtigsten Fragen zu RTK, zur Installation, zum Nutzen und zur richtigen Messung von Token Kosten.