Die Illusion der Token-Komprimierung: Warum ich RTK skeptisch sehe

• RTK verspricht, die Terminalausgabe von Coding-Agenten zu komprimieren und so Kosten zu senken, aber eine Reduktion der Rohausgabe bedeutet nicht automatisch günstigere, sicherere und präzisere Softwareentwicklung
• „60–90 % Einsparung“ bedeutet nicht, dass sich die LLM-Abrechnung in diesem Ausmaß verringert, sondern kommt eher dem Anteil der Kommandozeilenausgabe nahe, den RTK entfernt
• Wenn silent failures auftreten, bei denen Terminalausgabe stillschweigend beschädigt wird oder fehlt, kann der Agent ohne wichtige Stack-Traces oder Compiler-Kontext falsche Entscheidungen treffen
• Diagramme zur Token-Einsparung allein reichen nicht aus; benötigt werden auch die Task-Success-Rate und SWE-bench-artige Genauigkeitsbewertungen, die zeigen, ob autonome Agenten reale Aufgaben tatsächlich abgeschlossen haben
• RTK wirkt eher wie eine Funktion von Entwicklungstools als wie ein eigenständiges Produkt und ist anfällig für Änderungen an CLI-Ausgaben wie git, cargo, npm und grep, was das Einbinden in den kritischen Pfad von Produktions-Agenten zu einem operativen Risiko macht

---

Die tatsächliche Kostenstruktur hinter den Einsparungszahlen

• RTK wirbt mit geringerem Token-Verbrauch und niedrigeren Kosten durch die Komprimierung von Terminalausgaben für Coding-Agenten
  • Das Projekt hat mehr als 60k GitHub-Stars erhalten, und die Branche reagiert stark auf dieses Marketing
  • Behauptungen von Entwicklungstools, die „zu gut klingen“, sollte man jedoch anhand der tatsächlichen Struktur prüfen
• Die virale Zahl von „60–90 % Einsparung“ entspricht nicht der tatsächlichen Einsparung bei API-Rechnungen
  • RTK reduziert nur einen Teil der Bash-Ausgabe
  • Größere Kostentreiber wie tiefes Dateilesen, Repository-Kontext, System-Prompts und modellinterne Reasoning-Token bleiben bestehen
  • Befehle wie rtk gain wirken eher auf Kennzahlen ausgerichtet, die sich gut für Screenshots in sozialen Medien oder für nichttechnische Manager eignen, als auf grundlegende Architektur-Optimierung
  • Auch in jüngsten GitHub-Issues werden übertriebene Kennzahlen zunehmend hinterfragt

Genauigkeit und operative Stabilität sind die wichtigeren Variablen

• Optimierung ist bedeutungslos, wenn die Genauigkeit nicht mitzieht, und in den öffentlichen Issues des Repositories gibt es bereits Fälle, in denen Terminalausgaben stillschweigend beschädigt oder ausgelassen werden
  • Das zentrale Risiko besteht darin, dass der AI-Agent nicht weiß, dass der Text komprimiert wurde
  • Wenn RTK wichtige Zeilen aus Stack-Traces oder Compiler-Kontext entfernt, um ein paar Tokens zu sparen, arbeiten sowohl Nutzer als auch LLM mit unvollständigen Informationen
  • Die Einführung von RTK bedeutet, sich auf eine externe Schicht zu verlassen, die die Ausgabe zahlreicher CLI-Tools ohne Bedeutungsverlust parsen, interpretieren und zusammenfassen muss
• RTK zeigt Diagramme zur Token-Einsparung, aber die in der Praxis entscheidende Metrik Task-Success-Rate fehlt
  • Entscheidend ist, ob autonome Agenten am Ende ihrer Ausführungsschleife tatsächlich Softwareentwicklungsprobleme gelöst haben
  • Selbst wenn die Prompt-Kosten um 80 % sinken, kann der Agent wegen verschlechtertem Kontext halluzinieren, Builds nicht schaffen oder in Schleifen geraten und am Ende sogar mehr Tokens verbrauchen
  • Solange es neben Kostendiagrammen keine strengen SWE-bench-artigen Genauigkeitsbewertungen gibt, bleibt die Erzählung rund um RTK unvollständig
• Aus Architektursicht fügt RTK dem synchronen kritischen Pfad zwischen Agent und Shell eine anfällige externe Abhängigkeit hinzu
  • Ausgabeoptimierung wirkt eher wie eine Funktion als wie ein eigenständiges Produkt oder eine Plattform
  • Wenn wichtige CLI- und Entwicklungstools native Flags wie --compact oder --json-stream für den LLM-Konsum anbieten, könnte der Hauptvorteil von RTK verschwinden
• RTK ist stark auf das spezifische Parsen menschenlesbarer stdout/stderr-Formate angewiesen, was die Wartung erschwert
  • Wenn git, cargo, npm oder grep ein paar Leerzeichen im Terminalformat oder das Layout von Fehlermeldungen ändern, können die regulären Ausdrücke und Parsing-Filter von RTK brechen
  • In solchen Fällen kann es statt eines expliziten Fehlers zu einem stillen Fehlschlag kommen, der beschädigten oder unvollständigen Text an den Agenten weitergibt
• RTK tauscht für die auffällige Kennzahl einer Reduktion roher Terminal-Tokens deterministische Zuverlässigkeit, semantische Vollständigkeit und architektonische Einfachheit ein
  • Solange silent degradation nicht gelöst ist und keine transparenten Benchmarks zur Task-Genauigkeit vorliegen, ist die Aufnahme in den kritischen Pfad von Produktions-Agenten-Workflows gemessen am Rabatt ein operatives Risiko

[GN⁺]

Hacker-News-Kommentare

• Es ist schön zu sehen, dass solche Beiträge endlich an Zugkraft gewinnen, was die gesamte LLM-Zauberkisten-Industrie angeht
  Von caveman mode über RTK bis zur semantischen Suche wirken Entwickler eher wie Zauberer, die Sprüche aufsagen, als wie Ingenieure, und bei der Arbeit ist es besonders anstrengend, weil jeder überzeugt ist, dass gerade sein eigener Spruch die ultimative Methode zum Tokensparen ist
  Mein Maßstab ist folgender: Ideen, die nicht in einem Evaluations-Harness auftauchen, sind meistens nichts wert, und gute Ideen landen am Ende ohnehin bei Codex/Claude. Auch Werbung auf GitHub, die ein paar Prozent Token-Ersparnis verspricht, ist schwer zu glauben
  In diesem Bereich ist es schwer, betrügerische Tools zu vermeiden, und ich hoffe, dass die Leute anfangen, kritischer darauf zu schauen

  • Das ist völlig falsch und unterschätzt, wie inkompetent die Firmen an der Front in Bereichen außerhalb des Bauens von LLM-Modellen sind
    Ein Jahr lang gab es Beispiele wie blinkende TUIs, die „wie eine Game Engine geschrieben“ waren, und nachdem ich selbst mehrere Benchmarks laufen ließ, gibt es verifizierte Methoden, die bei gleichem Ergebnis Tokens reduzieren. Zum Beispiel dieselbe CVE zu finden oder im Code Review denselben Bug zu entdecken
    Als kleinen Beleg kann man sich https://maki.sh ansehen
  • Deshalb wird alles mit blinden A/B-Tests geprüft
    Dabei verbrennt man viele Tokens, aber man muss beweisen, dass tatsächlich ein Wert entsteht, und die meisten Dinge verfehlen diesen Maßstab komplett
    In meinem AI-Agenten stecken auch mehrere Funktionen, aber ich würde nicht behaupten, dass die Ergebnisse eines blinden A/B-Tests von vor vier Monaten heute noch aussagekräftig sind. Schon meine Wortwahl kann die Resultate stark verändern
    Trotzdem teste ich, um den Wert selbst zu bestätigen und mit eigenen Augen zu sehen. Konkrete Ergebnisse der blinden A/B-Tests veröffentliche ich absichtlich nicht
    Ich habe auch gesehen, wie andere Leute blinde A/B-Tests völlig falsch durchführen, und wenn die Messung schlecht ist, ist der Test selbst bedeutungslos
    Wir alle versuchen, dieses Problem gemeinsam zu lösen, und es gibt viel schwarze Magie, deshalb verlasse ich mich stark auf hooks. Auch in meinem kleinen AI-Agenten steckt sicher eine Menge schwarze Magie
    Das Einzige, was ich sicher weiß, ist, dass es für mich funktioniert. Ohne das wüsste ich ehrlich gesagt nicht, wie die Leute heute überhaupt mit AI arbeiten
    Ich lasse den Link hier, aber das heißt nicht, dass ich es empfehle, egal was du vorhast. Es wird fast nur von anderen Softwareingenieuren benutzt und ist sehr stark auf die Arbeit spezialisiert, die ich erledigen muss. Im besten Fall kann es Ideen liefern, die man selbst umsetzt
    https://github.com/notque/vexjoy-agent
  • Die Aussage „gute Ideen landen bei Codex/Claude“ gilt nur dann, wenn jemand Tools wie RTK baut und andere sie ausprobieren
    Es ist in Ordnung, diese Runde nur zu beobachten, aber Tools wie RTK, Headroom und caveman mode können die zu verarbeitenden Ein- und Ausgabetokens reduzieren und bei lokalen LLMs messbare Geschwindigkeitsgewinne bringen
    Es gibt noch nicht genug Daten, um sagen zu können, ob die Qualität der Endausgabe darunter leidet, aber es macht Spaß, damit herumzuspielen, um das herauszufinden
  • Die Idee selbst ist plausibel. Wenn man das Signal-Rausch-Verhältnis im Kontextfenster verbessern kann, ist das gut
    Ob RTK das tatsächlich leistet, ist aber noch nicht belegt. Ich würde gern Benchmarks sehen, die sauber messen, welchen Unterschied dieses Tool in der Praxis macht, statt bedeutungsloser Formulierungen wie „bis zu 90 %“
  • Darüber hinaus scheinen einige der Optimierungen, die ich in rtk für Befehle wie git status gesehen habe, bereits auf die Modellebene gewandert zu sein
    Codex macht jetzt häufig Tool-Aufrufe wie git status --short statt einfach git status

• Ich bin der Autor des Beitrags. Ehrlich gesagt habe ich das geschrieben, weil rtk ai auf mich als Softwareingenieur sehr merkwürdig wirkt
  Die fehlenden Zahlen, das Ausbleiben jeder Erwähnung zur Genauigkeit und die Art, wie das Management so etwas zur Kostenoptimierung durchdrückt, haben mich gestört. Jetzt wickeln die Leute jeden möglichen Befehl in rtk ein, versuchen alle wichtigen Befehle komplett zu behandeln und wollen sogar festlegen, welche Ausgabe man erhalten soll

  • Ich würde wirklich gern ehrliche Gedanken zu https://www.github.com/jahala/tilth hören
    Das ist ein anderer Ansatz als RTK, und in Benchmarks hat er die Kosten pro korrekter Antwort um etwa 40 % gesenkt
  • Ich verstehe nicht, warum überhaupt keine realen Nutzungszahlen zur Untermauerung der Behauptungen gezeigt wurden. Das war nicht besonders hilfreich

• Tool-Ausgaben machen einen großen Teil meiner Ausgabe aus. Wenn ich von 3,9 Millionen Eingabetokens 3,7 Millionen sparen kann, nehme ich das mit. Gesparte Tokens sind gesparte Tokens
  Als RTK-Nutzer fände ich Genauigkeits-Benchmarks gut, aber ich habe bisher noch keinen Beleg gesehen, dass das Modell wegen der Komprimierung etwas Wichtiges übersehen hat
  In der Designphilosophie wird der Erhalt der Genauigkeit sehr strikt behandelt, und wenn ein Filter fehlschlägt, fällt das System sogar auf die Originalausgabe zurück. Ich habe mir auch den Source-Code der häufig verwendeten Befehle direkt angesehen, er hat mir gefallen, und bisher hat RTK für mich Vertrauen gewonnen
  Es gibt auch die Sorge, dass die Regexe und Parser von RTK kaputtgehen, wenn git, cargo, npm oder grep das Terminal-Formatting um ein paar Spalten ändern oder das Fehlerlayout umstellen, aber wenn ein Filter fehlschlägt, wird auf die Originalausgabe zurückgefallen. RTK ist so gebaut, dass dem Agenten kein beschädigter oder unvollständiger Text vorgesetzt wird
  Die Bedenken sind berechtigt, aber ich würde mir wünschen, dass Kritik durch Belege gestützt wird. Ich frage mich, ob ihr RTK ausprobiert habt und ob ihr Beweise gefunden habt, dass die Genauigkeit nicht erhalten bleibt

  • Ich habe mir die Issues bei der Untersuchung des Themas angesehen, und einige davon wirkten ziemlich übel
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Gesparte Tokens sind nicht immer gesparte Tokens
    RTK entfernt Flags und andere Informationen. Manchmal führt das dazu, dass man später mehr Tokens ausgeben muss, um sie wiederzubekommen. Selbst wenn bei diesem Tool-Call 70 % der Tokens gespart wurden, zeigt die Metrik nicht, ob man den Tool-Call statt einmal nun dreimal gemacht hat
    Man muss auch berücksichtigen, ob die entfernte Ausgabe dazu führt, dass mehr Reasoning-Tokens verbraucht werden
  • Ich glaube nicht, dass es ausreicht, nur zu sagen, dass die Genauigkeit extrem strikt erhalten wird
    Wenn man den Kostenunterschied zwischen aktuellen Modellen und zurückliegenden Open-Weights-Modellen betrachtet oder den Unterschied zwischen dem größten Modell und der nächstkleineren Stufe, dann muss die Performance sehr sorgfältig gemessen werden
    Es ist nicht so sehr die Aufgabe der Kritiker, Belege zu liefern, sondern RTK muss nachweisen, dass RTK die Leistung nicht verschlechtert

• Der Kern ist: Es gibt unzählige Tools, die behaupten, AI besser zu machen, aber es gibt keine Möglichkeit zu messen, ob AI tatsächlich besser funktioniert
  Große Unternehmen mit populären Produkten haben dafür Methoden. Irgendwo zwischen klassischer Produktanalyse und Chatbot-Evaluierung ermitteln sie, ob Nutzer in einer Session erfolgreich sind. Das ist der Job
  Einzelne Entwickler, die pro Tag 3 bis 50 Sessions fahren, haben aber fast keine Möglichkeit zu wissen, was ein LLM wirklich besser macht. Alles ist Bauchgefühl
  In unserem Unternehmen haben wir den ganzen Stack: bevorzugtes Harness, Modell, Skills und sogar Code-Struktur. Es sollte eine Möglichkeit geben zu messen, ob dieses Setup für uns funktioniert, selbst in einem Maßstab von einem Millionstel von Claude Code

  • In meinem Produkt sage ich explizit, man solle den Agenten fragen. Es gibt echte Beispiele und echte Repositories, in denen man das selbst ausprobieren kann
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Der durchschnittliche Token-Spareffekt interessiert mich nicht besonders. Mich interessiert eher, ob die AI unnötige Dateien in den Kontext zieht, denn das kann das Reasoning beeinflussen
    Nach einer Aufgabe kann man den Agenten einfach fragen: „Wie viele Dateien glaubst du, hättest du nicht gelesen, wenn du ihren Zweck vorher gekannt hättest?“
  • Der Aufwand, einen gültigen Benchmark zu erstellen, ist enorm. Wahrscheinlich stimmt das, und genau deshalb ist es noch frustrierender
    Schon bei Frameworks gab es endlose Debatten, und hier ist es noch viel schlimmer. Es wird zum Kampf Bauchgefühl gegen Bauchgefühl. Wer hätte gedacht, dass nichtdeterministische Ausgaben uns bis hierher bringen würden
  • Es gibt eine Antwort. Solche Tools sollte man nicht an bloßen Token-Ersparnissen messen, sondern an Kosten pro richtiger Antwort

• Ich habe es selbst benutzt, und die Nachrichten, die 90 % meines Kontexts ausmachen, werden nicht komprimiert, also wurde nur ein kleiner Teil meines gesamten Token-Verbrauchs komprimiert
  Wenn man den Beitrag aufmerksam liest, steht es dort auch direkt. Wenn man sich /context ansieht, merkt man wahrscheinlich, dass nicht die Tool-Calls die Tokens verbrauchen. Deshalb hat ein Proxy, der nur Tool-Calls komprimiert, keinen großen Effekt, selbst wenn die Aussage stimmt, dass Tool-Calls um das Achtfache komprimiert werden
  In langen Coding-Sessions war das für mich nicht besonders wichtig
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Dieser Beitrag enthält fast keine Daten, die die Gegenargumente stützen, und liest sich größtenteils wie ein von einem LLM erzeugter Text

• Bei Semble haben wir solche Beschwerden auch schon bekommen. Ich halte sie für berechtigt, aber Benchmarks dieser Art zu erstellen ist wegen der Harness × Modell × MCP/CLI-Kombinationen sehr schwierig und teuer
  Bei klassischem Machine Learning oder Tools war es normalerweise ein Warnsignal, keine Benchmarks zu zeigen. Aber bei LLM-Tools bin ich mir da nicht sicher

• Wenn man dem Agenten RTK-Komprimierung bewusst macht und ihm eine Bypass-Option gibt, kann man ihm ermöglichen, Abschneidungen zu erkennen. Ich verwende RTK_DISABLE=1, um den vollständigen Originaltext wiederherzustellen
  Das funktioniert gut, und ja: Da nur Kommandoausgaben komprimiert werden, betrifft das aus „Komprimierungs“-Sicht nur die Eingabetokens

• Es stimmt, dass Mainstream-CLI- und Entwickler-Tools native --compact- oder --json-stream-Flags für den LLM-Konsum bereitstellen könnten, aber sie werden das so schnell wohl nicht tun
  Deshalb versuchen Tools wie rtk, caveman und ponytail, die weiter steigenden Kosten zu senken. In einer Organisation mit 2.000 Leuten liegt das derzeit bei ungefähr 2,5 Millionen Dollar, und alle kennen und justieren diese Trade-offs bereits
  Anders als der Autor behauptet, kennen wir die Trade-offs sehr gut und verwenden die Tools, während wir sie forken, benchmarken und prüfen, ob die Ausgabequalität unseren Anforderungen entspricht. Wir setzen sie nicht blind ein
  Für einzelne Entwickler ist das vielleicht nicht zwingend nötig, und es kann besser sein, zur Kostensenkung andere Modelle selbst zu hosten. In Organisationen ist das aber ein ziemlich schmerzhafter Punkt
  Es ist gut, dass solche Beiträge Aufmerksamkeit auf das Thema lenken, aber wie bei Tools selbst sollte man auch solche Beiträge mit einem gewissen Filter lesen

• Ich habe auf dem Mac rtk gain ausprobiert. Meine Haupt-Entwicklungsmaschine habe ich wegen Speicherproblemen neu aufgesetzt, und dabei ist einiges durcheinandergeraten, sodass ich es dort nicht prüfen konnte. Auf dem Mac wurden aber ungefähr 51.000 Eingabe-Token und 23.000 Ausgabe-Token eingespart, außerdem im Schnitt 3 Sekunden pro Befehl.
  Ich verstehe nicht so recht, warum manche so wütend sind oder warum dafür unbedingt sogar ein Artikel geschrieben werden musste.
  Ich weiß nicht, wer Stacktraces in RTK piped. Ich nutze es nur für ein sehr spezifisches Programm, und Compiler-Ausgaben hineinzuschieben wirkt töricht. Man kann dem Agenten einfach sagen, dass er RTK nur für einen bestimmten Befehlssatz verwenden soll.