GitHub Copilot tutorial: come usare Fusion e scegliere il livello giusto

Contenuti verificati sulla documentazione e sugli annunci ufficiali di GitHub il 29 ottobre 2026. L’analisi si basa sulla documentazione, non su un benchmark eseguito direttamente.

Che cosa cambia con GitHub Copilot Fusion

Con GitHub Copilot Fusion, deleghi la scelta del modello e, quando serve, il coordinamento tra più modelli. Pensa a un responsabile tecnico che decide se una modifica richiede un’implementazione rapida, una revisione o un intervento più approfondito. Definire il lavoro e valutare se il codice prodotto è accettabile resta compito tuo.

GitHub ha reso Fusion disponibile al pubblico il 28 ottobre 2026, unendo l’orchestrazione di Project HydraFusion alla selezione automatica dei modelli di Auto. Le selezioni esistenti Auto, HydraFusion e HydraFusion Max passano ai corrispondenti livelli di impegno di Fusion. L’anteprima di ricerca di ottobre è quindi il predecessore di Fusion, non un prodotto separato da affiancargli. L’annuncio di Fusion su GitHub.

Gli schemi di esecuzione definiscono come viene organizzato il lavoro:

• Single: un modello svolge il compito direttamente.
• Cascade: una prima proposta passa a un modello valutatore, che la accetta oppure richiede un intervento ulteriore.
• Critique: una prima proposta riceve una critica indipendente, poi il modello che l’ha prodotta la rivede.

Questi schemi derivano dalla ricerca di GitHub su HydraFusion. La documentazione attuale di Fusion descrive modelli che formulano critiche in parallelo, i cui riscontri vengono poi combinati. Non significa che ogni prompt attivi tutti gli schemi. Come si comporta Fusion.

Correggere un’etichetta e indagare una race condition, per esempio, non dovrebbero ricevere automaticamente lo stesso trattamento. Fusion decide come distribuire il lavoro all’interno della sessione. La guida ai model router approfondisce il principio di fondo: affidare il compito a capacità adeguate, poi verificare se la scelta ha portato un vantaggio.

Dove usare Fusion e come attivarlo

Fusion si può usare nell’app Copilot, in Visual Studio Code, in Copilot CLI e negli IDE JetBrains. GitHub indica questi ambienti e la disponibilità nei piani Copilot. Questo non implica che tutti gli account abbiano accesso agli stessi livelli di impegno: i modelli restano soggetti ai limiti del piano e ai criteri configurati. Disponibilità attuale.

Aggiorna il client prima di seguire queste istruzioni. Le vecchie opzioni dell’anteprima HydraFusion non corrispondono alla procedura attuale per configurare Fusion.

App GitHub Copilot

Fai clic sul nome del modello sotto il campo del prompt, attiva Copilot Fusion e scegli uno dei livelli di impegno disponibili. Per tornare a un modello specifico, disattiva l’interruttore e seleziona il modello. L’app ricorda la scelta nelle sessioni successive. Selezione del modello nell’app.

Visual Studio Code

Nelle impostazioni, verifica che chat.copilot.dynamicAutoTiers.enabled sia abilitato. Avvia una nuova chat con il Copilot harness, l’ambiente di esecuzione che collega il modello agli strumenti dell’agente. Seleziona Copilot Fusion nel selettore dei modelli e scegli uno dei livelli disponibili. L’impostazione non concede di per sé il diritto di accesso: se non è disponibile alcun livello Fusion idoneo per l’account, il selettore può continuare a mostrare Auto. Configurazione in VS Code.

GitHub Copilot CLI

In una sessione interattiva, digita /model, scegli Fusion e il livello di impegno, quindi conferma. Per una prima prova circoscritta, GitHub documenta la seguente struttura del comando; questo esempio richiede un’analisi senza modificare i file:

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

È l’opzione attuale di Fusion e non usa il vecchio flag sperimentale di HydraFusion. Selezione del modello nella CLI.

Quali modelli può usare Fusion?

L’elenco dei modelli Claude e GPT si riferisce a un momento preciso: non garantisce scelte di instradamento permanenti. Nell’aggiornamento di HydraFusion del 14 ottobre 2026, GitHub indicava espressamente:

• Claude Opus 5.5 di Anthropic.
• GPT-6 Astra di OpenAI.
• GPT-6.1 Sol di OpenAI.
• GPT-6 Luna di OpenAI.

Quell’aggiornamento introduceva anche HydraFusion Max e un ragionamento più approfondito nelle fasi di stesura e revisione. Questi sono i nomi verificati nell’annuncio dell’anteprima. Aggiornamento di ottobre sui modelli disponibili.

La panoramica attuale di Fusion non pubblica un elenco fisso ed esaustivo dei modelli cloud. Specifica che l’insieme cambia e permette di vedere quali modelli sono stati usati passando il puntatore sull’etichetta del livello di impegno sotto una risposta. Il catalogo completo dei modelli Copilot non va interpretato come una promessa che Fusion utilizzerà ciascuno di essi. Come viene gestito oggi l’insieme dei modelli.

Per un responsabile tecnico, l’elenco rilevante è quello dei modelli consentiti nel proprio account. Gli utenti con ruolo di proprietario Enterprise possono aprire AI controls → Copilot → Models → Configure Copilot Fusion models. Le scelte effettuate restano soggette anche agli altri criteri sui modelli applicabili all’utente. Controlli Enterprise sui modelli.

Esiste inoltre un’anteprima separata per l’instradamento verso modelli locali. Supporta configurazioni specifiche con MAI Code 1.1 Flash o Qwen3.8 Flash Next, usando Standard. Aggiungere un modello locale qualsiasi non lo rende automaticamente utilizzabile da Fusion. E l’inferenza locale non rende Fusion utilizzabile offline: l’instradamento avviene comunque nel cloud. Limiti dei modelli locali.

Parti da Standard e aumenta il livello quando serve

Comincia da Standard; scegli High o Max quando sai quale lavoro affidare alla revisione aggiuntiva. GitHub presenta Standard come il livello per la programmazione quotidiana, High per i compiti complessi e il ragionamento più approfondito, Max per il lavoro più impegnativo. Definizione dei livelli di impegno.

I compiti proposti di seguito sono raccomandazioni editoriali, non affermazioni sulle prestazioni basate su misurazioni:

Una richiesta generica di migliorare un’intera applicazione è una cattiva prova per Max. Senza aver definito il risultato atteso, non puoi capire se il ragionamento aggiuntivo sia servito. Restringi il compito a un problema osservabile: per esempio, eliminare un percorso duplicato di gestione delle richieste mantenendo invariato il comportamento dei tentativi successivi.

Fusion Max è un livello di impegno, non il nome di un abbonamento obbligatorio. Esiste anche Fusion Fast, ma l’utente non può selezionarlo ed è limitato alla chat inline di VS Code. Opzioni per il livello di impegno.

Come Fusion consuma i crediti AI

Il costo dipende dal lavoro svolto dai modelli selezionati. I token di input, output e quelli memorizzati nella cache vengono tariffati in base al modello, con eventuali addebiti per la scrittura nella cache, e poi convertiti in crediti AI. Non è pubblicato un costo fisso in crediti per un compito svolto da Fusion. Come funziona la fatturazione di GitHub.

Fusion non prevede un costo separato per l’orchestrazione. I piani Copilot a pagamento beneficiano attualmente di uno sconto del 30% sui costi dei modelli usati da Fusion fino al 30 novembre 2026. Fatturazione di Fusion. Per il dettaglio dei piani e delle dotazioni incluse, consulta la guida ai prezzi di GitHub Copilot.

La stesura di una prima proposta, la critica e la revisione generano ciascuna dei consumi. Anche il livello di ragionamento, le dimensioni del contesto, l’attività degli strumenti e l’uso della cache incidono. Un’esecuzione con più passaggi può quindi consumare più crediti di una richiesta a un solo modello, anche quando l’instradamento funziona come previsto. La spiegazione di VS Code sul consumo dei crediti AI.

Nella prova, conta anche i tentativi falliti e i prompt correttivi. Una prima proposta economica che richiede ripetute correzioni può risultare meno conveniente di un’esecuzione più costosa che produce una modifica accettabile. Al contrario, pagare una critica per una semplice rinomina può non offrire alcun vantaggio. Confronta il lavoro portato a termine, non il prezzo della singola risposta più economica.

Che cosa dimostra il benchmark di GitHub, e che cosa no

GitHub riporta un risultato promettente, che però non dimostra quanto risparmierai sul tuo repository. Nell’annuncio di Universe, GitHub afferma:

La valutazione citata è l’Artificial Analysis Coding Agent Index. Si tratta di un risultato di benchmark dichiarato da GitHub, non di un test indipendente eseguito per questo articolo. Annuncio di GitHub Universe.

Il changelog dettagliato specifica che il confronto è con Claude Code usando Opus 5.5 Max e che il costo misurato è il costo API medio per compito. È un’affermazione più precisa del dire che Fusion dimezza la fattura di Copilot. Il contesto del benchmark di GitHub.

La conclusione utile è che l’orchestrazione può rendere più efficiente ottenere risultati di qualità, rispetto alla scelta sistematica di una configurazione particolarmente impegnativa. Non ci sono invece basi per promettere che ogni correzione di bug sarà più rapida o meno costosa. La trasferibilità del risultato dipende dai tuoi compiti, dai criteri di accettazione e dal lavoro necessario per correggere gli errori. Anche la promozione temporanea sui costi e il confronto del benchmark sono due affermazioni distinte: non vanno sommate per promettere un risparmio.

Che cosa cambia per sviluppatori, responsabili tecnici e chi acquista

Per gli sviluppatori, Fusion semplifica la scelta del modello. Se interrompi spesso il lavoro per decidere a quale modello affidare il compito successivo, vale la pena fare una prova circoscritta. Mantieni espliciti la descrizione del problema, il comportamento atteso e i criteri di revisione. Delegare la scelta dovrebbe ridurre una distrazione, senza rendere il compito meno preciso.

I responsabili tecnici hanno bisogno di regole sui livelli e di una traccia dei risultati accettati. Un criterio iniziale utile è Standard per il lavoro ordinario, High per modifiche circoscritte che richiedono revisione e Max solo con una scelta motivata. Registra perché il passaggio a un livello superiore ha aiutato. Altrimenti scegliere il livello più alto può diventare un’abitudine, senza prove che migliori ciò che viene effettivamente rilasciato.

Chi confronta Copilot con Claude Code o Cursor per decidere cosa acquistare dovrebbe provare il flusso di lavoro che intende adottare. Un benchmark è un motivo per valutare un’opzione, non per far migrare un’intera organizzazione. Accanto ai crediti, valuta l’impegno richiesto dalla revisione, l’adeguatezza al repository e i risultati portati a termine. Per la scelta complessiva, consulta il confronto tra Claude Code e GitHub Copilot: Fusion cambia una parte di quella decisione.

Dove le promesse vanno ridimensionate e quando disattivare Fusion

Coinvolgere più modelli non elimina la tua responsabilità sulle modifiche al codice. GitHub documenta un limite dalle conseguenze particolarmente rilevanti: le proposte scartate possono lasciare modifiche nei file. Inoltre, Fusion non ha una propria finestra di contesto combinata e non avvia subagenti. Limiti di Fusion.

Tieni Fusion disattivato quando serve un modello specifico per un confronto controllato, un’indagine riproducibile o un flusso di lavoro approvato esplicitamente. Fissa la scelta del modello, così l’instradamento non diventa un’ulteriore variabile. Questo non rende deterministico un modello linguistico: elimina semplicemente una fonte di variazione.

Se una configurazione con un modello specifico che conosci già gestisce bene il tuo compito circoscritto e richiede poche correzioni, non cambia nulla per te finché una prova non dimostra un vantaggio pratico. Non c’è alcun obbligo di passare a Fusion.

Aspetta anche se hai bisogno di un flusso di lavoro offline, oppure se non riesci a definire e verificare una modifica accettabile. Per le richieste ordinarie più piccole, può essere più sensato continuare a usare Standard lasciando inutilizzati i livelli che ricorrono maggiormente all’orchestrazione. «Non usare Max» e «non usare Fusion» sono due decisioni diverse.

GitHub Copilot tutorial: prova Fusion su un repository questa settimana

Limita la prova in modo da poter esaminare ogni risultato. Scegli un repository che conosci, poi confronta Fusion con la configurazione del modello che usi già.

L’azione per questa settimana: assegna a quel repository uno sviluppatore e un revisore, concorda i controlli di accettazione e scegli l’impostazione predefinita solo dopo aver esaminato le modifiche prodotte. Una decisione documentata in modo chiaro vale più dello screenshot della risposta più veloce.

Iscriviti alla newsletter per ricevere guide pratiche su come scegliere e usare gli strumenti AI per lo sviluppo software.