fleetmux

Une équipe, pas un simple assistant

Pilotez vos équipes d'IA comme vos conteneurs.

fleetmux fait tourner un agent superviseur et N agents workers sous forme de sessions de terminal visibles. Le superviseur ne fait que juger et répartir le travail ; les workers ne font qu'exécuter ; c'est un daemon, et non les modèles, qui décide quand le travail est terminé. Une session proche de sa limite de contexte passe le relais à une nouvelle session au moyen d'une note de passation écrite, si bien qu'une même tâche peut tourner pendant des heures à travers de nombreuses sessions de modèle.

Démarrer GitHub

Un terminal animé : le superviseur découpe l'objectif et répartit le travail, deux workers exécutent, le daemon vérifie chaque livrable déclaré, worker-1 rédige une note de passation et devient worker-1.1 dans le même volet, puis la tâche est COMPLETED.

La disposition réelle : le superviseur en haut à gauche, history et daemon en bas à gauche, les workers en onglets à droite.

Chef de projet

Un chef de projet, pas un secrétaire

Les agents de type assistant personnel savent déjà lancer des sous-agents, exécuter des tâches planifiées et basculer d'un modèle à l'autre en cas de panne. fleetmux ajoute ce que fait un chef de projet :

Capot fermé, ça tourne

Refermez le capot. Déplacez-vous. Rouvrez. Ça continue.

Fermez le MacBook, emportez-le ailleurs, rouvrez-le, rebranchez-vous au réseau : la flotte continue. Le daemon distingue une machine qui a dormi d'une liaison qui a lâché : quand l'écart entre deux ticks dépasse deux périodes de renouvellement des ponts, il accorde à chaque session trois périodes pour redonner signe de vie avant de conclure à une liaison perdue. Un démarrage qui tombe sur une erreur réseau n'est pas bloqué : il attend 30, 60, 120 secondes, puis réessaie toutes les 300 secondes. Et rien ne redémarre hors ligne — avant de relancer une session, le daemon vérifie le réseau, et sans réseau il attend seulement, sans consommer de tentative ni démarrer de nouvelle génération. La flotte ne se met pas en pause, personne n'a à la relancer à la main, et elle repart dès que le réseau répond.

01

Livraison validée par le programme

L'existence des livrables, la présence de ce qu'ils doivent contenir et le passage des tests sont établis par le daemon, pas repris du compte rendu du modèle.

02

Des sessions qui se prolongent sans fin

Près de la limite de contexte, une session rédige une note de passation et une nouvelle session prend sa place ; une session figée redémarre sur place ; le daemon et le superviseur se surveillent mutuellement.

03

Répartition selon une matrice de capacités

Avant chaque envoi, le conseiller choisit le modèle et le niveau d'effort dans une matrice de capacités (domaine × type de tâche × modèle, chaque case étayée par des preuves), et ce choix doit être validé par cette même matrice ; un plafond d'usage fait passer l'emplacement au modèle utilisable suivant de la chaîne de son rôle, ou met la tâche en pause.

04

Visible de bout en bout

Chaque agent est une session de terminal visible, que vous pouvez observer et reprendre en main à tout moment.

05

CLI officiels, votre propre connexion

Chaque agent tourne dans le CLI de son éditeur, avec votre propre connexion ; aucun jeton n'est extrait, l'identité d'aucun client n'est usurpée et aucun appel d'API ne passe par un proxy.

06

Un budget par tâche

Une carte de budget plafonne les appels, les tours, les heures et le quota par compte ; une table des plafonds d'usage fait descendre d'un cran de modèle ou met l'exécution en pause pour la reprendre plus tard.

07

Des équipes d'équipes

Un worker peut devenir le chef de sa propre sous-flotte : une seule flotte résidente peut ainsi mener plusieurs activités, chacune démarrée et arrêtée selon son propre calendrier.

Comment ça marche

Le parcours d'une tâche

La tâche porte sa propre définition de ce qui est fait : les livrables qu'elle doit produire, la longueur de chacun et ce que chacun doit contenir.

Tâche objectif + livrables déclarés Superviseur découpe et répartit Workers un pas chacun Daemon validation littérale COMPLETED chaque livrable vérifié renvoi — trois renvois bloquent la tâche
Le superviseur ne peut que déclarer des fichiers à vérifier, jamais des commandes à exécuter.
worker-1 contexte 60 % worker-1.1 note de passation worker-1.2 même onglet
Le successeur reprend l'onglet de son prédécesseur ; l'écran retiré et la note passent dans la page history.

Rotation du contexte, pas compaction

À 60 % de la fenêtre de contexte, la session rédige une note de passation en trois sections, l'ancien écran passe dans la page history, et un successeur démarre au même endroit et lit la note. Si le modèle n'écrit rien, un squelette machine est utilisé ; une note manquante ne bloque pas à elle seule la rotation.

Une session figée redémarre sur place ; le daemon et le superviseur se surveillent mutuellement.

CLI mixtes

Mélangez les CLI que vous utilisez déjà

Claude Code officiel, Codex CLI officiel, Pi (modèles Codex et modèles locaux) et opencode cohabitent dans une même flotte. La matrice ci-dessous liste chaque paire superviseur × worker connue de la table des paires, en mode tâche et en mode service.

Paires superviseur × worker, mode tâche. Une paire absente de la table des paires n'est pas prise en charge.
Superviseur ↓ / worker → Claude Code Codex CLI Pi opencode dsh
Pi validé non pris en charge validé test de fumée seulement validé
Codex CLI validé test de fumée seulement validé validé non pris en charge
Claude Code validé non pris en charge validé non pris en charge non pris en charge
Paires superviseur × worker, mode service. Une paire absente de la table des paires n'est pas prise en charge.
Superviseur ↓ / worker → Claude Code Codex CLI Pi opencode dsh
Pi validé non pris en charge validé validé non pris en charge
Codex CLI validé non pris en charge validé test de fumée seulement non pris en charge
Claude Code validé non pris en charge validé non pris en charge non pris en charge
a passé un vrai test de fumée (1 superviseur + 2 workers, 4 contrôles) mode smoke uniquement (démarre avec --lifecycle smoke) non pris en charge (absent de la table des paires)

Les workers Codex (codex+codex) ne sont pas encore validés ; opencode n'est jamais superviseur, et dsh n'est qu'un backend worker en mode tâche. Les paires et leur statut (validée / non validée = --lifecycle smoke seulement / refusée) se trouvent dans fleetmux/config/fleet.yaml#cli_pairs ; toute paire absente de la table est refusée avec un motif avant le provisionnement.

paire de nuit : superviseur Pi + workers Pi 
fleetmux start --supervisor-cli pi --worker-cli pi \
  --supervisor-pi-model openai-codex/gpt-6-astra --supervisor-pi-thinking high \
  --pi-model flashnext/<local-model> --workers 2 --lifecycle <mode> \
  --allow-unsandboxed-pi --allow-development-v2

Cas d'usage

Ce pour quoi c'est conçu

Chaque start indique un --lifecycle ; il détermine ce que « terminé » veut dire et la façon dont l'exécution se clôt.

01

Des opérations limitées aux modèles locaux

Certains environnements n'autorisent que des modèles qui tournent sur vos propres machines, et les modèles locaux collaborent mal. fleetmux retire la collaboration aux modèles pour la confier au daemon : le superviseur ne fait que choisir l'étape suivante, un worker ne fait que l'exécuter, et c'est le daemon qui décide quand un tour est terminé, si le résultat existe et quand une session passe le relais. --max-busy maintient les requêtes simultanées sous la limite mémoire du serveur d'inférence ; le Redis privé de la flotte n'écoute que sur un socket Unix et n'ouvre aucun port.

02

Surveillance de trading : des stratégies confiées à l'IA, revues sur déclenchement

C'est votre propre programme qui surveille les prix et les indicateurs ; lorsqu'un niveau ou un paramètre est franchi, il envoie une requête et le worker titulaire de ce rôle mène une revue complète et répond en JSON. Une requête qui indique to saute le tour du superviseur, et le daemon contrôle les champs de la réponse avant que votre programme ne la lise. La flotte ne passe aucun ordre et ne connaît aucun calendrier.

03

Rapport de recherche planifié

Le planificateur de l'appelant démarre une flotte à heures fixes dans la journée ouvrée : un superviseur et deux workers Claude Code dotés de skills de recherche et d'un MCP de recherche web. L'objectif déclare le fichier du rapport et les sections qu'il doit contenir ; le daemon le valide littéralement, impose un budget de temps strict à l'exécution et ferme l'espace de travail à la fin.

04

Service de jugement résident

Un autre programme envoie des requêtes JSON ; une requête qui indique to va directement au worker de ce rôle. Le daemon contrôle chaque réponse au regard de reply.required et reply.allowed, et l'appelant suspend la flotte en dehors de ses heures de travail avec pause et resume.

Démarrage rapide

Trois étapes et c'est parti

Ouvrez un terminal cmux, configurez votre fournisseur et votre modèle Pi, et remplacez local/my-model ci-dessous.

  1. Vérifiez les prérequis

    • macOS avec cmux ≥ 0.64.25 (new-surface --command) ; lancez start dans un terminal cmux.
    • Pour les agents Codex : Codex CLI ≥ 0.156.
    • redis-server dans le PATH (brew install redis) ; chaque exécution démarre sa propre instance privée et ne touche jamais localhost:6379.
    • Python 3.14 et les paquets de requirements.txt.

  2. Installation

    install 
    git clone https://github.com/justindbca/fleetmux && cd fleetmux
pip install -e .

  3. Démarrez votre première flotte

    première flotte 
    fleetmux start --workers 2 --supervisor-cli pi --worker-cli pi --lifecycle <mode> \
  --pi-model local/my-model --allow-unsandboxed-pi --allow-development-v2
echo '{"goal": "Survey the three most-cited papers on X and write a comparison",
       "hours": 4,
       "artifacts": [{"path": "worker-1/report.md", "min_chars": 800, "contains": ["Conclusion"]}]}' \
  | fleetmux task -                           # hand the goal to the supervisor
fleetmux status                               # task + per-agent state, context usage, inbox depth
fleetmux stop                                 # cancel; confirm runtime retirement before Redis shutdown

    Les nouveaux démarrages exigent Redis v2 et une activation explicite du mode développement ; c'est une intégration de développement, pas une acceptation de production.

    Limites connues

Lire le démarrage rapide complet →