multi-agent-shogun: Acht Coding-CLIs unter einer tmux-Hierarchie

Das Problem: acht CLI-Sitzungen, die niemand koordiniert

Wer heute mehrere Coding-Agenten parallel laufen lassen will, öffnet mehrere Terminalfenster und wechselt zwischen ihnen. Das funktioniert bei zwei Aufgaben, wird bei sieben aber unübersichtlich: Wer arbeitet gerade woran, welche Datei ist schon belegt, und welcher Agent wartet auf eine Entscheidung? multi-agent-shogun setzt genau dort an. Das Projekt startet laut README sieben Ashigaru genannte Arbeiter plus einen Gunshi genannten Strategen in tmux-Panes und stellt ihnen einen Karo als Verteiler sowie einen Shogun als Eingabepunkt voran. Die Zielgruppe sind nach der Selbstbeschreibung Nutzer, die ein Flatrate-Abo für ein Coding-CLI besitzen und mehrere unabhängige Aufgaben gleichzeitig abarbeiten wollen, statt Token für Koordination zu verbrennen. Das ist ein enges, aber klar umrissenes Publikum.

YAML auf der Platte statt Nachrichtenbus

Der interessanteste Teil ist die Koordinationsschicht, und sie ist bewusst primitiv. Die Agenten sprechen laut README über YAML-Dateien auf der Festplatte miteinander, nicht über einen Broker, eine Datenbank oder ein Mailbox-System. Der Shogun nimmt eine natürlichsprachige Anweisung entgegen, der Karo zerlegt sie in Teilaufgaben, die Ashigaru führen sie aus. Jeder Agent hat laut Projektbeschreibung eigene Dateien, die Kommunikation ist ereignisgesteuert und nicht pollend. Daraus folgt die eigentliche Kostenaussage: API-Aufrufe fallen nur für die Arbeit selbst an, nicht für die Abstimmung. Das README nennt das Null Koordinationsaufwand. Man muss diese Zahl nicht wörtlich nehmen, um den Mechanismus zu verstehen. Ein Dateisystem ist ein nebenläufigkeitssicherer Speicher nur in dem Maß, in dem die Skripte es erzwingen. Sobald zwei Ashigaru dieselbe Datei anfassen, entscheidet nicht das YAML-Format, sondern die Disziplin der Prompts, wer gewinnt. Das ist der wunde Punkt des Designs.

Sieben CLIs, ein Startskript

Die Installation ist kurz und vollständig dokumentiert. Nach git clone und cd multi-agent-shogun folgt bash first_setup.sh für Konfiguration, Abhängigkeiten und MCP, danach source ~/.bashrc, um den PATH neu zu laden. Für den ersten Start nennt das README claude --dangerously-skip-permissions, um OAuth abzuschließen und Bypass Permissions zu akzeptieren, gefolgt von /exit. Erst dann startet bash shutsujin_departure.sh alle Agenten. Voraussetzungen sind tmux, bash 4 oder neuer und mindestens eines der unterstützten CLIs: Claude Code, OpenAI Codex, GitHub Copilot, Kimi Code, OpenCode, Cursor oder Antigravity. Die Multi-CLI-Unterstützung ist der zweite Kernpunkt des Projekts. OpenCode erhielt in v5.0.0 laut Release-Titel First-Class Support, v5.1.0 widmet sich dem Karo als Traffic Controller. Wer bereits mehrere Abos parallel bezahlt, kann sie hier unter einer Oberfläche bündeln.

Bypass Permissions ist kein Nebensatz

Der Schritt claude --dangerously-skip-permissions steht im Quick Start und wird dort nicht weiter kommentiert. Das ist die größte Einschränkung des Projekts, und sie wird im README unterbelichtet. Acht Agenten, die ohne Rückfrage Dateien schreiben, Shell-Befehle ausführen und Netzwerkzugriffe starten, arbeiten in einem Modus, den Anthropic selbst mit dem Wort dangerously versieht. Wer dieses System auf einem Rechner mit Produktionszugängen, Cloud-Credentials oder einem beschreibbaren Home-Verzeichnis startet, gibt acht Prozessen gleichzeitig dieselben Rechte. Das README empfiehlt den Modus für den ersten Lauf, um OAuth abzuschließen, aber die Architektur setzt ihn faktisch dauerhaft voraus, weil eine interaktive Bestätigung pro Pane die Parallelität zerstören würde. Ein Container ohne Mounts oder eine dedizierte VM ist hier keine Übertreibung, sondern die naheliegende Konsequenz. Wer das nicht will, sollte das Projekt nicht einsetzen.

Der Autor hat seine eigene Armee aufgelöst

Bemerkenswert ist der Hinweis am Anfang des README. Im August 2026, also rund drei Monate nach v5.1.0, hat der Autor seine eigene Zehn-Agenten-Armee auf einen einzigen Agenten reduziert, der sein Urteilsvermögen trägt. Das Nachfolgeprojekt heißt kagemusha und liefert laut Beschreibung die Formen einer Urteilsschleife aus Korrekturen, Prinzipien und stehenden Regeln, nicht die Agenten selbst. multi-agent-shogun funktioniere weiterhin unverändert. Diese Fußnote ist die ehrlichste Information im ganzen Repository. Sie sagt nicht, dass das Werkzeug kaputt ist, aber sie sagt, dass der Autor nach eigener Erfahrung mit zehn Agenten zu einem anderen Schluss gekommen ist. Wer das Projekt evaluiert, sollte diese Randnotiz nicht überlesen. Sie ist kein Marketing, sondern ein Erfahrungsbericht aus erster Hand, und sie steht in direktem Kontrast zum Rest der Präsentation.

Wann LangGraph oder CrewAI die bessere Wahl sind

Die README-Tabelle vergleicht das Projekt mit dem Task-Tool von Claude Code, mit Agent Teams, mit LangGraph und mit CrewAI. Der Vergleich ist nicht neutral, aber er benennt einen realen Unterschied. LangGraph modelliert einen zustandsbehafteten Graphen und betreibt ihn auf Infrastruktur wie Postgres oder Redis. CrewAI arbeitet mit rollenbasierten Agenten und einer Plattform. Beide zahlen für Koordination mit API-Aufrufen oder Infrastruktur, liefern dafür aber etwas, was multi-agent-shogun nicht hat: einen reproduzierbaren Ausführungsgraphen. Wer Fehler nachstellen, Läufe wiederholen oder einen Audit-Trail über jede Entscheidung führen muss, ist hier falsch. Ein Verzeichnis voller YAML-Dateien ist lesbar und versionierbar, aber es ist kein Ausführungsprotokoll mit Zeitstempeln und Determinismus. Der Unterschied liegt nicht im Grad der Parallelität, sondern darin, ob der Ablauf nachvollziehbar definiert oder aus dem Verhalten der Agenten emergiert.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Projekt steht unter MIT-Lizenz. Das ist die permissivste gängige Wahl: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Copyright-Hinweis erhalten bleibt. Wer das System in ein internes Werkzeug einbettet, muss den Lizenztext mitliefern, und es gibt keine Copyleft-Pflicht, den eigenen Code offenzulegen. Das ist keine Rechtsberatung, sondern die übliche Lesart von MIT. Der Wartungsaufwand hängt an den CLIs, die das Projekt ansteuert, nicht am Projekt selbst. Ändert ein Anbieter seine Kommandozeilen-Flags oder seinen Login-Fluss, brechen die Shell-Skripte, und der Nutzer wartet auf einen Patch oder schreibt ihn selbst. Die Release-Historie zeigt drei Versionen zwischen April und Mai 2026, danach bis August nur noch der Hinweis auf das Nachfolgeprojekt. Wer plant, das System produktiv zu betreiben, sollte vorher klären, ob der Autor weiterhin auf CLI-Änderungen reagiert, und ob das eigene Team Shell-Skripte warten kann. Ein Blick in first_setup.sh zeigt konkret, welche Verzeichnisse, PATH-Einträge und MCP-Konfigurationen das Skript anlegt, und das ist die erste Datei, die man vor der Ausführung lesen sollte.

Redaktionelles Fazit

Wer bereits ein Flatrate-Abo für Claude Code, Codex oder einen der anderen unterstützten CLIs besitzt und mehrere unabhängige Aufgaben parallel laufen lassen will, findet hier ein schlankes Modell ohne Serverinfrastruktur. Wer reproduzierbare Pipelines, Audit-Trails oder Windows ohne WSL braucht, sollte Abstand nehmen. Vor dem ersten Einsatz lohnt ein Blick in first_setup.sh, um zu sehen, welche Verzeichnisse und MCP-Einträge das Skript anlegt, und ein Testlauf mit reduzierter Ashigaru-Zahl, bevor die Bypass-Permissions dauerhaft aktiv bleiben.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Releases
5. yohey-w/multi-agent-shogun on GitHub