GitHub ha presentato Project HydraFusion come anteprima di ricerca, dopo Auto model selection, che consente agli sviluppatori di selezionare automaticamente il modello più adatto alle loro attività. HydraFusion completa i compiti selezionando in fase di esecuzione tra i modelli di più provider, attraverso la generazione di bozze, la revisione critica, la correzione o l’inoltro a modelli più potenti. Il sistema instrada automaticamente le richieste tra modelli locali, cloud e compositi, tenendo conto dell’equilibrio tra prestazioni, costi e latenza.
HydraFusion è disponibile in GitHub Copilot CLI, a cui gli utenti di tutti i piani GitHub Copilot possono accedere tramite /experimental. Gli utenti devono aggiornare il programma con il comando /update, attivare la funzione /experimental e selezionare l’opzione HydraFusion (Research Preview) dal menu /model. Il costo si basa sui prezzi standard per token dei modelli utilizzati.
Per ogni richiesta, il sistema sceglie una delle tre modalità operative: “Single”, in cui un singolo modello produce direttamente una soluzione; “Cascade”, in cui la bozza di un modello efficiente viene sottoposta a un controllo di qualità e, se necessario, inoltrata a un modello più potente; e “Critique”, in cui l’output di un modello viene esaminato e rielaborato da un revisore indipendente appartenente a una diversa famiglia di modelli.
Nelle valutazioni offline condotte su tre benchmark di programmazione, HydraFusion ha mostrato una qualità di livello frontier a un costo stimato contenuto. In TerminalBench 2.1, ha aumentato di 4,9 punti la qualità verificata delle attività rispetto a Claude Opus 5, riducendo al contempo il costo stimato del 67%.
Perché è importante
Questo approccio sta cambiando il modo di lavorare basato su un unico modello nei processi di programmazione, riducendo per gli sviluppatori l’onere di scegliere un modello per ogni attività. Il routing dei modelli locali, cloud e compositi in base a prestazioni, costi e latenza consente in particolare agli utenti di Copilot CLI di usufruire, all’interno dello stesso flusso di lavoro, di diverse opzioni in termini di qualità e risorse. Sebbene i risultati dei benchmark offline mostrino l’obiettivo di raggiungere un’elevata qualità a un costo stimato inferiore, questi dati da soli non spiegano quale sarà il riscontro del sistema, che si trova in fase di anteprima di ricerca, nell’utilizzo reale. Per gli utenti, la questione fondamentale ancora aperta è in che modo questo routing, che varia a seconda del tipo di attività, influirà sul costo complessivo calcolato sulla base dei prezzi standard dei token e sull’esperienza quotidiana di sviluppo.