AIREITERUne tâche de développement peut sembler triviale jusqu’à ce qu’une dépendance entre plusieurs fichiers vienne compliquer la donne. Project HydraFusion sélectionne le workflow qui devrait atteindre le niveau de qualité attendu, mais cette preview de recherche ne révèle toujours pas le chemin exact et ne garantit pas les mêmes économies sur tous les dépôts.
Le routage en un coup d’œil
Project HydraFusion est une couche d’orchestration à l’exécution intégrée à GitHub Copilot CLI, pas un nouveau modèle de fondation. Vous sélectionnez HydraFusion (Research Preview) ; le runtime choisit ensuite les modèles et le mode d’exécution.
| Workflow | séquence d’exécution | Principal avantage | Principal compromis |
|---|---|---|---|
| Single | Un seul modèle sélectionné traite directement la tâche. | Le moins de surcoût d’orchestration et le chemin de latence le plus simple. | Aucune escalade ni revue indépendante intégrée. |
| Cascade | Un modèle efficace prépare une première réponse ; une barrière de qualité l’accepte ou transmet la tâche à un modèle plus puissant. | Évite de mobiliser le modèle le plus puissant lorsque le premier passage suffit. | Un échec du contrôle peut ajouter des appels de modèle, des tokens et du temps d’attente. |
| Critique | Un modèle prépare une réponse ; un critique indépendant issu d’une autre famille de modèles la relit en lecture seule ; le solveur la révise une fois. | Apporte un second regard pour les modifications susceptibles de contenir des erreurs. | Ajoute du travail séquentiel, et le critique ne peut ni utiliser les outils ni modifier le dépôt. |
Pour essayer la preview, exécutez /update, puis /experimental on, puis /model, et sélectionnez HydraFusion (Research Preview). GitHub décrit cette séquence dans son annonce officielle de HydraFusion. La preview est accessible avec tous les forfaits Copilot, même si l’accès géré par une organisation peut dépendre de la politique Copilot CLI activée par un administrateur.
Il s’agit de modes d’exécution, pas de trois commandes publiques permettant de forcer manuellement le traitement d’une requête. La documentation de lancement explique que l’on sélectionne HydraFusion et que le runtime arbitre entre performances, coût et latence.
Ce que le runtime cherche à anticiper
GitHub indique que HydraFusion s’appuie sur des signaux de capacité liés au raisonnement, à la génération de code, au débogage et à l’utilisation des outils. Il choisit le mode d’exécution le plus efficace qui devrait atteindre le niveau de qualité requis pour la demande. En revanche, GitHub ne publie ni les seuils ni une règle déterministe du type « trois fichiers égalent Cascade ».
La nature de la tâche sert donc de repère, pas de garantie de routage : une modification ciblée avec un parcours de test évident se prête théoriquement à Single ; une demande potentiellement complexe correspond à l’escalade sélective de Cascade ; et un changement qui gagnerait à être relu indépendamment peut relever de Critique. L’annonce ne fournit ni liste fixe de modèles pour chaque requête ni trace de routage lisible.
Peut-on forcer Single, Cascade ou Critique ?
GitHub documente la sélection de HydraFusion et laisse son runtime choisir le workflow ; aucune commande publique permettant d’imposer l’un des trois modes n’est documentée. Utilisez un modèle Copilot fixe lorsque vous avez besoin d’un routage prévisible.
Quand chaque workflow justifie un appel supplémentaire
Single : exécuter directement quand le chemin est évident
Single fait passer la tâche par un seul solveur, dans la boucle d’agent habituelle de Copilot, avec prise en compte des permissions. Ce mode convient à une petite modification bien définie, à une explication courte ou à un correctif dont l’implémentation et le parcours de test sont clairs.
Son avantage tient à un profil de coût et de latence plus simple. Le workflow n’ajoute volontairement ni barrière de qualité ni second avis ; le développeur reste donc le principal relecteur si le solveur interprète mal la demande.
Cascade : n’escalader que si le premier passage échoue
Cascade commence par un modèle efficace. Une barrière de qualité évalue la proposition et peut transmettre la tâche à un modèle plus puissant si elle n’atteint pas le niveau attendu.
La logique économique est conditionnelle :
- Le premier modèle traite les tâches qu’il peut accomplir correctement.
- La barrière de qualité filtre les propositions faibles ou incertaines.
- Seules les tâches qui nécessitent davantage de capacités empruntent le chemin renforcé.
Cette approche peut réduire le coût moyen du workflow par rapport à l’envoi systématique de chaque tâche vers un modèle de pointe. Une escalade, une nouvelle tentative ou un fallback peut toutefois rendre la fin de distribution plus coûteuse et plus lente, et GitHub n’a pas publié de taux d’escalade universel pour la planification propre à chaque dépôt.
Critique : payer pour un second regard
Critique fonctionne selon une boucle rédaction-relecture-révision. Le premier solveur produit le résultat, un critique issu d’une autre famille de modèles le relit dans un contexte isolé, sans outils et en lecture seule, puis le solveur initial effectue une révision.
Le critique ne peut pas lancer les tests du projet, inspecter un fichier généré à l’aide d’une commande ni appliquer lui-même une correction. Critique apporte donc une diversité de points de vue, pas une implémentation indépendante de bout en bout.
Le bilan des benchmarks : réduire le coût ne garantit pas un niveau de qualité unique
GitHub a évalué des politiques HydraFusion fixes face à Claude Opus 5 sur trois benchmarks de développement agentique. Les chiffres ci-dessous proviennent de l’annonce officielle de GitHub.
| Benchmark | Qualité de HydraFusion par rapport à Claude Opus 5 | Coût estimé du workflow par rapport à Claude Opus 5 | Lecture pratique |
|---|---|---|---|
| TerminalBench 2.1 | +4,9 points de pourcentage | 67 % inférieur | Une meilleure qualité vérifiée pour les tâches, à un coût estimé inférieur dans cette évaluation. |
| DeepSWE | −1,5 point | 36 % inférieur | Une économie significative, avec une concession mesurable sur la qualité pour les tâches difficiles sur dépôt. |
| CheckpointBench | −0,1 point | 65 % inférieur | Une qualité presque équivalente pour un coût estimé nettement inférieur. |
La diversité des résultats en matière de qualité est justement le point à retenir : HydraFusion est conçu pour ajouter de l’inférence lorsque le gain de qualité attendu justifie le coût et la latence, pas pour utiliser davantage de modèles à chaque requête.
GitHub précise que l’évaluation conservait les mêmes entrées, outils, limites d’exécution, tarifs et méthodes de notation, tout en comptabilisant les étapes de rédaction, critique, révision, escalade, nouvelle tentative et fallback. Il s’agit néanmoins d’estimations contrôlées hors ligne, liées aux politiques évaluées, au pool de modèles, aux versions des benchmarks et aux hypothèses tarifaires.
Ces chiffres ne permettent pas d’affirmer qu’une tâche Copilot classique coûtera 67 % de moins, ni que HydraFusion surpassera Claude Opus 5 dans un dépôt donné. Pour tester la preview sur des tâches réelles, GitHub recommande de commencer par des tâches de développement substantielles, bien délimitées et réalisables dans un seul prompt.
L’équation du coût comporte trois variables
Pour évaluer HydraFusion, distinguez le coût attendu en tokens, le coût dans les cas les plus longs et le temps d’attente.
| Facteur | Single | Cascade | Critique |
|---|---|---|---|
| Travail initial | Un solveur | Un solveur efficace en premier | Un solveur chargé de la rédaction en premier |
| Travail supplémentaire | Aucun par conception | Un modèle plus puissant après l’échec du contrôle | Un critique, puis une révision par le solveur |
| Profil de coût | Plus prévisible | Conditionnel ; augmente en cas d’escalade ou de nouvelle tentative | Structurellement supérieur à une rédaction directe |
| Profil de latence | Le chemin le plus simple | Court si la réponse est acceptée ; plus long après une escalade | La relecture et la révision prolongent le traitement |
| Mécanisme de qualité | Capacités du solveur | Barrière de qualité et escalade | Relecture indépendante et révision |
Un coût de workflow estimé inférieur ne signifie pas automatiquement une réponse plus rapide : Cascade peut ralentir les cas qui sont escaladés, Critique ajoute une relecture séquentielle, tandis que Single répond rapidement en laissant davantage de validation au développeur.
La documentation d’utilisation de Copilot CLI indique que /usage affiche la durée de la session, les AI Credits consommés, les lignes modifiées et le détail de l’utilisation des tokens par modèle. Ces informations permettent de comparer des tâches réelles, mais elles n’expliquent pas chaque décision de routage et ne montrent pas les brouillons intermédiaires écartés.
La boîte noire entre le prompt et le patch
GitHub décrit une comptabilisation complète des différentes étapes du workflow, une exécution limitée avec gestion des délais d’expiration et des annulations, une relecture isolée, un routage validé et une application sécurisée du patch après l’invalidation ou l’annulation d’un workflow. Ces contrôles réduisent le risque opérationnel ; ils ne prouvent ni que le chemin choisi ni que le code final sont corrects.
GitHub précise également que la preview conserve les brouillons intermédiaires jusqu’à pouvoir renvoyer un résultat cohérent. Il devient donc difficile de savoir si une tâche est restée dans Single, si elle a été escaladée par Cascade ou si elle est passée par Critique et une révision.
Un utilisateur réel a pointé directement cette lacune d’observabilité :
« La prochaine fonctionnalité que j’aimerais voir serait une trace lisible indiquant quel modèle a fait quoi et pourquoi le routeur a changé de modèle. » — @_Mazzana sur X
Sans reçu de routage, les développeurs ne peuvent pas relier complètement le coût, la latence et le patch final d’une tâche au workflow qui les a produits.
Tester la preview sans lui faire dire plus qu’elle ne dit
Considérez HydraFusion comme une expérience avant d’en faire le choix par défaut de l’équipe :
- Créez une branche ou un worktree propre et notez le commit de départ.
- Testez un correctif courant, une modification répartie sur plusieurs fichiers et une tâche ambiguë avec un contrôle d’acceptation reproductible.
- Indiquez dès le premier prompt le comportement attendu, les contraintes et les commandes de test.
- Inspectez le diff final, vérifiez qu’aucun fichier sans rapport n’a été modifié et exécutez vous-même les tests concernés.
- Notez la durée de la session, la consommation visible d’AI Credits ou de tokens, le résultat des tests et tout signal visible de nouvelle tentative ou d’escalade.
- Répétez l’expérience sur plusieurs tâches avant de comparer HydraFusion à un modèle fixe.
Ne déduisez pas le mode caché de la seule longueur de la réponse. Une réponse longue peut refléter la complexité du dépôt plutôt que l’utilisation de Critique. Conservez un modèle fixe de secours pour les tâches longues, les échanges en plusieurs tours, les cas sensibles à la latence ou les changements à fort enjeu : GitHub recommande actuellement des tâches réalisables au premier tour et présente l’amélioration des performances en conversation multi-tour comme un axe futur dans ses consignes de lancement.
FAQ HydraFusion
Puis-je sélectionner manuellement Single, Cascade ou Critique ?
Pas via une commande de mode HydraFusion documentée. Pour l’instant, il faut sélectionner HydraFusion et laisser son runtime choisir ; utilisez un modèle fixe lorsque vous avez besoin d’un routage déterministe.
Comment HydraFusion est-il facturé ?
GitHub indique que l’utilisation dépend des tokens consommés par les modèles utilisés par HydraFusion, facturés au tarif standard de chaque modèle, comme l’explique l’annonce officielle. Une réduction observée sur un benchmark ne constitue pas une remise universelle pour les clients, et un workflow en plusieurs étapes peut consommer davantage qu’une requête directe.
HydraFusion est particulièrement intéressant lorsqu’une tâche est assez importante pour bénéficier d’une escalade ou d’une relecture sélective, tout en restant suffisamment structurée pour être vérifiée. Pour les demandes rapides, la simplicité de Single peut compter davantage ; pour les travaux longs ou critiques, le comportement prévisible d’un modèle fixe peut rester le meilleur choix opérationnel tant que les données de votre dépôt ne justifient pas une orchestration supplémentaire.