AIREITERGitHub HydraFusion è un sistema di orchestrazione in research preview per Copilot CLI. I risultati ottenuti nei benchmark offline non garantiscono però le stesse prestazioni su repository lunghi, complessi e disordinati.
In breve: quando vale la pena usarlo
GitHub HydraFusion merita una prova se hai un piano GitHub Copilot e un'attività di sviluppo importante ma ben delimitata, descrivibile in un unico prompt. Per il momento non lo userei come impostazione predefinita per modifiche critiche in produzione o sessioni lunghe e iterative: GitHub lo definisce ancora una research preview e indica il supporto multi-turn più robusto come lavoro futuro.
HydraFusion non è un nuovo foundation model. È un sistema di orchestrazione runtime integrato in GitHub Copilot CLI, che decide se un compito richiede un solo modello, un percorso di escalation oppure una revisione indipendente prima di produrre il risultato.
Come attivare HydraFusion in Copilot CLI
La preview si abilita da Copilot CLI, non dal normale selettore di modelli di VS Code. L'annuncio ufficiale di GitHub indica che è disponibile sui vari piani Copilot tramite una sequenza di comandi sperimentali, mentre la guida rapida di Copilot CLI spiega separatamente installazione e autenticazione.
- Aggiorna Copilot CLI con
/update. - Abilita le funzionalità sperimentali con
/experimental on. - Apri il selettore del modello con
/model. - Seleziona HydraFusion (Research Preview).
- Inizia con un'attività di sviluppo corposa ma chiaramente circoscritta, invece di un progetto conversazionale prolungato.
Se HydraFusion non compare, aggiorna anzitutto la CLI e verifica che il tuo account Copilot, le policy dell'organizzazione e la build della CLI supportino la preview. L'annuncio ufficiale di GitHub è la fonte di riferimento per la sequenza di comandi aggiornata; nome e disponibilità della preview possono cambiare.
Nei risultati di ricerca appare anche AICPS/hydrafusion, un repository di ricerca sulla fusione di sensori per veicoli autonomi. Non ha alcun legame con Project HydraFusion di GitHub per Copilot.
Il workflow giusto dipende dal tipo di attività
HydraFusion seleziona uno fra tre schemi di esecuzione in base alle esigenze previste di qualità, costo e latenza. Nella preview attuale non si tratta di una modalità da scegliere manualmente: GitHub presenta HydraFusion come un'opzione simile a un modello, capace di decidere a runtime quale workflow sottostante usare.
| Workflow | Cosa succede | Quando usarlo per iniziare | Compromesso principale |
|---|---|---|---|
| Single | Un solo modello risolve direttamente il compito. | Modifiche lineari, spiegazioni o piccole correzioni. | Overhead apparentemente minimo, ma senza escalation né revisione indipendente. |
| Cascade | Un modello efficiente prepara una prima risposta; un controllo di qualità può passare il compito a un modello più potente. | Attività forse semplici, ma che potrebbero richiedere maggiori capacità. | Riduce il costo quando il primo tentativo basta, ma aggiunge un controllo e la possibile seconda chiamata. |
| Critique | Un modello prepara la bozza, un critico isolato di un'altra famiglia di modelli la esamina e l'autore la rivede una volta. | Modifiche in cui un secondo punto di vista può intercettare errori. | Più chiamate e più latenza, senza accesso diretto agli strumenti per il critico. |
Single: esecuzione diretta
Single è il percorso più essenziale. GitHub spiega che un singolo solver riceve il compito e lavora nel normale ciclo dell'agente Copilot, rispettando i permessi: una soluzione adatta a richieste con implementazione chiara e un breve percorso di test.
Il vantaggio è un minor overhead del workflow, ma Single non offre un secondo parere integrato.
Cascade: prima l'efficienza, poi la potenza se serve
Cascade parte da un modello efficiente e usa un controllo di qualità per stabilire se il risultato sia sufficiente oppure debba essere passato a un modello più potente. L'idea economica è l'escalation selettiva: le richieste di routine non dovrebbero consumare automaticamente il modello più capace disponibile.
Cascade può contenere la spesa quando il primo passaggio supera il controllo, ma GitHub non pubblica un tasso di escalation universale. Conviene valutarlo sui risultati effettivi dei compiti, senza dare per scontato che ogni richiesta segua il percorso più economico.
Critique: bozza, revisione indipendente e una correzione
Critique introduce un revisore separato, proveniente da una diversa famiglia di modelli. GitHub afferma che il critico opera in un contesto isolato e privo di strumenti, analizza la bozza e invia il feedback al solver originale per un'unica revisione; non può modificare direttamente il repository.
In pratica è una peer review automatizzata, con il costo di una chiamata al modello e di maggiore latenza.
I benchmark mostrano compromessi, non promesse
I test offline di GitHub evidenziano compromessi tra qualità e costo specifici dei benchmark; non promettono un risparmio del 67% su ogni attività svolta con Copilot.
| Benchmark | Qualità di HydraFusion rispetto a Claude Opus 5 | Costo stimato rispetto a Claude Opus 5 | Cosa indica |
|---|---|---|---|
| TerminalBench 2.1 | +4,9 punti percentuali | 67% inferiore | Il risultato più forte riportato: migliore qualità verificata sul compito a un costo stimato inferiore. |
| DeepSWE | −1,5 punti | 36% inferiore | Un risparmio rilevante, accompagnato da una perdita di qualità misurabile sul lavoro difficile nei repository. |
| CheckpointBench | −0,1 punti | 65% inferiore | Qualità quasi equivalente nel benchmark interno di GitHub basato sul replay, a un costo stimato molto più basso. |
Secondo il suo annuncio ufficiale su HydraFusion, GitHub ha usato impostazioni di valutazione coerenti e conteggiato tutte le chiamate del workflow, inclusi retry, critiche, escalation e fallback.
CheckpointBench viene descritto come un replay di sessioni Copilot selezionate su commit immutabili di repository pubblici. È quindi più vicino al lavoro di un coding agent rispetto a un semplice test di generazione testuale, ma resta un benchmark controllato. Il risultato inferiore di HydraFusion su DeepSWE è significativo perché impedisce di leggere la tabella come una vittoria universale.
Le prove indipendenti nel mondo reale sono ancora limitate. @DoDataThings su X, uno sviluppatore indipendente, individua il punto chiave da validare:
“Il modello che pianifica non deve per forza essere quello che scrive il codice. La nota di GitHub dice che HydraFusion ha eguagliato o superato la baseline Opus 5 in valutazioni offline controllate, e il passaggio dalle valutazioni offline a repository reali e disordinati è dove l'orchestrazione di solito perde il suo margine. Mi chiedo quanto del divario di costo sopravviva.”
Il post pone una domanda, non presenta una misurazione, ma individua il test corretto: costo e qualità su repository disordinati.
Gli aspetti operativi che contano davvero in un repository
Il valore di HydraFusion non dipende soltanto dalla selezione di un modello meno costoso. GitHub documenta controlli per contabilità, annullamento, validazione del routing, isolamento della revisione e applicazione delle patch, perché chiamare più modelli crea più stati operativi rispetto a una singola richiesta diretta.
| Controllo | Cosa comporta per l'utente |
|---|---|
| Controlli su costi e tempi | HydraFusion tiene traccia delle chiamate nei vari passaggi del workflow e supporta un'esecuzione con limiti, ma critiche, escalation, retry e fallback possono comunque aumentare latenza o consumo complessivo. |
| Controlli su routing e patch | GitHub afferma di validare i percorsi e di non applicare patch dopo un workflow non valido o annullato; nessuno dei due controlli dimostra che il percorso scelto o il codice finale siano corretti. |
| Isolamento della revisione | I critici sono in sola lettura e senza strumenti, mentre i solver usano lo spazio di lavoro condiviso: questo limita le modifiche dirette del revisore, ma non elimina la necessità di controllare il diff e svolgere i test. |
L'annuncio di GitHub documenta anche un compromesso di visibilità: le bozze intermedie non vengono mostrate fino al risultato finale. La risposta risulta più pulita, ma durante l'attesa non sono visibili bozze, retry, escalation e scarti.
Un primo test sensato con HydraFusion
La prima prova migliore è un'attività circoscritta nel repository, con un controllo di accettazione oggettivo; non una richiesta aperta per “migliorare” una codebase. Considera la preview un esperimento, partendo da un commit noto e con una definizione fissa di successo.
- Crea un branch o un worktree pulito e annota il commit iniziale.
- Scegli un'attività con confini ristretti a livello di file e un comando di test riproducibile.
- Indica nel primo prompt comportamento atteso, vincoli e test.
- Lascia che HydraFusion completi il compito, poi esamina il diff invece di accettarlo perché l'agente segnala il successo.
- Esegui personalmente i test pertinenti e verifica l'assenza di modifiche a file non correlati.
- Registra latenza, dati visibili di utilizzo o costo, retry, comportamento di escalation e risultato finale dei test, se la CLI li espone.
- Ripeti la prova con alcune attività prima di confrontare HydraFusion con un modello fisso o cambiare l'impostazione predefinita del team.
Una patch riuscita non basta per convalidare le affermazioni dei benchmark. L'unità utile è un piccolo insieme di attività che comprenda una correzione di routine, una modifica che coinvolge più file e un caso deliberatamente ambiguo in cui escalation o critique potrebbero fare la differenza.
Costi di HydraFusion e limiti delle sue promesse
Nell'annuncio GitHub non pubblica un prezzo in dollari separato per HydraFusion. Indica invece che l'utilizzo viene addebitato secondo le tariffe token standard dei modelli sottostanti: il costo finale dipende quindi dai modelli e dai passaggi del workflow scelti dal runtime.
| Domanda sulla fatturazione | Risposta attuale |
|---|---|
| Esiste un costo di abbonamento separato per HydraFusion? | Nell'annuncio di GitHub non viene indicato alcun costo separato per HydraFusion. |
| Come viene fatturato l'utilizzo? | In base ai token consumati dai modelli che lo compongono, alle loro tariffe standard. |
| Un singolo compito può usare più chiamate fatturabili? | Sì. Cascade e Critique possono coinvolgere più passaggi del workflow, e la contabilità include retry e fallback. |
| Un risparmio del 67% nel benchmark equivale a un risparmio del 67% per il cliente? | No. È un confronto stimato per uno specifico benchmark, una certa policy, un pool di modelli e una configurazione di prezzi. |
| HydraFusion è una funzionalità stabile per la produzione? | No. GitHub la definisce una research preview e avverte che modelli, workflow, disponibilità, comportamento e nome possono cambiare. |
Usa inizialmente HydraFusion per attività ispezionabili e risolvibili con un solo prompt; mantieni un fallback su modello fisso per lavori lunghi, multi-turn o ad alto impatto, finché i test a livello di repository non ne giustifichino un impiego più ampio.
FAQ su HydraFusion
HydraFusion è un modello o un router?
HydraFusion è un sistema runtime di orchestrazione multi-modello in GitHub Copilot CLI, non un foundation model autonomo; seleziona modelli e schemi di esecuzione per un'attività di sviluppo.
Come si abilita HydraFusion in Copilot CLI?
Esegui /update, /experimental on e /model, quindi seleziona HydraFusion (Research Preview).
HydraFusion è disponibile su tutti i piani Copilot?
GitHub afferma che la preview è disponibile sui vari piani Copilot tramite Copilot CLI, anche se account, policy dell'organizzazione, versione della CLI o cambiamenti nella disponibilità possono influire sulla sua visibilità.
Quali modelli sottostanti usa HydraFusion?
GitHub descrive una selezione fra modelli di più provider, ma non pubblica un elenco fisso per ogni richiesta. Non bisogna quindi presumere che ogni attività venga gestita da un modello nominato.
HydraFusion supera sempre Claude Opus 5?
No: GitHub riporta un miglioramento su TerminalBench 2.1, una quasi parità su CheckpointBench e uno svantaggio di 1,5 punti su DeepSWE.
HydraFusion ha un costo aggiuntivo?
L'utilizzo viene fatturato alle tariffe token standard dei modelli sottostanti e un percorso può chiamare più modelli; nell'annuncio GitHub non indica un prezzo in dollari separato per HydraFusion.
HydraFusion è disponibile in VS Code?
Il materiale di lancio documenta la preview tramite Copilot CLI; per un'eventuale disponibilità più ampia, verifica la documentazione GitHub aggiornata.
È sicuro lasciare che HydraFusion modifichi un repository?
GitHub descrive solver attenti ai permessi, critici isolati, routing validato, esecuzione con limiti e assenza di patch per workflow non validi o annullati; prima del merge, controlla comunque il diff ed esegui i test.