Fusion — le panneau multi-modèles

Les différents modèles de pointe échouent différemment. L'un manque un cas limite qu'un autre attrape ; l'un hallucine une API que les trois autres refusent d'inventer. Fusion transforme cette diversité en fonctionnalité : lorsqu'elle est activée, chaque question posée par votre session Claude Code reçoit une réponse de plusieurs modèles à la fois, un modèle juge cartographie les points où les ébauches s'accordent, s'opposent et brillent individuellement, et une seule réponse synthétisée — ancrée dans cette analyse — est renvoyée à Claude Code comme si un seul modèle l'avait rédigée. L'agent ne sait jamais qu'un panel a été convoqué.

Fusion s'exécute entièrement dans le proxy côté hôte (voir Concepts), donc rien ne change à l'intérieur de la VM : aucun indicateur d'agent, aucun script d'encapsulation, aucune source de latence visible à laquelle l'agent pourrait réagir. Elle se configure par espace de travail dans le volet de paramètres Fusion et s'active par session grâce au bouton éclair (⚡) dans la barre de titre de la session.

Remarque : Fusion est étiquetée BETA dans l'interface. Il s'agit d'un prototype fonctionnel : le mécanisme est stable, mais les prompts du juge, les backends de fournisseurs et la gestion des échecs évoluent encore. Consultez Limitations de la version bêta avant de vous y fier.

Comment fonctionne Fusion

Fusion intercepte le trafic de la session Claude Code vers le point de terminaison /v1/messages d'Anthropic. Chaque requête est traitée par étapes :

1. Étape A — Claude répond en premier. La requête d'origine de l'invité est envoyée à Anthropic sans modification (forcée en mode non diffusé afin que la réponse complète puisse être inspectée). Votre session Claude Code est toujours l'une des étapes de la fusion.
2. Les tours d'outils passent directement. Si la réponse de Claude est un appel d'outil — le cas courant en codage agentique, où la plupart des tours sont « lire ce fichier », « exécuter cette commande » — elle est transmise à l'agent telle quelle et la fusion est ignorée pour ce tour. La boucle agentique n'est jamais interrompue par un appel d'outil synthétisé.
3. Les tours de texte se déploient. Ce n'est que lorsque Claude renvoie une réponse en texte brut que Fusion s'active. Chaque autre fournisseur sélectionné — Codex (OpenAI), Grok (xAI), et facultativement un modèle local sur l'appareil — se voit poser la même question sur la même transcription aplatie.
4. Le juge cartographie le terrain. Le modèle juge compare toutes les ébauches et émet une analyse JSON structurée — consensus, conflits, éclairages uniques, angles morts et un verdict — plutôt qu'un commentaire en prose.
5. Le juge synthétise. Le même modèle juge rédige ensuite la réponse définitive, ancrée dans l'analyse qu'il vient de produire.
6. Livraison. La réponse fusionnée est renvoyée en flux à l'agent dans la VM exactement sous la forme de fil qu'il a demandée (SSE Anthropic ou JSON). Du point de vue de Claude Code, un seul modèle a répondu.

Un échec à n'importe quelle étape se dégrade en douceur plutôt que d'interrompre la session : une étape dont l'identifiant ne peut être résolu, ou qui échoue ou expire, est silencieusement retirée de la fusion. Si moins de deux réponses subsistent, la propre réponse de Claude est renvoyée sans modification.

Tours d'outils vs. tours de texte

La distinction tour d'outil/tour de texte est ce qui rend Fusion sûre pour le travail agentique. Les actions (appels d'outils) sont exécutées exactement telles que Claude les a émises ; seules les réponses — explications, conceptions, revues, plans — sont fusionnées. Dans une session de codage typique, la plupart des tours sont des actions, de sorte que l'influence de Fusion se concentre là où la diversité des modèles compte le plus : le raisonnement et les conclusions, et non les modifications mécaniques de fichiers.

D'où provient l'identité de chaque étape

Fusion n'a pas d'interface d'identifiants propre. Chaque étape résout l'identifiant que l'onglet Agents de l'espace de travail détient déjà pour ce fournisseur :

• Mode abonnement — l'étape utilise un jeton OAuth actif issu du magasin d'abonnements de l'hôte ; l'hôte le rafraîchit selon les besoins. Les jetons d'abonnement Claude reçoivent automatiquement le bloc d'identité système Claude Code et l'en-tête bêta OAuth exigés par Anthropic.
• Mode jeton API — l'étape utilise la véritable clé API issue de la table d'échange de jetons côté hôte (l'invité n'a jamais vu qu'un leurre ; voir Identifiants).
• Modèle local — l'étape cible le moteur d'inférence sur l'hôte avec sa clé interne (voir Inférence locale et hybride).
• Bedrock (AWS) — un agent Claude en mode Bedrock ne contribue qu'à travers la propre requête de l'invité ; il n'y a pas d'étape de fusion Bedrock distincte.

Une étape dont l'identifiant ne peut être résolu est retirée avec une ligne de journal, jamais avec une erreur exposée à l'agent.

Prérequis

Fusion a besoin d'au moins deux modèles utilisables :

• Votre session Claude Code compte toujours comme une étape, à condition que l'agent Claude Code dispose d'un identifiant utilisable.
• Chaque étape cloud supplémentaire — Codex (OpenAI), Grok (xAI) — a besoin que son identifiant soit configuré dans l'onglet Agents de l'espace de travail. Jusque-là, sa ligne dans le volet Fusion est grisée avec l'indication — aucun identifiant cloud (configurez-le dans Agents).
• L'étape Modèle local a besoin qu'au moins un modèle soit téléchargé dans le volet Modèles locaux. Jusque-là, sa ligne affiche — téléchargez-en un dans Modèles locaux.

Avec moins de deux modèles utilisables sélectionnés, le volet affiche le texte d'aide « Choisissez au moins deux modèles à fusionner — votre session Claude Code en compte pour un, alors ajoutez-en un de plus (un agent cloud ou un modèle local). » et le bouton éclair de la session reste désactivé.

Configurer Fusion pour un espace de travail

Fusion se configure dans le volet Fusion de la fenêtre Modifier l'espace de travail (l'icône éclair jaune dans la barre latérale, marquée BETA). La référence champ par champ se trouve dans Paramètres de Fusion ; cette section parcourt le flux de travail.

Dans la capture d'écran ci-dessus, aucun identifiant d'agent n'est encore configuré, de sorte que chaque ligne sous Modèles à fusionner est grisée et le texte d'aide orange explique ce qui manque. Une fois que l'onglet Agents détient des identifiants, les lignes deviennent sélectionnables.

1. Ouvrez l'espace de travail dans le navigateur d'espaces de travail et cliquez sur Modifier l'espace de travail, puis sélectionnez le volet Fusion.
2. Sous Modèles à fusionner, cochez les fournisseurs dont vous voulez les réponses dans le panneau. Claude Code (Anthropic) — votre session est toujours une étape ; ajoutez Codex (OpenAI), Grok (xAI) et/ou Modèle local. La ligne Modèle local comprend un sélecteur des modèles locaux installés.
3. Sous Juge, choisissez le Fournisseur et le Modèle qui pèseront les ébauches et rédigeront la réponse finale. La liste des fournisseurs propose chaque fournisseur cloud disposant d'un identifiant utilisable, plus Local lorsqu'au moins un modèle local est installé. Les listes de modèles cloud sont récupérées en direct depuis le point de terminaison /v1/models du fournisseur et incluent une entrée (default) ; si la récupération échoue, une petite liste intégrée est proposée à la place. Un juge local choisit parmi les modèles du catalogue installés.
4. Cliquez sur Enregistrer.

Lorsque le modèle d'une étape n'est pas épinglé explicitement, les valeurs par défaut sont : Claude → claude-opus-4-8 ; Codex → gpt-5.5 sur un abonnement ou gpt-5.5-2026-04-23 avec une clé API ; Grok → grok-build.

Astuce : Un modèle local constitue une étape supplémentaire performante et à coût marginal nul — et le juge lui-même peut s'exécuter localement, gardant toute l'étape d'analyse et de synthèse sur votre Mac. Voir Inférence locale et hybride.

Activer Fusion dans une session

Configurer le volet ne rend Fusion que disponible. Chaque session décide de l'utiliser ou non, via le bouton éclair (⚡) dans la barre de titre de la fenêtre de session :

Cliquez sur l'éclair pour basculer. Les nouvelles sessions démarrent toujours désengagées — Fusion est un choix explicite, par session, jamais une valeur par défaut silencieuse.

Depuis la ligne de commande

Avec l'application en cours d'exécution, vous pouvez basculer Fusion sur une VM active sans toucher à la fenêtre :

bromure-cli vm fusion enable <vm>
bromure-cli vm fusion disable <vm>

<vm> est un id de VM ou un nom d'espace de travail, et on/off/engage/disengage sont acceptés comme alias. La sortie de statut de bromure-cli vm inclut une ligne fusion indiquant engaged ou available (off). Ces commandes communiquent avec l'API de contrôle de l'application, elles nécessitent donc que l'application (ou son agent) soit en cours d'exécution ; voir Automatisation et CLI.

Ce que coûte Fusion

Fusion multiplie l'utilisation des modèles, et vous devriez l'activer en connaissant l'arithmétique. Pour chaque tour où Claude renvoie une réponse en texte brut :

• Chaque étape sélectionnée supplémentaire effectue un appel de modèle complet, recevant la même transcription aplatie comme contexte — de sorte que les longues conversations coûtent proportionnellement sur chaque étape, à chaque tour fusionné.
• Le juge effectue deux appels de plus : un pour produire l'analyse JSON, un pour rédiger la synthèse. Les deux sont plafonnés à 4 096 jetons de sortie.

Avec les quatre étapes sélectionnées, une seule réponse fusionnée coûte donc jusqu'à cinq appels de modèle en plus de l'appel Claude que vous faisiez déjà. Les tours d'appel d'outil se déploient en zéro appel supplémentaire, ce qui en pratique rend les sessions agentiques bien moins coûteuses que le pire cas — la plupart des tours dans une boucle de codage sont des appels d'outils.

La façon dont chaque étape est facturée suit son identifiant : les étapes à clé API sont facturées au jeton, les étapes d'abonnement puisent dans le quota de l'abonnement, et une étape locale ne coûte que du calcul sur l'appareil (et de la batterie, sur un ordinateur portable). Chaque étape a un délai d'attente en amont de 600 secondes par défaut.

Fusion dans la trace

Fusion est délibérément invisible pour l'agent mais entièrement visible pour vous. Chaque appel secondaire en amont — chaque étape, l'analyse du juge et la synthèse — est capturé par le pipeline de traces comme tout autre échange IA, sous réserve du niveau de trace de l'espace de travail (voir Traçage).

Conséquences pratiques :

• L'Inspecteur de traces (menu Fenêtre → Inspecteur de traces…) répertorie les échanges supplémentaires aux côtés du trafic normal de la session, et restitue les requêtes et réponses capturées sous forme de conversations analysées — vous pouvez lire exactement ce que chaque étape a répondu et ce que le juge a conclu.
• bromure-cli trace hostnames montre que des hôtes tels que api.openai.com ont été contactés depuis une session que vous pensiez peut-être exclusivement Anthropic. Si votre organisation audite le trafic sortant, attendez-vous à ce que les sessions fusionnées affichent les points de terminaison de chaque fournisseur sélectionné.
• Fusion journalise également de façon verbeuse dans le stderr de l'application avec un préfixe [fusion] — utile pour diagnostiquer pourquoi une étape a été retirée.

Remarque : Si les règles de traitement des données de votre espace de travail restreignent quels fournisseurs peuvent voir votre code, rappelez-vous que chaque étape sélectionnée reçoit la transcription aplatie complète de la conversation. Sélectionnez les étapes en conséquence.

Substitutions d'environnement

Quelques valeurs par défaut peuvent être remplacées par des variables d'environnement au lancement de l'application — utile pour l'expérimentation, non destiné à une configuration quotidienne :

Limitations de la version bêta

Fusion est une fonctionnalité bêta dont les aspérités méritent d'être connues :

• Sessions Claude Code uniquement. Fusion intercepte les requêtes POST /v1/messages d'Anthropic. Les sessions exécutant Codex ou Grok comme agent principal ne sont pas fusionnées — le trafic de ces agents passe normalement.
• Les étapes non-Claude répondent sans outils. Les définitions d'outils sont abandonnées pour les étapes Codex, Grok et locale ; elles répondent en prose sur une transcription aplatie. Leurs ébauches nourrissent la synthèse mais ne peuvent pas elles-mêmes entreprendre d'actions.
• Backends d'abonnement au mieux. L'étape d'abonnement Codex circule sur le backend ChatGPT via WebSocket, et l'étape d'abonnement Grok utilise cli-chat-proxy.grok.com — deux interfaces non documentées. En cas d'erreur, l'étape est retirée plutôt que de faire échouer la fusion.
• Dégradation silencieuse. Les étapes retirées et les échecs du juge se replient sur la propre réponse de Claude (ou une ébauche brute) sans alerter l'agent. La trace et le journal stderr [fusion] sont les seuls endroits où vous verrez que cela s'est produit.
• Latence. Un tour de texte fusionné attend l'étape survivante la plus lente, puis deux appels de juge. Attendez-vous à des tours de réponse nettement plus lents qu'une session simple ; les tours d'outils ne sont pas affectés.