multi-agent-shogun : huit CLI de codage pilotées par une hiérarchie féodale dans tmux
Samurai-inspired multi-agent system for Claude Code. Orchestrate parallel AI tasks via tmux with shogun → karo → ashigaru hierarchy.
En bref
- De quoi s’agit-il ?
- Le projet de yohey-w fait tourner sept ouvriers et un stratège dans des panes tmux séparés, coordonnés par des fichiers YAML plutôt que par des appels d'API. Le README annonce un coût de coordination nul, ce qui mérite d'être examiné de près.
- À qui s’adresse-t-il ?
- À adopter si vous avez déjà un abonnement forfaitaire à un CLI de codage, une machine Linux ou macOS avec tmux, et des tâches réellement décomposables en sept lots indépendants. À éviter si vous dépendez d'une facturation à l'usage, si vous travaillez sous Windows sans avoir vérifié la procédure d'installation, ou si votre travail est une longue session de raisonnement sur un seul fichier.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 41 jours.
- En quel langage est-il écrit ?
- Principalement Shell, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : faire tourner plusieurs CLI de codage sans écrire de glue
Un CLI de codage comme Claude Code ou Codex travaille dans un seul contexte. Si vous voulez sept choses faites en parallèle, il faut sept terminaux, sept invites, et une discipline personnelle pour savoir qui fait quoi et où en est chacun. multi-agent-shogun prend ce travail à sa charge. Le README le formule ainsi : une commande lance sept ouvriers plus un stratège, et vous pouvez donner l'ordre suivant pendant que les précédents tournent. Le public visé est donc l'utilisateur individuel qui a déjà un abonnement à un CLI et qui veut paralléliser sans installer Postgres, Redis ou un orchestrateur Python. Le projet est écrit en Shell, sous licence MIT, et se présente comme un système d'agents pour Claude Code, étendu depuis à sept CLI distincts.
Shogun, karo, ashigaru : ce que la hiérarchie change concrètement
La chaîne de commandement compte trois niveaux plus un rôle latéral. Vous êtes le seigneur. Le pane shogun reçoit votre commande en langage naturel et la transmet. Le karo, décrit dans la version 5.1.0 comme un contrôleur de trafic, découpe la demande en tâches et les répartit. Les ashigaru, au nombre de sept par défaut, exécutent. Un gunshi, qualifié de stratège, occupe un pane séparé. Le README insiste sur un point de conception : la propriété des fichiers est dédiée par agent, la communication est événementielle et non par sondage répété. C'est ce découpage qui évite que deux agents modifient le même fichier, pas un verrou logiciel. Le diagramme du dépôt montre la flèche descendante du shogun vers le karo, puis l'éventail vers les sept panes et le gunshi. Rien dans le matériel fourni ne décrit de mécanisme de reprise si un agent meurt en cours de tâche.
La coordination passe par le disque, pas par le réseau
C'est le point le plus intéressant du projet. Les agents ne s'envoient pas de messages par API. Ils écrivent et lisent des fichiers YAML sur le disque, dans des panes tmux visibles. Le README affirme que le coût de coordination est nul et que les seuls appels d'API correspondent au travail réel. La comparaison qu'il propose est parlante : l'outil Task de Claude Code exécute les sous-agents séquentiellement dans un même processus, et les Agent Teams font circuler des messages dans une boîte JSON, chaque coéquipier représentant un contexte séparé. Ici, la file d'attente est un répertoire. L'avantage pratique est que vous pouvez lire, comparer et versionner chaque instruction et chaque rapport avec git. L'inconvénient est tout aussi concret : la latence de coordination devient celle du système de fichiers, et l'état du système est dispersé dans des fichiers plutôt que centralisé dans un service interrogeable. Selon la façon dont vous travaillez, l'un ou l'autre compte davantage.
Mise en route : quatre commandes et une permission à accepter
Le README donne la séquence exacte. On clone le dépôt, on entre dans le répertoire, puis on lance bash first_setup.sh, présenté comme la configuration unique : configuration, dépendances, MCP. Ensuite source ~/.bashrc pour recharger le PATH. La quatrième étape est particulière : claude --dangerously-skip-permissions, à exécuter une seule fois, pour l'authentification OAuth et l'acceptation du mode Bypass Permissions, suivi de /exit. Enfin bash shutsujin_departure.sh lance l'ensemble des agents. Les prérequis annoncés sont tmux, bash 4 ou supérieur, et au moins un CLI parmi Claude Code, Codex, Copilot, Kimi, OpenCode, Antigravity et Cursor. Le drapeau dangerously-skip-permissions mérite qu'on s'y arrête : il est cohérent avec un système où huit agents doivent agir sans intervention, mais il déplace la question de la sécurité vers l'isolation de la machine, pas vers le projet lui-même. Le README renvoie à une procédure complète incluant Windows, sans la détailler dans l'extrait disponible.
L'argument du forfait plutôt que du jeton
Le README chiffre son propre raisonnement : huit agents de gamme Opus via API coûteraient environ 100 dollars par heure, contre environ 200 dollars par mois en abonnement CLI. Ces chiffres viennent du projet, pas d'une mesure indépendante, et ils dépendent entièrement des tarifs en vigueur chez chaque fournisseur. L'argument de fond reste valable indépendamment des montants : avec une facturation au jeton, chaque agent supplémentaire a un coût marginal visible, ce qui pousse à en lancer le moins possible. Avec un forfait, le coût marginal est nul jusqu'au plafond d'usage. C'est cette structure d'incitation, plus que le montant exact, qui explique pourquoi le projet est bâti autour de CLI et non d'appels d'API directs. Si vous payez à l'usage, multi-agent-shogun transforme une facture prévisible en facture qui dépend du nombre d'agents que vous oubliez de fermer.
Sept CLI, mais un seul écosystème de permissions
Le support multi-fournisseurs est réel : Claude Code, OpenAI Codex, GitHub Copilot, Kimi Code, OpenCode, Cursor et Antigravity sont listés, et la version 5.0.0 est intitulée OpenCode First-Class Support. Le README attribue à Claude Code une intégration tmux éprouvée et le support de Memory MCP, ce qui suggère que tous les CLI ne sont pas à égalité de fonctionnalités. C'est une limite qu'il vaut mieux connaître avant de répartir ses agents : la mémoire persistante entre sessions, présentée comme un avantage du système, semble liée à un serveur MCP configuré par first_setup.sh, et rien dans le matériel fourni ne précise comment les autres CLI y accèdent. De même, chaque CLI a son propre modèle d'authentification et ses propres drapeaux de permission. Le shogun uniformise la répartition des tâches, pas les politiques de sécurité des outils sous-jacents.
Quand le projet lui-même reconnaît ses limites
L'élément le plus instructif du README est l'encadré en tête : en août 2026, l'auteur a dissous sa propre armée de dix agents pour revenir à un seul agent portant son jugement, et a publié un projet successeur nommé kagemusha, centré sur une boucle de jugement (corrections, principes, règles permanentes) plutôt que sur des agents. Le texte précise que multi-agent-shogun continue de fonctionner tel quel. Il faut prendre cette note au sérieux. Elle indique que le goulot d'étranglement, dans l'expérience de l'auteur, n'était pas la capacité d'exécution parallèle mais la qualité du jugement en amont. Un système qui exécute sept tâches en parallèle ne vous aide pas si ces sept tâches découlent d'une mauvaise décomposition. Le karo, décrit comme contrôleur de trafic depuis la 5.1.0, ne remplace pas cette décomposition : il la répartit.
Alternatives : ce que change vraiment le choix de tmux
Face à LangGraph, le contraste porte sur l'infrastructure. LangGraph modélise le travail comme un graphe d'états et suppose, selon le tableau du README, Postgres ou Redis pour la version parallèle, plus une intégration LangSmith pour l'observabilité. multi-agent-shogun n'a besoin que de tmux et de bash. En échange, il n'offre pas de machine à états formalisée : la reprise après échec, la répartition conditionnelle et les points de contrôle sont à votre charge, via les fichiers YAML. Face à CrewAI, la différence est du même ordre, avec une plateforme et OpenTelemetry en plus côté CrewAI. Le compromis est clair : vous échangez des garanties d'orchestration contre l'absence de dépendances. Pour un développeur seul sur une machine de travail, c'est souvent le bon échange. Pour une équipe qui doit rejouer une exécution à l'identique six mois plus tard, le graphe d'états de LangGraph répond à une question que les fichiers YAML laissent ouverte.
Conclusion éditoriale
À adopter si vous avez déjà un abonnement forfaitaire à un CLI de codage, une machine Linux ou macOS avec tmux, et des tâches réellement décomposables en sept lots indépendants. À éviter si vous dépendez d'une facturation à l'usage, si vous travaillez sous Windows sans avoir vérifié la procédure d'installation, ou si votre travail est une longue session de raisonnement sur un seul fichier. Avant de lancer shutsujin_departure.sh, vérifiez deux choses dans le dépôt : le contenu de first_setup.sh, qui configure les dépendances et le serveur MCP, et la façon dont les fichiers YAML de tâches sont nommés et nettoyés, parce que c'est là que se joue la reprise après un agent bloqué.
Notes de la communauté