MassGen: orchestration multi-agents en terminal, entre redondance et vote

Le problème: un seul modèle, un seul passage, une seule réponse

Un appel classique à un LLM produit une réponse, puis s'arrête. Si elle est fausse, il faut reformuler la question, changer de modèle ou ajouter du contexte à la main. MassGen part d'un principe différent: au lieu d'espérer que le bon modèle trouve la bonne réponse du premier coup, il fait travailler plusieurs agents sur le même énoncé et laisse la comparaison faire le tri. Le README résume la démarche par deux mots, redondance et raffinement itératif. Chaque agent traite le problème entier, pas un fragment, puis observe et critique le travail des autres.

Le public visé est précis. Il faut être à l'aise avec un terminal, disposer de clés API pour au moins deux fournisseurs, et accepter de payer plusieurs inférences là où une seule suffirait. Un développeur qui veut juste poser une question à un modèle n'a rien à faire ici. Le projet cite comme origine les idées de threads of thought et de iterative refinement présentées dans un article intitulé The Myth of Reasoning, et prolonge l'idée de conversation multi-agents d'AG2. La filiation est assumée, pas dissimulée.

Ce qui circule entre les agents: critiques, partage, vote

La mécanique décrite dans le README tient en trois temps. Les agents travaillent en parallèle sur la même tâche. À chaque cycle, ils publient leur production, lisent celle des autres et la commentent. Puis, quand un agent juge qu'une réponse est suffisamment solide, un vote est déclenché et la réponse validée collectivement l'emporte.

Deux éléments méritent l'attention. D'abord, la convergence n'est pas imposée par un planificateur externe: le README parle de convergence naturelle par raffinement collaboratif. Ensuite, le mécanisme de redémarrage (restarts) laisse entendre qu'un cycle peut être relancé plutôt que corrigé sur place. Ce sont ces redémarrages qui rendent le coût en tokens difficile à prévoir, puisqu'ils dépendent du comportement des agents et non d'un nombre fixé à l'avance.

L'interface est un TUI construit sur Textual, avec une timeline. Le README mentionne aussi un fichier status.json et un BackgroundShellManager pour l'automatisation, ce qui suggère qu'un orchestrateur externe peut suivre l'avancement sans lire la sortie terminal. Le détail du schéma de ce fichier n'est pas reproduit ici.

Mise en route: installation, clés, première commande

Le README donne l'installation par PyPI, avec une exigence de Python 3.11 ou plus récent. La configuration des accès se fait par variables d'environnement, une par fournisseur. La commande de base prend la forme suivante, avec un agent unique pour commencer:

uv run massgen --model claude-3-5-sonnet "votre question"

Pour la collaboration multi-agents, le README décrit une configuration par fichiers YAML, avec un paramètre de type agent et une liste d'agents. Le mode interactif multi-tours existe également. Le projet prend en charge le Model Context Protocol ainsi que les opérations sur le système de fichiers et la gestion d'espace de travail, ce qui permet aux agents de lire et écrire dans un répertoire de travail. Une intégration de contexte utilisateur par chemins est apparue en v0.0.21.

Point pratique: le README mentionne l'installation de MassGen comme skill via npx skills add massgen/skills --all, pour l'invoquer depuis Claude Code, Cursor ou Copilot. C'est une porte d'entrée distincte de l'usage en ligne de commande, et elle ne remplace pas l'installation Python.

Le coût caché: plusieurs modèles frontier, plusieurs cycles

C'est la limite la plus concrète du projet, et le README ne la chiffre pas. Faire tourner trois agents sur trois modèles frontier pendant plusieurs cycles de critique, avec redémarrages possibles, multiplie la facture d'inférence par un facteur qui dépend du comportement du système, pas d'un réglage. Sur une tâche courte et bien posée, un appel unique à un bon modèle coûtera moins cher et répondra aussi bien. MassGen devient intéressant quand la tâche est assez difficile pour qu'une première réponse soit souvent insuffisante, et assez courte pour que la facture reste acceptable.

Deuxième limite: la latence. Le parallélisme aide, mais chaque cycle attend les productions des autres agents avant de les critiquer. Le gain de qualité se paie en temps mural, ce qui exclut les usages interactifs où l'utilisateur attend une réponse en quelques secondes.

Troisième point, la licence. Le badge du README affiche Apache 2.0, mais les métadonnées du dépôt renvoient NOASSERTION, ce qui signifie que GitHub n'a pas su identifier de licence reconnue. Avant toute réutilisation en entreprise, il faut ouvrir le fichier LICENSE et le lire. Je ne peux pas trancher cette contradiction à partir des seuls éléments fournis.

Face à un simple appel API ou à un framework d'agents

L'alternative la plus directe n'est pas un autre framework, c'est un seul appel à un modèle frontier. La différence est structurelle: un appel unique produit une réponse sans confrontation, MassGen produit un ensemble de réponses qui se critiquent mutuellement avant qu'une seule soit retenue. Le second coûte plus cher et prend plus de temps, en échange d'une réduction du risque qu'une erreur isolée passe sans être relevée.

Face à un framework d'agents classique, la différence porte sur la répartition du travail. Dans un montage courant, un agent planificateur découpe la tâche et délègue des sous-problèmes à des agents spécialisés. MassGen fait l'inverse: chaque agent reçoit le problème entier, et c'est la comparaison entre productions complètes qui fait la qualité. Cette approche évite les erreurs de découpage, mais elle interdit de spécialiser un agent sur une sous-tâche précise. Le README rattache explicitement cette démarche à l'idée de test-time scaling, c'est-à-dire dépenser plus de calcul au moment de la réponse plutôt qu'à l'entraînement.

Cadence de publication et surface à maintenir

Les trois dernières versions publiées, v0.1.95, v0.1.96 et v0.1.97, sont datées du 8, du 10 et du 12 juin 2026. Deux jours entre chaque. Ce rythme indique un projet en développement actif, pas un dépôt stabilisé. Le corollaire est direct: une version figée dans un requirements.txt vieillira vite, et les notes de version deviennent une lecture obligatoire avant toute mise à jour.

La surface à maintenir est plus large qu'il n'y paraît. Le projet dépend de fournisseurs de modèles externes, dont les noms de modèles et les API changent régulièrement. Il dépend aussi du Model Context Protocol, dont la spécification évolue. Une montée de version peut donc casser non pas à cause de MassGen lui-même, mais parce qu'un modèle référencé dans la configuration n'existe plus.

Sur la licence, je répète la réserve: le badge annonce Apache 2.0, les métadonnées du dépôt renvoient NOASSERTION. Apache 2.0 inclut une concession de brevet explicite, ce qui compte pour un usage commercial, mais encore faut-il que ce soit bien la licence appliquée. C'est une vérification de cinq minutes qui évite une mauvaise surprise plus tard.

Ce que le README ne dit pas

Plusieurs questions restent sans réponse dans le matériel fourni. Le nombre d'agents au-delà duquel le système cesse de progresser n'est pas indiqué. Le critère exact qui déclenche un vote n'est pas détaillé: le README parle d'agents qui estiment qu'une réponse est suffisamment solide, ce qui renvoie à un jugement du modèle lui-même et non à un seuil mesurable. Le comportement en cas de désaccord persistant, quand aucun vote ne se dégage, n'est pas décrit non plus.

Le schéma de status.json est mentionné mais pas reproduit. La documentation en ligne, à docs.massgen.ai, est citée comme ressource; c'est là qu'il faut chercher ces détails, pas dans le README. Enfin, aucun élément du matériel fourni ne permet de dire comment le système se comporte sur des tâches longues ou sur des contextes volumineux. Sur ces points, la prudence est de mise.

Conclusion éditoriale

MassGen s'adresse aux équipes qui veulent comparer plusieurs modèles frontier sur une même tâche et disposent du budget d'inférence correspondant. Il faut d'abord vérifier deux choses dans le dépôt: le fichier LICENSE, puisque l'API GitHub renvoie NOASSERTION alors que le badge du README annonce Apache 2.0, et le coût réel d'un cycle complet sur vos clés API avant de l'intégrer dans un pipeline automatisé.

Sources officielles

1. Issues
2. massgen/MassGen on GitHub
3. Project website
4. README
5. Releases