C'est quoi un Council ?
Quand vous posez une question difficile à un seul modèle, vous obtenez un seul angle. Si ce modèle a un biais sur le sujet, vous héritez du biais sans le savoir. L'idée d'un conseil de LLM est simple : réunir plusieurs avis, les confronter, puis trancher.
Le pattern vient d'Andrej Karpathy, qui a publié le repo karpathy/llm-council le 22 novembre 2025. Il le décrit lui-même comme du code « 99% vibe coded as a fun Saturday hack » : une app web locale qu'il a montée en une après-midi pour lire des livres en comparant plusieurs LLM côte à côte. Le repo a explosé (au 2026-06-02, environ 19 900 étoiles et 3 760 forks, chiffres à re-vérifier sur GitHub car ils bougent vite), mais il reste un prototype personnel.
Le workflow se déroule en trois temps. Les noms et le comportement ci-dessous sont repris directement du README du repo.
First opinions
Votre question part vers chaque modèle du council, individuellement. Chacun répond sans voir les autres. Vous récupérez autant de réponses brutes que de conseillers, affichées côte à côte. C'est déjà utile en soi : voir plusieurs réponses indépendantes révèle vite les points de consensus et les points de friction.
Review (anonymisée)
Chaque modèle reçoit ensuite les réponses des autres, mais les identités sont masquées. Personne ne sait qui a écrit quoi. Cet anonymat est volontaire : il empêche un modèle de se favoriser lui-même ou de privilégier une marque. Chaque conseiller classe alors les réponses sur deux axes, l'exactitude et la profondeur d'analyse.
Final response
Un modèle désigné, le Chairman, reçoit toutes les réponses et tous les classements, puis rédige une synthèse unique. C'est cette réponse finale qui vous est présentée. Le Chairman ne se contente pas de recopier le meilleur avis : il arbitre les désaccords et combine ce qui tient la route.
Détail qui compte pour un site « Claude » : dans la version d'origine, Claude n'est qu'un conseiller parmi quatre, et c'est Gemini qui préside. Voici la configuration par défaut, copiée verbatim depuis backend/config.py :
COUNCIL_MODELS = ["openai/gpt-5.1","google/gemini-3-pro-preview","anthropic/claude-sonnet-4.5","x-ai/grok-4",]CHAIRMAN_MODEL = "google/gemini-3-pro-preview"
Les identifiants sont au format OpenRouter, car le repo route tous les appels via OpenRouter (ouvre un nouvel onglet) (une clé API, plusieurs providers). Côté stack, c'est du FastAPI (Python 3.10+) avec httpx pour le backend, du React + Vite pour le front, et un stockage en fichiers JSON. Rien d'hébergé : c'est une app locale que vous lancez sur votre machine.
Multi-modèles ou multi-personas ?
Le mot « Council » recouvre deux montages très différents. Les confondre est l'erreur classique, alors posons-les côte à côte.
| Approche | Principe | Forces | Limites |
|---|---|---|---|
| Multi-modèles (façon Karpathy) | N modèles de providers différents (GPT, Gemini, Claude, Grok) délibèrent | Vraie diversité d'angles, biais décorrélés entre modèles | Coût et latence (N providers), clé OpenRouter, qualité inégale d'un modèle à l'autre |
| Multi-personas d'un seul Claude | Un seul Claude joue plusieurs rôles qui se contredisent | Simple (un seul provider, une seule clé), reproductible, empaquetable en skill | Biais corrélés (même modèle dessous), risque d'écho plutôt que de vraie contradiction |
Sur Claude, on fait le plus souvent du multi-personas : on demande au même modèle d'incarner tour à tour un sceptique, un optimiste, un expert du domaine, puis de jouer le Chairman. C'est plus simple à mettre en place et ça tient dans un seul prompt ou un seul skill. En échange, vous perdez la vraie indépendance des avis : comme c'est le même cerveau derrière chaque persona, les angles morts sont partagés. Un persona « contrarian » bien écrit aide, mais il ne remplace pas un modèle entraîné différemment.
Le multi-modèles offre une diversité plus authentique, au prix d'une stack à monter et d'une facture qui se multiplie. À vous de choisir selon l'enjeu.
Anatomie d'un council
Un council, qu'il soit multi-modèles ou multi-personas, repose sur trois ingrédients.
Les conseillers. En multi-modèles, ce sont des modèles distincts. En multi-personas, ce sont des rôles que vous définissez. À titre d'illustration, vous pourriez imaginer un panel comme un sceptique qui cherche les failles, un partisan qui défend l'option, un praticien qui pense à l'exécution concrète, et un généraliste qui prend de la hauteur. Ce ne sont que des exemples : les bons personas dépendent entièrement de votre question. Trois à cinq suffisent presque toujours.
La review croisée anonymisée. C'est l'étape qui distingue un vrai council d'un simple « pose la question trois fois ». Chaque avis est soumis aux autres sans étiquette d'auteur, et chacun doit le juger sur le fond. L'anonymat évite la complaisance.
Le Chairman. Il a le dernier mot. Son travail n'est pas de voter, mais de synthétiser : repérer les accords, expliciter les désaccords, et produire une recommandation argumentée. En multi-personas, c'est souvent le même Claude qui change de casquette une dernière fois.
Démo : le générateur
Plutôt que de copier du code FastAPI, voici un générateur qui produit le texte dont vous avez besoin. Choisissez le mode, le nombre de conseillers, leurs personas et le Chairman : vous obtenez un prompt prêt à coller dans Claude, et un squelette SKILL.md si vous voulez en faire un skill réutilisable. Tout se passe dans votre navigateur, aucun appel n'est envoyé nulle part.
Générateur de Council
Choisissez le mode, les conseillers et le Chairman. Tout est généré dans votre navigateur, aucun appel n'est envoyé.
Tu vas jouer un conseil de plusieurs experts qui délibèrent sur ma question. Incarne tour à tour chaque rôle ci-dessous, puis fais la synthèse en tant que Chairman.
## Les conseillers
1. Sceptique : cherche les failles, les risques et les hypothèses non vérifiées.
2. Partisan : défend l'option la plus prometteuse et en montre la valeur.
3. Praticien : pense à l'exécution concrète, aux coûts et aux contraintes réelles.
## Étape 1 : Premiers avis
Chaque conseiller répond à la question de façon indépendante, sans voir les réponses des autres.
## Étape 2 : Revue croisée (anonymisée)
Présente à chaque conseiller les autres réponses sans révéler leurs auteurs, et demande-lui de les classer sur l'exactitude et la profondeur.
## Étape 3 : Synthèse finale
Le Chairman désigné est : Sceptique.
Le Chairman lit tous les avis et tous les classements, arbitre les désaccords et produit une recommandation unique et argumentée.
## Question
(remplacez par votre question)Le prompt généré convient pour un usage ponctuel : vous le collez, Claude joue les rôles dans une seule conversation. Le SKILL.md, lui, sert quand vous voulez déclencher ce comportement de façon répétée, sans recoller le prompt à chaque fois. Pour comprendre comment Claude charge un skill, voyez Qu'est-ce qu'un skill ?.
Quand l'utiliser, quand c'est du gâchis
Un council coûte cher. Comptez de l'ordre de 2N + 1 appels par question (N réponses initiales, N reviews croisées, 1 synthèse du Chairman). Pour quatre conseillers, ça fait neuf appels là où une question simple en demande un. La latence suit la même courbe.
Ce surcoût ne se justifie que face à un vrai enjeu, sans bonne réponse évidente, où plusieurs angles éclairent vraiment la décision.
Prochaines étapes
- Qu'est-ce qu'un skill ? pour comprendre comment empaqueter ce pattern et le déclencher automatiquement.
- find-skills pour vérifier si quelqu'un a déjà publié un skill de council avant d'écrire le vôtre.
- Orchestrer des agents si vous voulez aller plus loin que le prompt unique et faire tourner les conseillers comme des agents distincts.