Empryo: Symbolgenaue Bearbeitung statt String-Patching

Welches Problem der Graph lösen soll

Die README beschreibt das Verhalten üblicher Coding-Agenten in einem Satz: sie greppen, lesen ganze Dateien und patchen Strings, ohne zu wissen, was von der geänderten Stelle abhängt. Das ist keine Übertreibung, sondern die Folge davon, dass Textsuche keine Semantik kennt. Wer eine Funktion umbenennt, findet mit grep alle Vorkommen des Namens, aber nicht die Aufrufe über eine Re-Export-Kette, und schon gar nicht die Datei, die denselben Bezeichner in einem anderen Modul verwendet. Empryo setzt an dieser Stelle an: vor der ersten Änderung soll ein Modell wissen, welche Symbole existieren, wer sie importiert und welche Dateien in der Versionsgeschichte gemeinsam geändert wurden. Die Zielgruppe sind Entwickler in gewachsenen Codebasen, in denen eine einzelne Änderung mehrere Module berührt. Für ein Repository mit zwanzig Dateien ist der Aufwand, einen Graphen aufzubauen, schwerer zu rechtfertigen als ein gezielter grep.

Wie der Code-Genom-Graph entsteht

Beim Start parst Empryo das Repository mit tree-sitter. Laut README unterstützt das über 30 Sprachen. Aus dem Parse-Ergebnis entsteht ein Graph aus Symbolen, Imports und Aufrufstellen. Zwei Signale bestimmen die Reihenfolge: PageRank über den Import- und Aufrufgraphen sowie git co-change, also die Häufigkeit, mit der Dateien in derselben Änderung auftauchen. Beide Signale zusammen ergeben eine Rangfolge, die als Relevanzfilter dient. Das README nennt außerdem blast-radius tags, also Markierungen, die anzeigen, wie weit eine Änderung reicht. Abfragen gegen diesen Graphen laufen laut Dokumentation in Millisekunden und verbrauchen keine LLM-Tokens, weil sie nicht durch ein Modell gehen. Das ist der eigentliche Kern des Entwurfs: Navigation wird aus dem Kontextfenster in eine Datenstruktur verlagert. Ob die Rangfolge in einem konkreten Repository sinnvolle Ergebnisse liefert, hängt davon ab, wie gut Importstruktur und Commit-Historie die tatsächlichen Abhängigkeiten abbilden. In Projekten mit vielen generierten Dateien oder flachen Verzeichnisstrukturen kann das Co-Change-Signal irreführend sein.

AST-Operationen, Batches und das Typecheck-Gate

Bearbeitet wird nicht der Text, sondern der Syntaxbaum. Das README spricht von über 65 symbolgenauen Operationen, die in atomaren Batches laufen: entweder alle Änderungen eines Batches greifen, oder keine, dann rollt das System zurück. Das ist der Unterschied zu einem Patch, der bei einem Konflikt halb angewendet wird. Ein weiteres Detail: nach der strukturellen Änderung dient ein Typecheck als Freigabe. Erst wenn der Typcheck durchläuft, gilt der Batch als erfolgreich. Das erklärt, warum Whitespace keine Rolle spielt: die Operation adressiert ein Symbol, nicht eine Zeile. Die Grenze liegt auf der Hand. Ein Typecheck ist nur so gut wie die Typabdeckung des Projekts. In einer JavaScript-Codebasis ohne Typen oder mit weit verbreitetem any fällt dieses Gate praktisch weg, und die Absicherung schrumpft auf die strukturelle Korrektheit der AST-Operation. Wer in einer solchen Codebasis arbeitet, sollte den Typecheck nicht als Beweis für Korrektheit lesen.

Installation ohne Paketmanager

Empryo wird nicht über Homebrew, WinGet oder npm verteilt. Die README ist an dieser Stelle ungewöhnlich deutlich und verweist auf Installationsskripte sowie direkte Downloads von empryo.com. Für macOS und Linux lautet der Befehl:

curl -fsSL https://empryo.com/install.sh | bash

Unter Windows lautet er:

irm https://empryo.com/install.ps1 | iex

Nach der Installation wird ein Schlüssel gesetzt, hier am Beispiel von Anthropic:

empryo --set-key anthropic sk-ant-...

Alternativ läuft der Agent laut README lokal mit Ollama, dann ohne Schlüssel. Der Start erfolgt aus dem Projektverzeichnis heraus mit empryo. Erwähnenswert ist der Hinweis, dass Binaries nicht von GitHub Releases oder Drittanbieter-Paketmanagern bezogen werden sollen. Das ist eine bewusste Vertrauensentscheidung: der Bezugsweg ist eine einzelne Domain statt eines signierten Pakets in einer öffentlichen Registry. Für Umgebungen mit gesperrten Egress-Regeln oder mit Vorgaben, die Installation ausschließlich über einen Paketmanager zulassen, ist das ein Hindernis, das vor der Evaluierung geklärt werden muss.

Rollenzuweisung und Cache-Verhalten

Empryo betreibt nicht ein Modell in einer Schleife, sondern mehrere benannte Rollen. Die README listet zehn: brain, spark als Scout, ember für Code, explore, verify als Review, goal review, desloppify, summarize, compact und web search. Jede Rolle ist ein Slot, der ein Modell aus einem der 22 genannten Anbieter aufnimmt. Die Zuweisung erfolgt pro Tab, pro Konfiguration oder pro Projekt, und benutzerdefinierte Agenten lassen sich ergänzen. Das Muster dahinter ist eine Kostenentscheidung: günstige Modelle erkunden, teure schreiben. Interessanter als die Rollenliste ist das Cache-Argument. Laut README bleiben Prompt-Cache-Präfixe stabil, und Sub-Agenten erben die Cache-Zeile ihres Elternprozesses, sodass wiederholter Kontext zum Cache-Read-Tarif abgerechnet wird. Das ist eine konkrete Behauptung über das Zusammenspiel von Routing und Anbieter-Caching. Ob sie in der eigenen Konfiguration trägt, hängt davon ab, ob die gewählten Anbieter Prompt-Caching überhaupt anbieten und ob die Rollenwechsel die Präfixe nicht doch verschieben. Die Kostenaufschlüsselung pro Modell, Sub-Agent, Tab, Sitzung und Tag ist jedenfalls die Voraussetzung, um das zu überprüfen.

Die Benchmark-Zahlen und was sie nicht zeigen

Die README nennt zwei Runden gegen pi, mit identischen Modellen, Repositories und Aufgaben. In Runde 1 (3 Bugs, 3 Modelle) werden 8/9 gegen 7/9 gelöste Bugs genannt, 28 Prozent niedrigere Kosten (1,13 gegen 1,58 US-Dollar), 57 Prozent kürzere Wanduhrzeit (4m 16s gegen 10m) und 5,7-mal weniger Input-Tokens (1,09M gegen 6,21M). Runde 2 nutzt fünf echte Bugs aus hono, zod und ky, mit 7/10 gegen 6/10, 23 Prozent niedrigeren Kosten, 32 Prozent kürzerer Laufzeit und 28 Prozent weniger Schritten. Die Methodik soll auf empryo.com/benchmarks liegen, der Nachbau im Repository proxysoul/pi-vs-empryo-bench. Zwei Einschränkungen sind wichtig. Erstens stammen die Zahlen vom Anbieter selbst; die README verweist zwar auf Transkripte, aber eine unabhängige Wiederholung ist damit nicht belegt. Zweitens ist die Stichprobe klein: neun bzw. zehn Aufgaben. Der Abstand von einem gelösten Bug in Runde 2 liegt innerhalb dessen, was ein einzelner Aufgabenwechsel verschieben kann. Die Token- und Kostenunterschiede sind deutlich größer und plausibler an die Graph-Navigation gekoppelt, aber auch sie gelten nur für diese Aufgabenauswahl.

SoulForge, Lizenz und Wartungslast

SoulForge ist nicht verschwunden. Die README schreibt, dass es weiterhin herunterladbar ist und Fehlerbehebungen für Bugs und kritische Probleme erhält, während neue Funktionen zu Empryo wandern. Installiert wird es über einen Homebrew-Tap oder über bun:

brew tap proxysoul/tap && brew install soulforge

bun install -g @proxysoul/soulforge

Wer heute auf SoulForge setzt, sollte den Wechsel als absehbar einplanen: der Quellcode liegt in diesem Repository, die aktive Entwicklung nicht mehr. Zur Lizenz lässt sich aus dem Material wenig sagen. Die Kennung lautet NOASSERTION, und die README verweist für SoulForge auf die Datei LICENSE mit dem Hinweis, dass der Quellcode unter der bestehenden Lizenz archiviert bleibt. Was diese Lizenz erlaubt oder verbietet, ist aus dem vorliegenden Text nicht ableitbar. Wer Empryo kommerziell einsetzen oder weiterverteilen will, muss LICENSE selbst lesen und die Bedingungen mit der eigenen Rechtsabteilung klären. Eine rechtliche Einschätzung ist hier nicht möglich und auch nicht beabsichtigt. Unabhängig davon ist der Release-Takt sichtbar: drei Versionen zwischen dem 8. und 12. Juli 2026, zuletzt v2.20.25. Der letzte Push ins Repository datiert auf den 9. September 2026. Das deutet auf laufende Pflege hin, sagt aber nichts über die Stabilität einzelner Funktionen.

Wann Empryo das falsche Werkzeug ist

Der Ansatz hat einen klaren Fehlerfall: Codebasen, in denen der Syntaxbaum keine verlässliche Struktur liefert. Dazu gehören Sprachen mit Makros, die der Parser nicht auflöst, Templates, die erst zur Laufzeit entstehen, und Projekte, deren Abhängigkeiten über dynamische Imports oder Reflection laufen. In solchen Fällen beschreibt der Graph nicht das, was zur Laufzeit passiert, und eine symbolgenaue Änderung kann an einer Stelle vorbeigehen, die kein Symbolbezug erfasst. Der zweite Fall ist die Größenordnung. Der Graph wird beim Start aufgebaut, und die README macht keine Angabe zur Aufbauzeit oder zum Speicherbedarf bei sehr großen Repositories. Wer ein Monorepo mit mehreren hunderttausend Dateien betreibt, sollte das vor einem Rollout messen statt annehmen. Drittens die Frage der Alternativen. Ein Editor mit funktionierendem LSP plus ein agentenfähiges Plugin deckt einen Teil desselben Bedarfs ab: Referenzen finden, Umbenennungen ausführen, Typfehler sehen. Der Unterschied liegt weniger in der Fähigkeit als in der Zuständigkeit. Beim Editor-Ansatz entscheidet der Mensch, welche Referenzen relevant sind, und das Modell bekommt sie vorgelegt. Bei Empryo entscheidet der Graph, was in den Kontext kommt, und der Agent arbeitet ohne Zwischenschritt. Das ist schneller, verschiebt aber die Kontrolle über die Auswahl der Fundstellen von der Person zum Ranking. Wer diese Kontrolle behalten will, für den ist der Editor-Weg der passendere.

Redaktionelles Fazit

Empryo passt zu Teams, die in großen, stark vernetzten TypeScript- oder Mehrsprachprojekten arbeiten und die Kosten pro Änderung senken wollen, weil der Graph Navigation übernimmt. Wer ein kleines Skript-Repository pflegt oder ohnehin einen Editor mit belastbarem LSP-Zugriff nutzt, gewinnt wenig. Vor dem Ausrollen sollte man klären, was unter der NOASSERTION-Kennung in LICENSE tatsächlich steht, ob die Installationsskripte in einer gesperrten Umgebung erlaubt sind und ob die eigenen Sprachen unter den 30+ unterstützten liegen.

Offizielle Quellen

1. Issues
2. Project website
3. proxysoul/Empryo on GitHub
4. README
5. Releases