GitHub ha rimosso Gemini 2.5 Pro e Gemini 3 Flash da ogni esperienza Copilot venerdì. Le sostituzioni sono Gemini 3.1 Pro e Gemini 3.6 Flash.

Lo scambio non è simmetrico

Gemini 2.5 Pro era un modello stabile, generalmente disponibile. Il suo successore designato, Gemini 3.1 Pro, è etichettato come Preview. I team che si erano standardizzati su un modello stabile vengono trasferiti a uno che porta un'etichetta di anteprima, il che, nella tassonomia di GitHub, significa che può cambiare o scomparire senza l'avviso riservato a un modello GA.

Che cosa copre davvero 'non è richiesta alcuna azione'

Il changelog dice che non è richiesta alcuna azione e, per quanto riguarda la rimozione, è corretto — non si rompe nulla, i modelli semplicemente smettono di comparire. La stessa voce osserva poi che gli amministratori di Copilot Enterprise potrebbero dover abilitare l'accesso ai modelli alternativi tramite le loro policy sui modelli. Queste due frasi non descrivono la stessa situazione. In un'organizzazione con una policy sui modelli restrittiva, i vecchi modelli Gemini scompaiono e i nuovi non vengono autorizzati automaticamente, lasciando gli sviluppatori senza alcuna opzione Gemini finché qualcuno con diritti di amministratore non se ne accorge.

L'altra modifica pubblicata lo stesso giorno

GitHub ha inoltre portato il targeting delle policy sui modelli per enterprise-team in anteprima pubblica: un'azienda può impostare un insieme di modelli di base e concederne altri aggiuntivi ai singoli team, risolti secondo il principio meno restrittivo. La maggior parte dei clienti riceve l'opzione di attivazione il 3 agosto, quindi l'annuncio precede la disponibilità. Nascosta al suo interno c'è una conseguenza che vale la pena leggere due volte — una volta attivato il targeting enterprise, le impostazioni dei modelli a livello di organizzazione non si applicano più. Le restrizioni esistenti di un amministratore di organizzazione vengono silenziosamente superate dalla policy enterprise.

Perché una voce di changelog merita attenzione

La disponibilità dei modelli all'interno di uno strumento di coding è ormai una decisione di approvvigionamento presa dal fornitore dello strumento, non dallo sviluppatore. I modelli a cui un team può accedere, e a quale livello di stabilità, vengono decisi due livelli sopra — dalla piattaforma, poi da un amministratore enterprise — e cambiano tramite voci di changelog che nessuno è obbligato a leggere.