GitHub ha reso disponibile in anteprima di ricerca Project HydraFusion, un sistema di orchestrazione multi-modello integrato in Copilot CLI che decide in tempo reale come eseguire ciascuna richiesta di coding invece di inviarla automaticamente a un singolo modello selezionato in anticipo. Il nome deriva da HyDRA, Hybrid Dynamic Routing Architecture, un’architettura di routing sviluppata dai ricercatori Microsoft. HydraFusion è già accessibile agli sviluppatori su tutti i piani Copilot attivando il flag /experimental nella CLI, mentre il consumo viene contabilizzato secondo le normali tariffe per token dei modelli effettivamente utilizzati. Nei test pubblicati da GitHub il sistema ha ridotto il costo stimato in tutti e tre i benchmark esaminati, arrivando nel caso migliore a una riduzione del 67% rispetto all’impiego esclusivo di Claude Opus 5.
La differenza principale rispetto a un normale router di modelli è che HydraFusion non si limita a stabilire quale modello sia più adatto a una richiesta. Prima di effettuare una chiamata costruisce una strategia di esecuzione e assegna il task a uno di tre schemi operativi: Single, Cascade oppure Critique. Nella modalità Single un solo modello risolve direttamente il problema quando il sistema stabilisce che non sono necessari ulteriori passaggi. Cascade utilizza inizialmente un modello più efficiente per produrre una soluzione e sottopone poi il risultato a un quality gate; se la qualità viene considerata sufficiente la risposta viene accettata, mentre in caso contrario lo stesso compito viene inoltrato a un modello più potente. Critique adotta invece una sequenza a più modelli: un primo modello genera la soluzione, un secondo modello appartenente a una famiglia differente la esamina in un contesto isolato e privo di strumenti, quindi il modello che ha prodotto la bozza effettua una singola revisione sulla base delle osservazioni ricevute.
GitHub ha valutato HydraFusion offline su TerminalBench 2.1, DeepSWE e CheckpointBench, utilizzando Claude Opus 5 e GPT-5.6 Sol come baseline. Su TerminalBench 2.1 il sistema ha superato Claude Opus 5 di 4,9 punti percentuali nella qualità verificata dei task, riducendo contemporaneamente il costo stimato del 67%. Su DeepSWE il costo è sceso del 36%, ma la qualità è risultata inferiore di 1,5 punti percentuali rispetto a Opus 5. Su CheckpointBench la riduzione del costo ha raggiunto il 65%, mentre il punteggio qualitativo è rimasto 0,1 punti percentuali sotto la stessa baseline. I risultati mostrano quindi un vantaggio economico in tutti i test, mentre la qualità ha eguagliato o superato quella di Opus 5 soltanto in uno dei tre benchmark.
Il risparmio deriva soprattutto dalla possibilità di non utilizzare il modello più costoso per ogni richiesta. Nel percorso Cascade, ad esempio, il modello più economico viene eseguito sistematicamente come primo tentativo, mentre quello più potente interviene soltanto sui task che non superano il controllo di qualità. Il costo medio dipende quindi dalla distribuzione delle richieste e dalla percentuale di casi che richiedono effettivamente l’escalation. Lo stesso principio vale per la modalità Single, nella quale i task considerati sufficientemente semplici possono essere completati senza ulteriori revisioni o chiamate. HydraFusion introduce in questo modo il controllo dei costi direttamente nella logica che stabilisce come un’attività debba essere eseguita, anziché applicarlo soltanto attraverso una scelta preventiva del modello.
Il progetto si affianca alla funzione Auto già presente in GitHub Copilot ma opera a un livello differente. Auto seleziona il singolo modello ritenuto più appropriato per una determinata richiesta, mentre HydraFusion decide quale combinazione di modelli e passaggi possa produrre il risultato migliore. Una richiesta può quindi essere affidata direttamente a un modello, iniziare con un modello più veloce per poi passare a uno superiore oppure essere sottoposta a un processo di generazione, critica indipendente e revisione. GitHub considera le due funzioni complementari e sta valutando la possibilità di far convergere in futuro le capacità di HydraFusion all’interno del sistema Auto.
La stessa impostazione di routing multi-modello è già utilizzata anche da altri sistemi. Nvidia ha introdotto NeMo Switchyard insieme a Nemotron 3.5 Lightning con l’obiettivo di ridurre il costo medio scegliendo dinamicamente tra modelli differenti; in una valutazione esterna di LangChain condotta su 145 attività multi-turn, l’invio di appena il 7% delle chiamate a un modello frontier ha ridotto la spesa del 74%, accompagnandola però a una perdita misurabile di accuratezza rispetto all’esecuzione esclusiva sul modello più potente. OpenRouter ha a sua volta aggiornato in agosto il proprio router Auto: nei benchmark pubblicati il nuovo sistema ha superato quello precedente in tre categorie su cinque, risultando invece inferiore su MMLU Pro, con l’85,2% contro l’86,6%, e su τ³-bench Banking, con il 20,6% contro il 21,0%.
Nella fase attuale HydraFusion presenta però un limite operativo importante: gestisce soltanto task di coding first-turn basati su un singolo prompt. L’orchestrazione di conversazioni e attività multi-turn è ancora in fase di sviluppo. L’anteprima permette quindi di sperimentare il routing dinamico soprattutto su richieste autonome e circoscritte, mentre i workflow più lunghi, nei quali il sistema deve conservare contesto, rivalutare la strategia e coordinare più passaggi successivi, non rientrano ancora nelle funzionalità disponibili. Il progetto mostra comunque già l’impostazione scelta da GitHub: spostare la decisione dal semplice modello da utilizzare alla struttura completa con cui il task deve essere eseguito, scegliendo di volta in volta tra esecuzione diretta, escalation e revisione incrociata tra modelli.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)