Google ha deprecato due slug Gemini Flash API e sta instradando automaticamente il traffico da ciascun vecchio nome a un sostituto più recente, creando una modifica di piccola entità al catalogo dei modelli con conseguenze maggiori per gateway, analisi e reporting dei clienti.
Secondo le note di rilascio Gemini API di Google datate 8 ottobre 2026, gemini-3.7-flash è deprecato e sostituito da gemini-3.8-flash. Le richieste inviate allo slug 3.7 Flash deprecato vengono automaticamente instradate a 3.8 Flash. Google ha anche deprecato gemini-3.5-flash, sostituendolo con gemini-3.6-flash e lo stesso comportamento di reindirizzamento automatico.
L'azienda ha inoltre deprecato deep-research-pro-preview-12-2025 e afferma che l'agente Deep Research verrà chiuso il 23 ottobre 2026, con percorsi di migrazione ai nuovi agenti Deep Research. Ciò offre ai team un breve lasso di tempo per identificare l'utilizzo in produzione, modificare gli ID bloccati e verificare il comportamento dell'output prima che il vecchio endpoint di anteprima scompaia.
Cosa è cambiato nel Gemini API
Il cambiamento operativo immediato è semplice: una richiesta può nominare un modello mentre Google ne serve un altro. Non è la stessa cosa che uno sviluppatore modifichi deliberatamente un'applicazione da gemini-3.7-flash a gemini-3.8-flash. Si tratta di una sostituzione lato fornitore.
Per le applicazioni semplici, la differenza potrebbe essere invisibile se le risposte rimangono accettabili. Per i team che eseguono valutazioni, analisi rivolte ai clienti, flussi di lavoro regolamentati o attribuzione dei costi, è importante. Una voce di log che registra solo il modello richiesto può far sembrare che un modello deprecato stia ancora gestendo il traffico. Una dashboard che registra solo il modello servito può nascondere il fatto che i clienti chiamano ancora un vecchio slug. Entrambe le visualizzazioni sono incomplete.
È qui che gli alias dei modelli AI diventano più che semplici comodità per gli sviluppatori. I gateway devono distinguere almeno tre casi: un alias cliente stabile creato dalla piattaforma, un alias fornitore che fluttua intenzionalmente e un percorso di deprecazione del fornitore che mappa silenziosamente un vecchio ID modello pubblico a uno nuovo. Trattarli tutti e tre come lo stesso campo crea analisi ambigue.
Perché il reindirizzamento automatico è utile ma rischioso
Il reindirizzamento automatico riduce le interruzioni immediate. Se un cliente ha codificato gemini-3.7-flash, il percorso sostitutivo di Google può mantenere le richieste in esecuzione mentre il team aggiorna la configurazione. Si tratta di una scelta pratica di continuità del servizio, soprattutto per le applicazioni in cui gli ID modello sono distribuiti tra script, integrazioni dei partner, richieste o impostazioni del cliente.
Il compromesso è la perdita di controllo esplicito. Una sostituzione del modello può modificare la latenza, lo stile di output, il comportamento di sicurezza, i modelli di utilizzo degli strumenti o l'affidabilità dei casi limite anche quando la chiamata API riesce comunque. Gli sviluppatori potrebbero non notare il cambiamento finché una valutazione non va alla deriva, un messaggio non si comporta diversamente o un cliente non chiede perché l'utilizzo segnalato non corrisponde più alla documentazione.
Il rischio è maggiore per le piattaforme che espongono Google modelli attraverso un gateway multi-modello API per i team. Questi prodotti si collocano tra il fornitore e l’utente finale, quindi devono decidere quanto del comportamento di routing del fornitore far emergere. Un gateway che inoltra semplicemente il vecchio slug e fattura la chiamata risultante come al solito può preservare la compatibilità, ma lascia ai team di supporto e finanza una traccia di controllo debole.
Quali gateway e piattaforme di rivenditori dovrebbero registrare
Il modello più pulito consiste nel memorizzare il modello richiesto, il modello del provider risolto e la regola di alias che ha causato la risoluzione. Per la modifica Gemini Flash, ciò significa che un record di utilizzo dovrebbe essere in grado di mostrare che il cliente ha richiesto gemini-3.7-flash, Google ha servito gemini-3.8-flash e il motivo era il reindirizzamento deprecato di Google anziché una regola di fallback definita dal cliente.
Questa distinzione influisce sul supporto per la fatturazione, sulla pianificazione della migrazione e sull'affidabilità del prodotto. Se un cliente chiede se la sua applicazione utilizza ancora un modello deprecato, la risposta non dovrebbe richiedere l'archeologia manuale dei log. Se un rivenditore deve notificare gli account downstream, dovrebbe essere in grado di segmentare in base allo slug legacy richiesto. Se una suite di valutazione interna inizia a fallire, gli ingegneri dovrebbero essere in grado di confrontare i risultati prima e dopo la modifica del modello servito senza indovinare quando si è spostato il traffico.
Per i prodotti di tipo Model Gate, il lavoro pratico riguarda l'analisi dell'utilizzo e il reporting sui clienti. Un dashboard di analisi dell'utilizzo dovrebbe evitare di comprimere il modello richiesto e quello offerto in un'unica etichetta. Dovrebbe inoltre rendere gli ID obsoleti sufficientemente visibili da consentire ai proprietari degli account di inviare le migrazioni prima che termini il supporto del provider.
La chiusura dell'agente Deep Research aggiunge un secondo tipo di scadenza. A differenza di un reindirizzamento Flash, Google afferma che deep-research-pro-preview-12-2025 verrà disattivato il 23 ottobre 2026. I team che utilizzano quell'agente di anteprima devono eseguire la migrazione anziché fare affidamento su un routing di compatibilità indefinito. Poiché i flussi di lavoro di Deep Research possono essere incorporati in pipeline di ricerca o di automazione a lungo termine, il controllo della migrazione dovrebbe includere richieste, ipotesi sugli strumenti, formati di output ed eventuali liste consentite di modelli archiviati.
Ciò che rimane incerto
Le note di rilascio diGoogle identificano gli slug deprecati, le sostituzioni e il comportamento di reindirizzamento, ma non risolvono ogni questione operativa per le piattaforme downstream. Le note non forniscono un ampio confronto comportamentale tra il vecchio modello Flash e quello sostitutivo nella voce del registro delle modifiche citata. Inoltre, non indicano una data di chiusura per gli slug Flash deprecati nello stesso modo in cui lo fanno per l'agente di anteprima Deep Research.
Ciò lascia i team con un problema di gestione API familiare: la compatibilità potrebbe continuare per ora, ma lo stato stabile è ancora in fase di migrazione. Gli sviluppatori dovrebbero aggiornare le selezioni esplicite dei modelli, eseguire nuovamente le valutazioni critiche rispetto agli ID sostitutivi e assicurarsi che i log contengano dettagli sufficienti per spiegare cosa è successo durante la transizione.
La lezione più ampia è che gli ID modello non sono più semplici nomi di prodotto. Possono essere versioni stabili, alias in movimento, shim di compatibilità o trappole di deprecazione. I gateway che desiderano offrire ai clienti un controllo affidabile necessitano di un modello di dati in grado di rappresentare direttamente tali differenze.