Une salle peut accueillir plusieurs agents, et ces agents n'ont pas besoin de partager le même runtime. Codex et Claude Code peuvent cohabiter dans la même salle, chacun rattaché à son propre répertoire (ou au même, tour à tour), chacun avec son propre handle et son mode de permission, tous deux encadrés par les mêmes autorisations, approbations et journaux d'audit. On choisit lequel mentionner comme on choisirait à quel collègue poser une question.
Cet article explique quand cela s'avère utile et ce qui change — c'est-à-dire moins de choses qu'on ne le pense.
Pourquoi deux runtimes
- Des atouts différents selon les tâches. Les équipes constatent souvent qu'un runtime gère mieux les gros refactorings tandis que l'autre est plus rapide sur les petits correctifs, ou l'inverse selon la base de code. Avoir les deux sous la main laisse le choix à la personne qui formule la demande.
- Quotas. Quand la limite d'un abonnement est atteinte en milieu d'après-midi, l'autre agent reste disponible. L'emprunt entre runtimes repose sur le même mécanisme que l'emprunt entre personnes. Voir emprunter un agent.
- Un second avis. Demandez à un agent de relire le diff de l'autre. Les deux sorties se retrouvent dans la même timeline.
- Des répertoires différents. Codex sur le pipeline de données, Claude Code sur l'application web, au sein d'une même salle parce que les trois mêmes personnes s'occupent des deux.
À quoi cela ressemble dans la salle
Deux agents avec des noms explicites : pipeline (Codex) et web (Claude Code), plutôt que les noms des runtimes. Les membres mentionnent l'un ou l'autre. Chaque agent conserve sa propre file d'attente séquentielle, de sorte qu'un long traitement Codex ne bloque pas une question rapide adressée à Claude Code. Chacun dispose de son propre mode de permission ; les quatre actions avec pause obligatoire s'appliquent aux deux.
Le daemon détecte les runtimes installés sur la machine et signale leurs versions ; vous choisissez le runtime au moment de créer chaque agent.
Référencer d'un agent à l'autre
Une requête peut mentionner une requête précédente par son id. « @web, apply the schema change from R-12 to the API models » fournit à l'agent Claude Code le résultat de l'agent Codex en guise de contexte. La requête référencée, sa sortie et ses artefacts sont intégrés au nouveau run ; personne n'a besoin de faire de copier-coller. Voir identifiants de requête et exécutions reprenables.
Ce qui reste identique
La salle constitue l'abstraction. Le runtime n'est qu'un détail de l'agent.
Modes de permission d'un runtime à l'autre
Les modes de Claude Code sont plan, default, acceptEdits et bypassPermissions. Codex dispose de ses propres réglages d'approbation selon une échelle similaire, de la simple suggestion à l'automatisation complète. Dans une salle, vous choisissez le niveau équivalent pour chaque agent, et les autorisations individuelles s'appliquent par-dessus. La correspondance est détaillée dans comprendre les modes de permission.
Foire aux questions
Les deux agents peuvent-ils travailler sur le même répertoire ? Oui, mais la file d'attente de chaque agent n'est séquentielle qu'en son sein. Deux agents modifiant le même dépôt en même temps risquent d'entrer en conflit. Attribuez-leur des répertoires distincts, ou acceptez de devoir parfois attendre.
Faut-il les deux abonnements ? Chaque runtime utilise le sien. muti n'héberge ni l'un ni l'autre et ne facture aucun des deux.
Quels autres runtimes sont détectés ? Cursor est implémenté et en attente de vérification ; OpenCode, DeepSeek et Hermes sont les suivants. Le modèle de salle ne change pas d'un runtime à l'autre.
Un membre peut-il voir quel runtime se trouve derrière un agent ? Oui. La carte de l'agent indique le runtime et sa version. Nommer l'agent d'après son rôle permet de fonder le choix sur la tâche, pas sur le fournisseur.
Deux agents, une salle, un ensemble de règles. Créez-leur une salle.
Publié le