Die Frage, wie man KI sinnvoll in die eigene Entwicklungsumgebung einbettet, ohne dabei die Kontrolle über Code und Daten zu verlieren, beschäftigt mich schon seit einer Weile. Zu dem Thema souveräne Entwicklung mit KI habe ich bereits einiges geschrieben. Mit OpenCode folgen wir diesem Weg konsequent weiter – und drei Plugins machen die Nutzung außerdem deutlich günstiger.
Was ist OpenCode?
OpenCode ist ein quelloffener KI-Coding-Agent, der direkt im Terminal läuft. Während Cursor oder GitHub Copilot proprietäre Systeme sind, die den eigenen Code an US-amerikanische Server schicken, kann OpenCode auch mit lokalen Modellen betrieben werden. Außerdem lässt sich das Tool mit über 70 weiteren Modellen konfigurieren – darunter auch einige kostenlose Modelle (diese nutzen die Eingaben dann allerdings zum Training). Das ist kein Kleingedrucktes, sondern Architekturentscheidung.
Wer auf europäisches Hosting setzt – etwa IONOS, STACKIT oder die Open Telekom Cloud – kann OpenCode einfach auf die entsprechenden OpenAI-kompatiblen Endpunkte zeigen und ist unabhängig von den großen US-Plattformen. Kein Lock-in, keine erzwungene Abhängigkeit von einem einzigen Modell.
Die Installation ist unkompliziert:
# macOS/Linux
curl -fsSL https://opencode.ai/install | bash
# oder via Homebrew
brew install anomalyco/tap/opencodeDas Token-Maxxing-Problem
Souveränität kann allerdings einen Haken haben, der sich schnell finanziell bemerkbar macht: Wer für Anfragen an ein Sprachmodell bezahlt, also keine Subscription wie Claude Pro sondern die API nutzt – sei es bei IONOS, OpenAI oder einem anderen Anbieter – der bezahlt pro Token. Und Tokens verschwinden schneller als gedacht.
Ein einzelner „npm test“-Lauf auf einem mittelgroßen Projekt produziert schnell 200 Zeilen Ausgabe. Der Großteil davon sind bestandene Tests, die das Modell eigentlich nicht braucht. „kubectl get pods“ in einem Cluster mit ein paar Dutzend Services liefert eine lange Statustabelle, von der das Modell in den meisten Fällen nur zwei oder drei Zeilen wirklich braucht. Multipliziert man das mit einer längeren Arbeitsession, läuft das Kontextfenster schnell voll – und die Rechnung entsprechend hoch. Ein Caching mit litellm kann helfen, ist aber auch kein Allheilmittel.
Die drei Plugins, die ich im Folgenden vorstelle, greifen dabei an unterschiedlichen Stellen an: RTK und opencode-snip komprimieren die Ausgabe einzelner Befehle, bevor sie den Kontext überhaupt erreichen. OpenSlimedit verkleinert die Tool-Beschreibungen, die bei jedem API-Call mitgeschickt werden. DCP räumt auf, was sich trotzdem im Kontext angesammelt hat.
RTK – Rust Token Killer
RTK ist ein CLI-Proxy, der sich zwischen die Shell und das Sprachmodell setzt. Wenn OpenCode einen Befehl ausführt, fängt RTK die Ausgabe ab, komprimiert sie und gibt nur die relevanten Informationen an das Modell weiter. Das Modell sieht eine saubere, kompakte Ausgabe – ohne dass sich am Workflow irgendetwas ändert. Meiner Erfahrung nach funktioniert dies auch recht gut, witzigerweise hat sich das Modell schon öfter darüber beschwert, dass RTK ein Proxy sei und nicht die volle Information liefert. In diesen Fällen nutzte es dann Python um ungefiltert an die Informationen zu kommen. Denn RTK unterstützt nur eine bestimmte Anzahl an Funktionen. Die genaue Liste findet sich in der Dokumentation von RTK.
Was der Eingriff konkret bedeutet, zeigt ein direkter Vergleich. Ohne RTK liefert „kubectl get pods -n production“ in einem Cluster mit mehreren Diensten beispielsweise folgende Ausgabe:
NAME READY STATUS RESTARTS AGE
api-gateway-7d4f8b9c6-xk2pq 1/1 Running 0 3d
api-gateway-7d4f8b9c6-zr9lm 1/1 Running 0 3d
auth-service-6c8d7f5b4-jn3ks 1/1 Running 0 5d
auth-service-6c8d7f5b4-wt7qp 1/1 Running 2 5d
frontend-deployment-5b9c8d7f6-hm4xr 1/1 Running 0 1d
frontend-deployment-5b9c8d7f6-pv6ns 1/1 Running 0 1d
notification-worker-4a7b6c5d3-ck8yt 0/1 Pending 0 12m
postgres-statefulset-0 1/1 Running 0 10d
postgres-statefulset-1 1/1 Running 0 10d
redis-deployment-3f6e5d4c2-bq5wr 1/1 Running 0 7dMit RTK landet beim Modell stattdessen:
pods: 9/10 Running | 1 Pending: notification-worker-4a7b6c5d3-ck8yt (12m)
restarts: auth-service-6c8d7f5b4-wt7qp (2)Semantisch identisch. Etwa 75 % weniger Token. Der Agentic-Loop des Modells liefert dieselben Ergebnisse – nur günstiger.
Installation
# macOS/Linux – Homebrew empfohlen
brew install rtk-ai/tap/rtk
# oder per curl
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | shDanach RTK als Plugin in OpenCode einbinden:
# Plugin installieren – legt rtk.ts direkt in ~/.config/opencode/plugins/ ab
rtk init -g --opencode
# Verifizieren
rtk gainWer kein separates Binary installieren möchte, kann stattdessen opencode-snip verwenden. Es funktioniert nach demselben Prinzip – CLI-Outputs werden komprimiert, bevor sie das Modell sehen – benötigt aber nur npm und kein zusätzliches System-Binary:
npm install opencode-snip{
"plugin": ["opencode-snip"]
}OpenSlimedit – weniger Overhead bei jedem API-Call
OpenSlimedit verkleinert aggressiv alle Tool-Beschreibungen und komprimiert Read-Outputs. Da Tool-Schemata bei jedem API-Call mitgeschickt werden, spart das tausende Input-Token pro Schritt – unabhängig davon, was der Befehl selbst liefert.
Das ist eine Ebene, die RTK und DCP (dazu gleich mehr) gar nicht berühren. OpenCode kennt eine Reihe von eingebauten Tools – Datei lesen, schreiben, suchen, Shell-Befehle ausführen. Jedes dieser Tools bringt eine Beschreibung mit, die dem Modell erklärt, was es tun kann und wie es aufzurufen ist. Diese Beschreibungen landen bei jedem einzelnen API-Call im Prompt – auch wenn das Modell die meisten Tools in diesem Schritt gar nicht braucht. OpenSlimedit kürzt diese Beschreibungen so weit wie möglich, ohne dass das Modell dabei Funktionalität verliert. Laut den Benchmarks des Projekts ergibt sich daraus eine Einsparung von bis zu 45 % – ohne Konfigurationsaufwand.
Installation
npm install openslimedit{
"plugin": ["openslimedit"]
}DCP – Dynamic Context Pruning
RTK und OpenSlimedit lösen das Problem auf der Ebene einzelner Befehle und API-Calls. DCP löst ein anderes Problem: Was passiert mit dem Kontext, der sich über eine lange Session aufgehäuft hat?
Jeder Coding-Agent liest Dateien, führt Befehle aus, analysiert Fehler. Nach einer Stunde Arbeit liegt im Kontextfenster noch der vollständige Inhalt einer „package.json“, den das Modell vor zwanzig Schritten eingelesen hat und längst nicht mehr braucht. DCP erkennt solche veralteten Tool-Outputs und ersetzt sie durch Platzhalter, bevor der Kontext ans Modell geschickt wird. Die Session-History bleibt dabei unangetastet – DCP verändert nur das, was das Modell tatsächlich sieht.
Ein konkretes Beispiel: Das Modell hat zu Beginn der Session „src/api/routes.ts“ gelesen, um die vorhandene Routing-Struktur zu verstehen. Mehrere Refactoring-Schritte später – neue Endpunkte hinzugefügt, bestehende umgebaut, Datei erneut eingelesen – sitzt das ursprüngliche Read-Ergebnis noch immer im Kontext. Veraltet, nutzlos, teuer. DCP ersetzt es durch:
[Output removed to save context - information superseded or no longer needed]Was vorher ~800 Token belegt hat, sind jetzt 12. Das Modell arbeitet weiter, ohne den alten Stand zu sehen.
Noch deutlicher wird der Effekt bei einem typischen Node.js-Debugging-Szenario: Das Modell führt „npm test“ aus, ein Test schlägt fehl, der vollständige Testlauf mit allen Stack-Traces landet im Kontext. Das Modell korrigiert den Fehler und führt die Tests erneut aus – diesmal erfolgreich. Der ursprüngliche, fehlerhafte Testlauf hängt jetzt noch im Kontext und belegt Platz, den das Modell nicht mehr braucht. DCP entfernt nach konfigurierbaren vier Durchläufen den veralteten Output automatisch. Der Kontext bleibt informativ, ohne aufgebläht zu werden.
Installation
npm install -g @tarquinen/opencode-dcp// ~/.config/opencode/opencode.json
{
"plugin": ["@tarquinen/opencode-dcp@latest"]
}OpenCode neu starten – DCP läuft danach automatisch im Hintergrund. Wer manuell eingreifen möchte, hat Slash-Commands zur Hand:
/dcp compress # Kontext sofort komprimieren
/dcp decompress 2 # Komprimierung Nr. 2 rückgängig machen
/dcp stats # Token-Statistiken der Session anzeigenDrei Plugins, ein Ziel
Die drei Plugins greifen auf unterschiedlichen Ebenen an und behindern sich gegenseitig nicht. RTK oder opencode-snip verhindern, dass überhaupt zu viel Rauschen in den Kontext gelangt. OpenSlimedit reduziert den Overhead, der bei jedem API-Call durch Tool-Beschreibungen entsteht. DCP räumt auf, was sich trotzdem angesammelt hat. Zusammen verlängern sie die nutzbare Sessiondauer deutlich – und senken die Kosten pro Session entsprechend.
Wer OpenCode mit einem europäischen Modellanbieter wie IONOS betreibt und pro Token bezahlt, merkt das direkt in der Abrechnung. Und wer ein Flat-Rate-Modell nutzt, kommt schlicht seltener an Ratenlimits.
Zwei Vorbehalte bleiben: DCP invalidiert durch seine Eingriffe das Prompt-Caching bei Anthropic und OpenAI oder eben auch im Zusammenspiel mit litellm – wer stark auf Cache-Hits setzt, sollte das einkalkulieren. In längeren Sessions überwiegen die Einsparungen erfahrungsgemäß trotzdem. RTK greift außerdem nur bei Bash-Tool-Calls – built-in Tools wie direkte Dateilesungen umgehen den Hook. Für diese Fälle ist DCP dann umso wichtiger.
Ein Thema, das in diesem Artikel bewusst ausgeklammert bleibt, ist persistentes Memory – also die Fähigkeit von OpenCode, Wissen über Sessions hinweg zu behalten. Auch dafür gibt es mittlerweile interessante Plugins. Dazu mehr im nächsten Beitrag.
