TL;DR: Gemini 3.5 Flash-Lite costa meno ed è adatto ai flussi ripetitivi; Gemini 3.6 Flash gestisce meglio codice, input multimodali e passaggi agentici complessi. Per una PMI la scelta corretta non è usare sempre il modello più capace: Flash-Lite deve essere il default, mentre Flash entra solo quando ambiguità, rischio o valore del task giustificano il costo.
Il 21 luglio 2026 Google ha portato in produzione due modelli con ruoli diversi: Gemini 3.6 Flash e Gemini 3.5 Flash-Lite. Il primo bilancia velocità e capacità sui task complessi. Il secondo punta su throughput e costo ridotto. Trattarli come alternative intercambiabili porta a spendere troppo oppure a correggere troppi output. Il criterio utile è un altro: quanto costa ottenere un risultato accettato dal workflow, non quanto costa una singola chiamata API.
Il confronto parte dal carico di lavoro
Entrambi supportano un contesto fino a un milione di token, output fino a 64.000 token, strumenti integrati e livelli di ragionamento configurabili. La somiglianza si ferma qui. La documentazione ufficiale dei nuovi modelli Gemini indica per 3.6 Flash un livello di ragionamento predefinito “medium” e per 3.5 Flash-Lite “minimal”. È una differenza operativa: uno dedica più calcolo al problema, l’altro privilegia esecuzione rapida e volumi.
| Criterio | Gemini 3.5 Flash-Lite | Gemini 3.6 Flash |
|---|---|---|
| Uso ideale | Estrazione dati, classificazione, JSON strutturato, sub-task ripetitivi | Codice, analisi multimodale, pianificazione e workflow agentici multi-step |
| Thinking predefinito | Minimal | Medium |
| Prezzo standard input | 0,30 dollari per milione di token | 1,50 dollari per milione di token |
| Prezzo standard output | 2,50 dollari per milione di token | 7,50 dollari per milione di token |
| Rischio principale | Più escalation o correzioni sui casi ambigui | Costi e tempi sprecati sui task banali |
Flash-Lite vince sui volumi prevedibili
Flash-Lite è la scelta razionale quando input e output hanno una struttura stabile. Un’automazione che legge richieste da un form WordPress, classifica l’intento e restituisce campi JSON non ha bisogno di usare sempre il modello più capace. Ha bisogno di produrre dati validi, velocemente e con un costo controllabile.
Il vantaggio economico è concreto. Alle tariffe standard pubblicate da Google, l’input di Flash-Lite costa un quinto rispetto a 3.6 Flash e l’output un terzo. Su migliaia di esecuzioni mensili la differenza pesa più del risparmio ottenuto ottimizzando pochi prompt. Google posiziona infatti Flash-Lite per analisi documentale ad alto volume, parsing strutturato e sub-agent execution.
Il limite emerge quando il task contiene eccezioni non previste. Un documento contraddittorio, una richiesta commerciale incompleta o una modifica WordPress che coinvolge permessi e dati sensibili richiedono più contesto decisionale. In questi casi un modello economico può generare un output sintatticamente corretto ma operativo solo a metà. La risposta non è scartarlo: serve un gate che intercetti l’incertezza.
Flash serve quando l’errore costa più della chiamata
Gemini 3.6 Flash è indicato per generazione di codice, ragionamento spaziale e multimodale e workflow agentici con più passaggi. Il modello costa di più, ma può ridurre i tentativi quando deve analizzare una schermata, modificare uno snippet PHP, scegliere strumenti in sequenza o ricostruire la causa di un errore.
Per un professionista, la distinzione pratica è semplice. Riassumere ticket, estrarre campi da PDF e preparare bozze strutturate sono task da Flash-Lite. Proporre una patch a un plugin, valutare un conflitto tra cache e JavaScript o pianificare una migrazione con dipendenze sono task da Flash. Usare 3.6 Flash per ogni etichetta o excerpt è sovradimensionamento. Usare Flash-Lite per una modifica irreversibile è falsa economia.
Su WordPress conviene instradare, non scegliere una volta
Un flusso serio può partire con Flash-Lite e passare a Flash solo quando scatta una regola esplicita. Per esempio:
- Flash-Lite estrae dati, normalizza campi e restituisce uno schema JSON;
- un validatore controlla campi obbligatori, tipi, lunghezza e valori ammessi;
- Flash interviene se mancano dati, la confidenza è bassa o il task richiede codice e tool multipli;
- un gate umano o tecnico resta obbligatorio prima di invii, pubblicazioni o modifiche distruttive.
Questo schema separa generazione e controllo. È lo stesso principio descritto nella guida su come validare l’output AI in JSON prima di WordPress: un modello non deve diventare il validatore di sé stesso. Schema validation, sanitizzazione e regole applicative restano nel codice.
Le metriche giuste non sono i benchmark generici
I benchmark del fornitore aiutano a capire il posizionamento, ma non decidono l’architettura di una PMI. Servono test sul proprio traffico. Le metriche da registrare sono latenza p95, costo per output accettato, percentuale di retry, errori di tool calling e quota di richieste trasferite al modello più capace.
Il costo per token da solo inganna. Se Flash-Lite richiede tre tentativi e poi un’escalation, il risparmio può sparire. Se invece completa il 90% dei task semplici al primo passaggio, usare Flash ovunque è uno spreco. La soglia va aggiornata con dati reali, non con l’impressione che il modello più nuovo sia automaticamente quello giusto.
La take: Lite di default, Flash per eccezione
Per PMI e professionisti sceglierei Gemini 3.5 Flash-Lite come motore predefinito delle automazioni. Gemini 3.6 Flash va riservato ai task complessi, ambigui o costosi da sbagliare. È una decisione netta perché obbliga a progettare routing, validazione e osservabilità invece di nascondere un workflow debole dietro un modello più caro.
Il punto non è avere due modelli nel menu. È assegnare a ciascuno un contratto operativo: Lite esegue il lavoro ripetibile; Flash gestisce le eccezioni che meritano più ragionamento. Se il team non sa definire quella soglia, il problema non è ancora il modello. È il processo.