oh-my-pi im Detail: Ein Coding-Agent mit eingebauter IDE und warum das Bearbeitungsformat über den Modellerfolg entscheidet

Einordnung: ein Coding-Agent mit eingebauter IDE

oh-my-pi, auf der Kommandozeile omp genannt, wird von can1357 bei Stencil Labs gepflegt. Es ist ein Fork von Pi, dem Open-Source-Projekt von Mario Zechner. Der Leitsatz ist kurz: „Ein Coding-Agent mit eingebauter IDE". Das README nennt diese Größenangaben: mehr als 60 Modellanbieter, 31 eingebaute Werkzeuge, 14 LSP-Operationen, 28 DAP-Operationen und rund 80.000 Zeilen Rust im Kern. Die Zahlen stammen vom Projekt selbst, und wir haben nicht jede einzeln geprüft. Sie zeigen aber die Absicht. omp will nicht nur ein Modell mit Terminal sein. Der Agent soll all das können, was Entwickler von einer IDE gewohnt sind.

Der Technologie-Stack besteht aus TypeScript, Rust und der Bun-Laufzeit. Nötig ist Bun 1.3.14 oder neuer, lauffähig auf macOS, Linux und Windows. Das README erwähnt außerdem einen Test der Beitragsregeln: Pull Requests sind vorerst für alle offen. Früher brauchte man ein Vouch, also eine Empfehlung. Dieses System kann je nach Ergebnis des Tests zurückkehren.

Kernarchitektur: drei Schichten auf Pi

Aus dem README lassen sich drei Schichten ablesen. Die erste ist die von Pi geerbte Agentenschleife samt Terminaloberfläche. Die zweite sind die „Batterien" von omp: viele eingebaute Werkzeuge, Modellanpassung und Prompt-Abstimmung. Die dritte ist die Sprachdienst-Schicht, die einer IDE entspricht, nämlich LSP und DAP.

LSP, das Language Server Protocol, liefert Sprung zur Definition, Suche nach Referenzen, Diagnosen, Umbenennen und ähnliche Operationen. Das README sagt: „Alles, was deine IDE weiß, weiß der Agent." Mit 14 LSP-Operationen muss der Agent Symbolbeziehungen nicht mehr mit grep erraten. Er fragt den Sprachserver. DAP, das Debug Adapter Protocol, ist bei Agenten seltener. Die 28 Operationen erlauben Haltepunkte, Einzelschritte und das Prüfen von Variablen. Das ersetzt den groben Ablauf aus Log-Zeilen einfügen und neu starten durch eine echte Debug-Sitzung. Für einen automatisierten Agenten machen diese beiden Protokolle aus einem Texteditor eine Entwicklungsumgebung.

Der Rust-Kern übernimmt die leistungskritischen Teile. Das README betont die Suchgeschwindigkeit, etwa mit der Formulierung „der Schnellste im Westen" für grep, und sagt, Suchen kämen sofort zurück. Implementierungsdetails oder Such-Benchmarks nennt es nicht. Wir behaupten daher nichts darüber hinaus.

Funktionsweise: Das Bearbeitungsformat ist der Engpass

Das zentrale Argument hinter omp lautet: Die Qualität hängt nicht nur vom Modell ab, sondern auch vom Harness, also der Umgebung um das Modell. Der Autor veröffentlichte am 12. Februar 2026 einen Beitrag mit dem Titel „The Harness Problem", auf den das README verweist. Die Idee: Dasselbe Modell verhält sich in verschiedenen Harnesses sehr unterschiedlich, und das Bearbeitungsformat zählt am meisten. Gibt ein Modell einen falsch geformten Diff aus, lehnt das Werkzeug ihn ab. Der Agent gerät dann in eine Wiederholungsschleife. Wiederholungen verbrauchen Tokens und verschmutzen den Kontext. omp stimmt Werkzeuge und Prompts für jedes Modell ab, damit Änderungen beim ersten Versuch gelingen. Die Tabelle im README nennt vier Beispiele: - Grok Code Fast 1: Die Erfolgsquote steigt von 6,7 % auf 68,3 %, etwa das Zehnfache. Der Autor führt das darauf zurück, dass das Bearbeitungsformat das Modell nicht mehr „auffrisst".

• Gemini 3 Flash: 5 Prozentpunkte über str_replace. Laut Autor schlägt das Googles eigenen besten Versuch mit diesem Format.
• Grok 4 Fast: 61 % weniger Ausgabe-Tokens, weil die Wiederholungsschleife bei fehlerhaften Diffs entfällt.
• MiniMax: das 2,1-Fache an Erfolgsquote, bei gleichen Gewichten und gleichem Prompt.

Wichtig: Das sind Zahlen des Autors. Testmenge, Stichprobengröße und Vergleichswerte stehen im Blogbeitrag, nicht in der README-Tabelle. Man behandelt sie besser als Hinweise, die man prüfen sollte, denn als gesicherte Ergebnisse. Der zugrunde liegende Effekt ist plausibel: Der Entwurf des Bearbeitungswerkzeugs kann verändern, wie nützlich ein bestimmtes Modell ist. Das README nennt weitere Entwurfspunkte. Das Werkzeug `read` liefert zusammengefasste Ausschnitte statt ganzer Dateien, mit abgestimmten Standardwerten und guter Trefferquote bei Selektoren. Die `prompts` werden für jedes Modell unablässig angepasst.

Code-Ausführung mit Werkzeugaufrufen

Die erste Funktion, die das README vorstellt, ist Code-Ausführung mit Werkzeugaufrufen. Die meisten Harnesses geben dem Agenten eine Python-Sandbox und hören dort auf. omp betreibt einen dauerhaften Python-Kernel und einen Bun-Worker. Beide Kernel können über eine Loopback-Brücke die eigenen Werkzeuge des Agenten zurückrufen, etwa read, search und task.

Im README-Beispiel lädt der Agent in Python mit tool.read eine CSV-Datei und zeichnet sie dann aus JavaScript als Diagramm, ohne die Zelle je zu verlassen. Der Nutzen ist klar. Zwischendaten bleiben im Kernel. Sie müssen nicht bei jedem Schritt durch den Modellkontext zurück. Bei großen Dateien und mehrstufigen Analysen spart das Kontext und entspricht eher der Arbeit eines Menschen im Notebook. Das Risiko liegt an derselben Stelle. Code-Ausführung mit Werkzeug-Rückrufen vergrößert die Angriffsfläche. Ein Unternehmen sollte die Berechtigungsgrenzen prüfen, bevor es den Agenten breit einsetzt.

Installation und Ökosystem

Die Installationswege sind vielfältig: ein curl-Einzeiler für macOS und Linux, Homebrew, eine globale Bun-Installation (im README als empfohlen markiert), Nix, PowerShell unter Windows und festgelegte Versionen über mise. Nix-Nutzer erhalten ein Flake mit packages, overlays, nixosModules und homeManagerModules. Eine Home-Manager-Konfiguration kann omp installieren und die Einstellungen deklarativ verwalten, zum Beispiel `settings.startup.quiet = true`. Unter Alpine müssen zuerst libstdc++ und libgcc installiert werden, weil das vorgebaute musl-Binary sie dynamisch einbindet.

omp erzeugt seine Shell-Vervollständigungen für bash, zsh und fish selbst, aus den laufenden Befehls- und Flag-Metadaten. Sie driften daher nicht von der echten CLI weg. Modellnamen für `--model`, `--smol`, `--slow` und `--plan` werden aus dem mitgelieferten Modellkatalog vervollständigt. `--resume` nutzt die Sitzungen auf der Festplatte. Die Flag-Namen deuten an, dass omp für verschiedene Aufgabenphasen verschiedene Modelle nutzen kann. Die genauen Regeln gehören in die offizielle Dokumentation.

Folgen für Entwickler und Unternehmen

Für Einzelentwickler liegt der Reiz in einem Werkzeug, das sofort läuft und bis ins Innere offen bleibt. Mit mehr als 60 Anbietern ist der Modellwechsel günstig. Die Abstimmung pro Modell zählt vor allem für Teams, die mehrere Hersteller mischen.

Für Unternehmen helfen die Unterstützung für Nix und Home Manager sowie die Installation mit festgelegter Version bei reproduzierbaren Umgebungen. Durch die LSP- und DAP-Anbindung kann der Agent die Sprachdienst-Konfiguration nutzen, die ein Team bereits besitzt.

Grenzen und Ausblick

Erstens sind die meisten Leistungszahlen selbst berichtet und nicht von Dritten reproduziert. Zweitens bilden 31 Werkzeuge, zwei Code-Kernel, LSP und DAP eine große Oberfläche. Lernaufwand und Aufwand für die Sicherheitsprüfung sind real. Drittens muss omp als Fork von Pi dem Upstream folgen, was dauerhafte Wartungslast bedeutet. Viertens ist die Pull-Request-Regel noch ein Test, die Governance der Community kann sich also ändern.

Wahrscheinliche Richtungen sind mehr Abstimmung pro Modell, tieferes Debugging und strengere Rechtekontrolle. Unser Rat ist praktisch. Lesen Sie zuerst „The Harness Problem". Lassen Sie omp dann auf Ihrer eigenen Codebasis mit den Modellen laufen, die Sie ohnehin nutzen, und prüfen Sie die Prozentwerte an Ihren eigenen Aufgaben.