AIREITERUn’attività di coding può sembrare banale, finché non entra in gioco una dipendenza tra più file. Project HydraFusion seleziona il flusso che, secondo le sue stime, dovrebbe raggiungere una determinata soglia di qualità. La preview di ricerca, però, non mostra il percorso esatto e non garantisce gli stessi risparmi in ogni repository.
Il routing in sintesi
Project HydraFusion è un livello di orchestrazione a runtime integrato in GitHub Copilot CLI, non un nuovo foundation model. Sei tu a selezionare HydraFusion (Research Preview); sarà poi il runtime a scegliere modelli e modalità di esecuzione.
| Flusso | Sequenza a runtime | Vantaggio principale | Compromesso principale |
|---|---|---|---|
| Single | Un unico modello selezionato risolve direttamente l’attività. | Il minimo overhead del flusso e il percorso di latenza più semplice. | Nessuna escalation automatica né revisione indipendente. |
| Cascade | Un modello efficiente prepara una prima soluzione; un quality gate la accetta oppure la inoltra a un modello più potente. | Evita di usare il modello più potente quando il primo tentativo è sufficiente. | Un controllo fallito può aggiungere chiamate al modello, token e tempi di attesa. |
| Critique | Un modello prepara la bozza; un revisore indipendente di un’altra famiglia di modelli la analizza in sola lettura; il solver la modifica una volta. | Aggiunge un secondo punto di vista per le modifiche più soggette a errori. | Introduce lavoro sequenziale e il revisore non può eseguire tool né modificare il repository. |
Per provare la preview, esegui /update, poi /experimental on, quindi /model e seleziona HydraFusion (Research Preview). GitHub documenta questa sequenza nel suo annuncio ufficiale di HydraFusion. La preview è disponibile con tutti i piani Copilot, anche se l’accesso gestito dall’organizzazione può dipendere dalla policy di Copilot CLI configurata dall’amministratore.
Non si tratta di tre interruttori pubblici che consentono di imporre manualmente un percorso a ogni richiesta. Il materiale di lancio descrive la selezione di HydraFusion e lascia al runtime il compito di bilanciare prestazioni, costi e latenza.
Cosa cerca di prevedere il runtime
GitHub afferma che HydraFusion utilizza segnali relativi a ragionamento, generazione di codice, debugging e uso dei tool. Sceglie il flusso più efficiente che, secondo le sue stime, dovrebbe raggiungere la soglia di qualità richiesta, ma GitHub non pubblica né le soglie né una regola deterministica del tipo “tre file significa Cascade”.
La forma dell’attività è quindi un’indicazione, non una garanzia di routing: una modifica circoscritta con un percorso di test evidente si presta concettualmente a Single; una richiesta potenzialmente difficile è adatta all’escalation selettiva di Cascade; una modifica che beneficia di una revisione indipendente può rientrare in Critique. L’annuncio non fornisce una lista fissa di modelli per ogni richiesta né una traccia del percorso leggibile dall’utente.
Si possono imporre Single, Cascade o Critique?
GitHub documenta la selezione di HydraFusion e lascia al runtime la scelta del flusso; non documenta un comando pubblico per forzare uno dei tre percorsi. Quando il routing prevedibile è una priorità, conviene usare un modello Copilot fisso.
Quando il lavoro aggiuntivo di ogni flusso è giustificato
Single: esecuzione diretta quando il percorso è chiaro
Single invia l’attività a un solo solver all’interno del normale agent loop di Copilot, con le relative regole di autorizzazione. È adatto a una piccola modifica ben definita, a una spiegazione breve o a un bug fix con implementazione e percorso di test chiari.
Il vantaggio è un profilo di costi e latenza più semplice. Il flusso non aggiunge deliberatamente un quality gate o una seconda opinione: se il solver interpreta male la richiesta, il principale revisore resta quindi lo sviluppatore.
Cascade: escalation solo quando il primo tentativo non basta
Cascade parte da un modello efficiente. Un quality gate valuta il risultato candidato e può inoltrare l’attività a un modello più potente quando la prima soluzione non supera la soglia prevista.
La logica economica è condizionata:
- Il primo modello gestisce il lavoro che può completare in modo adeguato.
- Il quality gate filtra i risultati deboli o incerti.
- Solo le attività che richiedono maggiore capacità seguono il percorso più potente.
Questo può ridurre il costo medio del flusso rispetto all’invio di ogni attività a un frontier model. Un’escalation, un nuovo tentativo o un fallback possono comunque rendere più costosa e più lenta la coda dei casi difficili, e GitHub non ha pubblicato una percentuale di escalation universale per la pianificazione specifica di ogni repository.
Critique: pagare per un secondo punto di vista
Critique è un ciclo composto da bozza, revisione e modifica. Il primo solver produce il risultato; un revisore appartenente a una famiglia di modelli diversa lo analizza in un contesto isolato, senza tool e in sola lettura; infine il solver originale apporta una revisione.
Il revisore non può eseguire i test del progetto, ispezionare un file generato tramite un comando o applicare direttamente una correzione. Critique offre diversità nella revisione, non un’implementazione end-to-end indipendente.
Il bilancio dei benchmark: spendere meno non equivale a una sola promessa sulla qualità
GitHub ha valutato policy HydraFusion fisse confrontandole con Claude Opus 5 su tre benchmark di coding agentico. Le cifre seguenti provengono dall’annuncio ufficiale di GitHub.
| Benchmark | Qualità di HydraFusion rispetto a Claude Opus 5 | Costo stimato del flusso rispetto a Claude Opus 5 | Come interpretarlo |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 punti percentuali | 67% in meno | In questa valutazione, qualità verificata superiore a un costo stimato inferiore. |
| DeepSWE | −1.5 punti | 36% in meno | Un risparmio significativo accompagnato da una rinuncia misurabile in termini di qualità sul lavoro complesso nei repository. |
| CheckpointBench | −0.1 punto | 65% in meno | Qualità quasi equivalente a un costo stimato sostanzialmente inferiore. |
Il punto sono proprio questi risultati eterogenei: HydraFusion è pensato per aggiungere inferenza quando il miglioramento atteso della qualità giustifica costi e latenza, non per usare più modelli a ogni richiesta.
GitHub afferma che la valutazione ha mantenuto coerenti input, tool, limiti di esecuzione, prezzi e criteri di valutazione, contando i passaggi di stesura, revisione, modifica, escalation, nuovo tentativo e fallback. Restano comunque stime offline controllate, legate alle policy valutate, al pool di modelli, alle versioni dei benchmark e alle ipotesi di prezzo adottate.
Non dimostrano che una normale attività in Copilot costerà il 67% in meno o che HydraFusion supererà Claude Opus 5 in uno specifico codebase. Durante la prova su carichi di lavoro reali, GitHub consiglia di iniziare da attività di coding sostanziali, ben delimitate e gestibili in un unico prompt.
L’equazione dei costi ha tre componenti
Quando valuti HydraFusion, separa costo atteso dei token, costo dei casi più onerosi e tempo di attesa.
| Fattore | Single | Cascade | Critique |
|---|---|---|---|
| Lavoro iniziale | Un solver | Prima un solver efficiente | Prima il solver che prepara la bozza |
| Lavoro aggiuntivo | Nessuno per progettazione | Modello più potente dopo un quality gate fallito | Revisore più una revisione del solver |
| Profilo dei costi | Più prevedibile | Condizionato; aumenta in caso di escalation o nuovo tentativo | Strutturalmente superiore a una bozza diretta |
| Profilo della latenza | Percorso più semplice | Breve se il risultato viene accettato; più lungo dopo un’escalation | La revisione e la modifica aggiuntive allungano il percorso |
| Meccanismo di qualità | Capacità del solver | Quality gate più escalation | Revisione indipendente più modifica |
Un costo stimato inferiore non significa automaticamente una risposta più rapida: Cascade può rallentare i casi che richiedono escalation, Critique aggiunge una revisione sequenziale e Single risponde velocemente lasciando però allo sviluppatore una parte maggiore della validazione.
La documentazione sull’uso di Copilot CLI di GitHub indica che /usage mostra la durata della sessione, gli AI Credits consumati, le righe modificate e la suddivisione dell’uso dei token per modello. Questi dati aiutano a confrontare le attività reali, ma non spiegano ogni decisione di routing né mostrano le bozze intermedie scartate.
La scatola nera tra prompt e patch
GitHub descrive una contabilizzazione completa dei vari passaggi del flusso, un’esecuzione delimitata con gestione di timeout e cancellazioni, una revisione isolata, un routing validato e l’applicazione fail-safe della patch dopo flussi non validi o annullati. Sono controlli che riducono il rischio operativo, ma non dimostrano che il percorso o il codice finale siano corretti.
GitHub afferma inoltre che la preview conserva le bozze intermedie finché non è in grado di restituire un unico risultato coerente. Diventa quindi difficile capire se un’attività sia rimasta in Single, sia passata all’escalation di Cascade oppure abbia seguito il ciclo di revisione e modifica di Critique.
Un utente reale ha evidenziato direttamente questo limite di osservabilità:
“La funzionalità di prodotto che vorrei vedere per prima è una traccia leggibile di quale modello ha fatto cosa e del motivo per cui il router è passato a un altro modello.” — @_Mazzana su X
Senza una ricevuta del percorso, gli sviluppatori non possono collegare pienamente costi, latenza e patch finale al flusso che li ha prodotti.
Come usare la preview senza trarre conclusioni eccessive
Considera HydraFusion un esperimento prima di trasformarlo nello standard del team:
- Crea un branch o un worktree pulito e annota il commit di partenza.
- Prova una correzione ordinaria, una modifica tra più file e un’attività ambigua con un controllo di accettazione riproducibile.
- Inserisci nel primo prompt comportamento atteso, vincoli e comandi di test.
- Esamina la diff finale, verifica che non siano stati modificati file estranei ed esegui personalmente i test pertinenti.
- Registra durata della sessione, utilizzo visibile di AI Credits o token, risultato dei test ed eventuali segnali visibili di nuovi tentativi o escalation.
- Ripeti la prova su più attività prima di confrontare HydraFusion con un modello fisso.
Non cercare di dedurre la modalità nascosta solo dalla lunghezza della risposta. Una risposta lunga può dipendere dalla complessità del repository, non da Critique. Mantieni un fallback basato su un modello fisso per attività lunghe, conversazioni con più turni, lavori sensibili alla latenza o situazioni ad alto impatto: per la preview attuale GitHub raccomanda attività gestibili al primo turno e, nella sua guida al lancio, indica le prestazioni migliori su più turni come obiettivo futuro.
FAQ su HydraFusion
Posso selezionare manualmente Single, Cascade o Critique?
Non tramite un comando documentato per impostare la modalità di HydraFusion. Il controllo attualmente disponibile consiste nel selezionare HydraFusion e lasciare la scelta al runtime; quando il routing deterministico è importante, usa un modello fisso.
Come viene fatturato HydraFusion?
GitHub afferma che l’utilizzo si basa sui token consumati dai modelli impiegati da HydraFusion, addebitati alla tariffa standard di ciascun modello, come descritto nell’annuncio ufficiale. Una riduzione osservata nei benchmark non equivale a uno sconto universale per i clienti e i flussi composti da più passaggi possono consumare più token di una richiesta diretta.
HydraFusion è particolarmente interessante quando un’attività è abbastanza importante da beneficiare di escalation o revisione selettiva, ma anche sufficientemente strutturata da poter essere verificata. Per il lavoro rapido può contare di più la semplicità di Single; per attività lunghe o ad alto rischio, il comportamento prevedibile di un modello fisso può restare la scelta operativa migliore finché i dati del repository non giustificano l’orchestrazione aggiuntiva.