Ein minimalistischer Open-Source-Agent und ein Token-Proxy – wie sie dasselbe Problem von zwei Seiten angehen
KI-Coding-Agenten haben ein strukturelles Problem: Je mehr sie tun, desto mehr Kontext verbrauchen sie – und desto schlechter werden sie. Das ist nicht nur eine Kostenfrage. Kontextverschmutzung – irrelevante, redundante oder falsch formatierte Information im Prompt – hat drei konkrete Auswirkungen: Modelle treffen schlechtere Tool-Entscheidungen, wenn zu viele Optionen gleichzeitig sichtbar sind. Prompts werden langsamer verarbeitet, wenn sie unnötig groß sind. Und Agenten-Loops driften stärker ab, weil jeder Schritt auf dem akkumulierten Rauschen aller vorherigen aufbaut.
Große Frameworks schleppen Dutzende Tools mit, von denen ein Großteil nie benötigt wird – jedes kostet Tokens, die dann für die eigentliche Aufgabe fehlen. Gleichzeitig flutet rohe CLI-Ausgabe das Kontextfenster mit ANSI-Codes, Ladebalken und redundanten Logs, die kein Modell braucht, aber alle bezahlen müssen.
Zwei kürzlich erschienene Open-Source-Tools adressieren dieses Problem – von entgegengesetzten Seiten. PI Agent baut den Agenten selbst minimalistisch auf. RTK filtert, was den Agenten erreicht. Zusammen ergeben sie eine praktische Antwort auf die Frage: Wie baut man Agenten-Workflows, die mit dem Kontext sparsam umgehen?
PI Agent: Der Minimalismus-Ansatz
PI ist ein Open-Source-KI-Agent mit rund 3800 GitHub-Stars, entwickelt von Mario Zechner. Die Kernidee ist eine explizite Gegenreaktion auf die Entwicklung großer Agenten-Frameworks: Statt eines „Alleskönner”-Agents mit Plan-Modus, Subagents und hundert eingebauten Tools setzt PI auf einen kleinen Core.
Der Grundansatz: Der Agent-Loop ist minimal gehalten, Tools werden nicht mitgeliefert, sondern geladen wenn gebraucht. Das ist keine Sparmaßnahme, sondern eine architektonische Entscheidung.
Im Agenten-Spektrum positioniert sich PI zwischen zwei Polen: Orchestrierungs-Frameworks wie LangChain oder LangGraph bieten volle Flexibilität und komplexe Multi-Agenten-Workflows – auf Kosten erheblicher Abstraktionsschichten und eines entsprechend großen initialen Kontexts. Am anderen Ende stehen stark opinionated Coding-Agenten wie Claude Code oder Cursor, die tief in Tools, Workflows und Modell-Annahmen integriert sind. PI liegt dazwischen: weniger Framework, mehr Laufzeit-System. Kein aufgezwungener Plan-Modus, keine fest eingebauten Subagents – stattdessen ein Kern, der sich dem Anwendungsfall anpasst.
Was PI darüber hinaus auszeichnet, sind zwei technische Konzepte, die in anderen Agenten-Frameworks selten so konsequent umgesetzt sind:
Self-Modifying Agent: PI kann sich selbst zur Laufzeit erweitern. Per Prompt lassen sich neue Funktionen hinzufügen – ohne Neustart, ohne Code-Änderung. Über 1400 Extensions existieren bereits, und neue entstehen im Gespräch. Das Modell passt sich dem Workflow an, nicht umgekehrt.
Tree-Struktur für Kontext: Statt eines linearen Gesprächsverlaufs arbeitet PI mit einer baumartigen Kontextstruktur. Das erlaubt echtes „Zurückspringen” zu früheren Zuständen – ohne den gesamten Gesprächsverlauf mitzuschleppen. Wer mit langen Agenten-Sessions arbeitet, kennt das Problem: Ein falscher Schritt früh im Prozess vergiftet den gesamten weiteren Kontext. PI löst das strukturell.
Technisch basiert PI auf TypeScript, unterstützt verschiedene LLMs – kein Vendor-Lock-in gegenüber OpenAI, Anthropic oder anderen – und ist unter MIT-Lizenz verfügbar.
Übergabe und Zukunft
Das Projekt wurde von Mario Zechner übergeben – an Armin Ronacher und das Unternehmen Earendil. Es bleibt Open Source unter MIT. Was die Übergabe für die Roadmap bedeutet, ist offen – kommerzielle Produkte auf Basis von PI sind laut eigener Aussage wahrscheinlich. Das ist kein ungewöhnlicher Weg für erfolgreiche Open-Source-Tools, aber ein Faktor, den Teams in ihrer Abhängigkeitsstrategie berücksichtigen sollten.
RTK: Der Token-Proxy
RTK – oft als „Rust Token Killer” bezeichnet – löst ein anderes Problem: nicht wie der Agent aufgebaut ist, sondern was er zu sehen bekommt.
Das Tool sitzt als leichtgewichtiger Proxy (Website, GitHub) zwischen Terminal und AI-Agent. Jede CLI-Ausgabe läuft durch RTK, bevor sie den Agenten erreicht: ANSI-Escape-Codes werden entfernt, Fortschrittsbalken herausgefiltert, repetitive Log-Einträge komprimiert, überflüssige Leerzeilen zusammengeführt. Was beim Agenten ankommt, ist die semantisch relevante Information – ohne das Rauschen.
Die gemessenen Einsparungen sind substanziell: 60 bis 90 Prozent weniger Token bei Befehlen wie git diff, npm install oder pytest. Der Grund liegt in einem fundamentalen Missverhältnis: CLI-Output ist für menschliche Lesbarkeit optimiert, nicht für LLM-Verarbeitung.
Ein typischer git diff enthält ANSI-Farbcodes, Diff-Header, identische Kontextzeilen ringsum und leere Zeilen zwischen Chunks. Was ein Modell davon braucht, lässt sich in einem Satz ausdrücken:
- const result = await fetchUser(id)
+ const result = await fetchUserWithRetry(id, 3)RTK destilliert genau das – semantische Aussage statt Darstellung. Dasselbe gilt für npm install-Output (hunderte Zeilen Dependency-Resolution, von denen nur Fehler und Warnings relevant sind) oder pytest-Läufe mit 2000+ Zeilen, von denen ein Modell die Assertion-Fehler braucht und nichts sonst.
Da RTK auf CLI-Ebene ansetzt, funktioniert es ohne Konfiguration mit allen gängigen Agenten-Frameworks – Claude Code, Cline, Cursor, Windsurf, Aider. Es ist kein Plugin, keine Integration, keine Neukonfiguration des Agenten. Es ist Middleware.
Praktische Wirkung
Die praktische Wirkung ist konkret: Bei einem pytest-Lauf mit 2000+ Zeilen Output – Failures, Warnings, Coverage-Report – reduziert RTK den Kontext so stark, dass der Agent die Fehlermuster noch im selben Run beheben kann, ohne das Kontextfenster zu verlassen. npm install-Output schrumpft von 1200 auf unter 50 Token. CI-Logs belegen keine 80 Prozent des Fensters mehr, bevor die eigentliche Aufgabe beginnt.
Statt „Agent lost context” mitten in einem Refactoring: stabilere Iterationen über mehrere Dateien, weil das Fenster nicht kontinuierlich von Rauschen aufgefüllt wird. Die Einsparung entsteht passiv – kein Prompt-Engineering, keine Anpassung des Workflows.
Sicherheitsaspekte
Wie bei jedem Proxy-Tool gibt es strukturelle Sicherheitsüberlegungen. RTK sitzt im Datenpfad zwischen System und Agent – was gefiltert wird, sieht der Agent nicht.
Das bedeutet: Im Extremfall können sicherheitskritische Ausgaben – etwa Warnungen aus npm audit oder Sicherheits-Scans – herausgefiltert werden, wenn sie von RTKs Kompressionslogik als redundant eingestuft werden. Da RTK Open Source (MIT) ist, lässt sich das Filterverhalten prüfen. Aber in produktiven Umgebungen mit sicherheitsrelevanten Agenten-Workflows sollte man sich das Filterverhalten für die eigenen Befehle einmal konkret ansehen.
RTK hat keinen Zugriff auf den direkten Dateizugriff von Agenten – es verarbeitet nur Terminal-Output. Das begrenzt das Risiko auf die Befehlsebene. Für normale Entwicklungs-Workflows ist das akzeptabel; für hochregulierte Umgebungen empfiehlt sich ein kurzer Evaluierungsschritt.
Zwei Werkzeuge, ein Grundgedanke
PI und RTK lösen verschiedene Symptome desselben Problems: Kontextverschwendung in AI-Agenten-Workflows.
| PI Agent | RTK | |
|---|---|---|
| Ansatzpunkt | Agent-Architektur | CLI-Output-Filter |
| Kern-Vorteil | Kleiner Kontext durch Minimalismus | Weniger Rauschen im Kontext |
| Vendor-Lock-in | Kein (multi-LLM) | Kein (framework-agnostisch) |
| Komplexität | Mittel (eigener Agent-Stack) | Gering (Middleware, sofort nutzbar) |
| Lizenz | MIT | MIT |
RTK sofort einsetzen, wenn du heute Claude Code, Cursor, Cline oder ein anderes Terminal-basiertes Setup nutzt. Kein Umbau, kein Risiko, sofortiger messbarer Gewinn. Lohnt sich ab dem ersten Build-Log.
PI sinnvoll, wenn du einen eigenen Agenten-Stack aufbaust, volle LLM-Flexibilität über Anbieter hinweg brauchst, oder die Kontext-Kontrolle über Framework-Grenzen hinaus optimieren willst. Rechne mit Einarbeitungszeit und eigener Wartung.
Eine Einschränkung zum Vendor-Lock-in: Beide Tools eliminieren Anbieterbindung auf Infrastruktur-Ebene. Was bleibt, sind zwei andere Schichten. Modell-Lock-in entsteht, wenn Prompt-Patterns und Agenten-Verhalten für ein bestimmtes Modell optimiert wurden – ein Wechsel zu einem anderen LLM kann unerwartet viel Anpassungsarbeit bedeuten. Workflow-Lock-in entsteht über Tool-Ökosysteme: Cursors Extension-Markt oder Claude Codes Tool-Integration erzeugen Abhängigkeiten, die nichts mit dem API-Anbieter selbst zu tun haben. Lock-in verschiebt sich – er verschwindet nicht.
Was PI und RTK nicht lösen
Beide Mechanismen reduzieren Kontextvolumen und Rauschen. Was sie nicht leisten: Entscheidungen darüber, welche Information überhaupt in den Kontext gehört.
Drei Schichten fehlen im Stack, den PI und RTK abdecken: Semantische Relevanzbewertung – welche Teile eines Dokuments, einer Codebase oder eines Log-Outputs sind für den aktuellen Task tatsächlich relevant? Das ist ein Retrieval- und Ranking-Problem, das Tools wie LlamaIndex oder eigene Embedding-Pipelines adressieren. Langzeitgedächtnis – Informationen aus vergangenen Sessions, über Kontextgrenzen hinweg, ohne sie jedes Mal neu einlesen zu müssen. Memory-Stores sind hier der fehlende Layer. Intent-Kompression – statt den vollen Verlauf mitzuschleppen, eine semantisch komprimierte Zusammenfassung des Zustands zu halten. Ansätze wie LLMLingua zeigen, dass lange Dokumente auf einen Bruchteil ihrer Tokenzahl destilliert werden können, ohne wesentlichen Informationsverlust.
PI und RTK sind Layer 1: Volumen- und Rauschreduktion. Der vollständige Kontext-Stack braucht mehr Schichten.
Einordnung
Beide Tools sind Reaktionen auf eine Entwicklung, die im letzten Jahr immer sichtbarer wird: Agenten-Frameworks wachsen schneller als die Kontextfenster der Modelle. Der Weg vieler kommerzieller Tools ist, mehr Features zu addieren – was das Problem verschärft. PI und RTK gehen den anderen Weg: Kontext reduzieren, nicht erweitern.
Das ist kein Anti-Commercialization-Statement. Es ist ein pragmatisches Argument für Effizienz. Ein Agent, der 80 Prozent seines Kontextfensters mit Tool-Definitionen und formatiertem Log-Output füllt, kann weniger Aufgaben vollständig lösen als einer, der denselben Raum für den eigentlichen Task nutzt.
Die Frage für Teams ist weniger „Soll ich PI oder RTK nutzen?” – sondern: Wie viel des Kontextfensters meiner Agenten wird gerade wirklich genutzt? Wer diese Zahl nicht kennt, zahlt wahrscheinlich zu viel – in Tokens, in Infrastruktur, und in Qualität.