Le sélecteur de modèles devient un sélecteur d’orchestration

GitHub a fait sortir HydraFusion de la ligne de commande pour l’intégrer à l’éditeur le 30 septembre. L’aperçu de recherche s’exécute désormais dans VS Code 1.140 et versions ultérieures, ainsi que dans l’application GitHub Copilot, ce qui place une idée assez inhabituelle devant les développeurs ordinaires : cessez de choisir un modèle, choisissez un workflow.

HydraFusion n’est pas un modèle. C’est une couche qui décide, à chaque tour, combien de rôles de modèle la tâche nécessite.

Trois formes pour une même requête

Single est le cas familier. Un seul modèle traite la requête, comme le fait déjà Copilot Auto.

Cascade commence à moindre coût. Un modèle efficace rédige une première version, et un contrôle qualité l’accepte ou escalade le travail vers un modèle plus puissant. L’objectif est de garder les modifications de routine sur des modèles peu coûteux et de réserver les modèles onéreux aux problèmes qui en ont réellement besoin.

Critique dépense plus pour être plus sûr. Un modèle rédige, un second modèle d’une famille différente joue le rôle de critique en lecture seule, et le modèle rédacteur révise une fois en fonction de ces retours. Le critique ne touche jamais au code, ce qui évite que la boucle ne se transforme en deux modèles qui se disputent.

La différence avec Auto est architecturale. Auto décide quel modèle unique doit recevoir votre invite. HydraFusion décide combien de rôles le tour nécessite et comment ils interagissent. C’est un changement significatif dans l’endroit où réside le contrôle de l’intelligence. Historiquement, vous choisissiez un modèle parce qu’il était meilleur pour votre type de travail. Ici, vous choisissez une politique d’optimisation et laissez la plateforme composer les modèles en dessous.

L’économie est réelle, et aussi auto-déclarée

Le piège, c’est la facturation. GitHub facture au token, au tarif standard de chaque modèle sélectionné. Une exécution Critique appelle au moins deux modèles, elle peut donc coûter plus cher par requête qu’un appel unique. Cascade est conçu pour coûter moins cher en poussant le travail facile vers le bas. L’économie n’est pas une remise sur un modèle. C’est le pari que la plupart des tours n’ont pas besoin du meilleur.

Les évaluations contrôlées de GitHub ont rapporté des réductions de coût de workflow de 36 à 67 % par rapport à sa référence Claude Opus 5 sur trois benchmarks d’agents de codage, avec une qualité supérieure de 4,9 points de pourcentage sur TerminalBench 2.1, inférieure de 1,5 point sur DeepSWE et inférieure de 0,1 point sur CheckpointBench. Ce sont des chiffres produits par l’éditeur sur sa propre configuration de test. Ils constituent une hypothèse concernant votre dépôt, pas une garantie, et le vivier de modèles participant à HydraFusion n’a pas été entièrement publié. Tout ce qui est construit sur l’aperçu doit considérer le comportement de routage comme susceptible de changer sans préavis.

Il y a aussi un coût de latence évident. Une ébauche plus une revue prend plus de temps qu’une seule réponse. Les équipes sur les offres Business et Enterprise doivent surveiller de près les tableaux de bord d’utilisation, car le système décide quand escalader et cette décision n’est pas gratuite.

Une optimisation que vous ne pouvez pas inspecter inspire difficilement confiance

La partie délicate du routage, c’est que ce qui prend la décision est la plateforme, pas le développeur. Vous pouvez voir quel modèle a répondu après coup, mais vous ne pouvez pas facilement voir pourquoi le système a choisi un workflow, ce que le contrôle qualité a mesuré, ni à quel point une exécution Cascade était proche d’escalader. Les affirmations de benchmark de GitHub décrivent une moyenne sur son propre ensemble de tests, et les moyennes masquent les cas qui comptent.

Cet écart transforme l’orchestration en problème de gouvernance plutôt qu’en problème purement technique. Une équipe d’ingénierie qui doit expliquer pourquoi une pull request donnée a été examinée par deux familles de modèles et facturée en conséquence a besoin de télémétrie de routage, et l’aperçu ne l’expose pas encore. Le remède n’est pas d’éviter la fonctionnalité. Il est de la tester comme vous testeriez toute dépendance dont les rouages sont cachés : sur un ensemble fixe et banal de tâches de dépôt, en mesurant le coût des tâches terminées par rapport à un seul modèle de pointe, et en surveillant les nouvelles tentatives et l’effort de revue plutôt que le prix affiché d’une sélection.

La comparaison avec Auto vaut la peine d’être retenue. Auto répond à la question de savoir quel modèle est le mieux adapté à une invite. HydraFusion répond à la question de savoir combien de processus un tour mérite, et le processus a toujours été la partie coûteuse du travail logiciel.

L’effet secondaire curieux est que cela rend le choix du modèle moins émotionnel. Les développeurs s’attachent à certains modèles, et ces attachements reposent généralement sur une poignée de succès mémorables. Un système qui route selon le type de tâche et escalade en cas d’échec reconnaît discrètement qu’aucun modèle unique ne gagne dans toutes les catégories, ce qui est vrai depuis un moment et rarement pris en compte.

La prochaine zone de l’éditeur est conçue pour cela

La version Insiders montre déjà la suite. Une fonctionnalité appelée Compare Agents, étiquetée Run Multiple Agents, envoie une invite à plusieurs agents en parallèle, chacun dans son propre worktree git, puis charge un agent arbitre de choisir un gagnant ou de remettre la présélection à une personne.

Le détail intéressant est ce que l’arbitre examine. Il compare les fichiers modifiés et les statistiques de diff, les résultats de tests, l’état de compilation, les diagnostics, le timing et les différences architecturales. Il exécute la suite de tests. Il ne demande pas à un autre modèle de langage de lire le code et de deviner. C’est une petite décision aux grandes conséquences, car elle signifie que la comparaison s’appuie sur l’état réel du projet plutôt que sur l’opinion qu’un modèle en a.

Le reste de la même version est une infrastructure plus discrète qui ne devient importante qu’une fois les agents exécutés en parallèle. Les sessions multi-dossiers permettent à chaque conversation d’une même session d’utiliser son propre dossier ou worktree, afin que les modifications cessent d’entrer en collision. La délégation à distance confie une tâche à un hôte d’agent distant connecté. Les dossiers worktree partagés réutilisent les répertoires ignorés pour éviter de réinstaller les dépendances à chaque branche. Les Dev Containers s’arrêtent désormais après cinq minutes d’inactivité et redémarrent à la demande.

La gouvernance continue d’arriver dans les mêmes commits que les fonctionnalités

La moitié de la version tournée vers l’informatique n’est pas un ajout après coup. Lorsque les fonctionnalités d’IA sont indisponibles, l’éditeur indique désormais la version minimale requise au lieu d’une invite générique de mise à jour. Les administrateurs peuvent définir un niveau par défaut pour le modèle Auto. Un nouveau paramètre OpenTelemetry associe l’utilisation de Copilot à des développeurs individuels.

Lisez ces trois éléments ensemble et la logique est claire. Une plateforme qui coordonne plusieurs modèles sur plusieurs tours génère des coûts, de la télémétrie et des questions de permissions qu’une autocomplétion mono-modèle n’a jamais suscités. L’attribution des coûts cesse d’être une curiosité financière et devient un prérequis pour laisser cette fonctionnalité s’approcher de la production.

La revue multi-modèles est une pratique courante chez les équipes d’ingénierie rigoureuses depuis un moment. Vous demandez à un modèle d’écrire et à un autre de chercher les erreurs, ou vous essayez d’abord un modèle rapide et escaladez lorsque le résultat déçoit. HydraFusion reprend cette habitude et la rend automatique, ce qui est pratique et supprime aussi une décision que certaines équipes aimaient prendre à la main.

Combien de temps une fonctionnalité d’aperçu doit-elle rester un aperçu ? C’est une question légitime. Les outils arrivent plus vite que la politique qui les entoure, et la prévisibilité des prix est la première victime. Une exécution Critique qui appelle discrètement deux modèles de pointe sur un grand dépôt peut dépenser de l’argent réel avant que quiconque ne s’en aperçoive. Que HydraFusion passe un jour au statut de fonctionnalité par défaut dépend moins de l’efficacité du routage que de la capacité de GitHub à rendre la facture suffisamment lisible pour que quelqu’un puisse la signer.