Gemini 3.6 Flash: la manopola del thinking che sposta i costi di 30x (misurato)

Gemini 3.6 Flash ti addebita i thinking token oltre alla risposta, e quanti ne consuma è una manopola che controlli per singola richiesta. Sullo stesso task di scrittura da 120 parole, l’impostazione di default ha fatturato $0.03316 e l’impostazione minimal $0.00110: un’oscillazione di 30x per un output che un lettore non saprebbe distinguere. Questa manopola è la decisione di costo più importante su questo modello, e nasconde un’insidia precisa. Gemini 3.6 Flash è diventato generalmente disponibile il 2026-07-21 a $1.50 per milione di token di input e $7.50 per milione di output, in calo rispetto ai $9 di output su 3.5 Flash. È uscito insieme a Gemini 3.5 Flash-Lite e a una 3.5 Flash Cyber ottimizzata per la sicurezza; questo articolo misura i due tier general-purpose, 3.6 Flash e Flash-Lite.

TL;DR

• reasoning_effort: "minimal" ha tagliato il costo per chiamata del 91–97% rispetto al default (un’oscillazione di 30x su un task da 120 parole), gratis su lavoro a passo singolo, output strutturato e tool-calling, ma manda in crisi la matematica multi-step, da 3/3 a 0/3.
• Il “17% di token di output in meno” di Google dipende dal workload: i nostri task pesanti sul ragionamento sono risultati più leggeri del 19% (32% più economici), la nostra suite agentica più pesante del 9% (6% più economica).
• Il contesto da 1M è reale (un ago recuperato a 972K token) e il prompt caching corrisponde esattamente alla soglia di 4.096 token pubblicata da Google: una corrispondenza pulita con le specifiche, a differenza di alcuni modelli “contesto 1M” che restano sotto quanto pubblicizzano.

Tutto quanto segue è stato misurato il 2026-07-24 attraverso il gateway Synthorai, con i prompt ripetuti salati per aggirare le cache; ogni numero è supportato dai record grezzi di utilizzo.

Quanto costa Gemini 3.6 Flash per task con le impostazioni di default?

Il ragionamento domina la bolletta dell’output, e viene addebitato che tu lo veda o no. All’effort di default il modello spende molti più token per pensare che per rispondere, e quei reasoning token vengono fatturati alla tariffa piena di $7.50/M di output:

Lo schema da interiorizzare è questo: una risposta fattuale da due token si porta comunque dietro 69 token di ragionamento, e il paragrafo da 120 parole ha speso 30 volte più token a pensare che a scrivere. I reasoning token sono dettagliati in completion_tokens_details.reasoning_tokens, quindi puoi vederne il conteggio, ma mai il contenuto. Gemini non restituisce alcun riepilogo del thinking né alcuna traccia: l’estremo più chiuso dello spettro che abbiamo mappato nel nostro studio sull’anatomia dell’uso dei token, dove Kimi K3 restituisce l’intera catena di ragionamento e GPT-5.6 un riepilogo. La sezione successiva riguarda come abbassare questa spesa.

Cosa fa davvero la manopola del thinking?

È una leva di costo reale e monotona, e sulla maggior parte dei tipi di task è praticamente denaro gratis. Impostando reasoning_effort (o il nativo thinking_config.thinking_level) su minimal i reasoning token sono scesi a zero e il costo per task è calato del 91–97%:

La manopola è concreta e i valori accettati sono minimal, low, medium (il default) e high; nei nostri test ogni gradino ha comprato in modo monotono più reasoning (minimal 0 token, low ~180, medium ~530, high ~650). L’unica cosa che minimal non può fare è ragionare, e l’aritmetica multi-step ne ha bisogno: costretto a rispondere in modo secco al problema testuale delle matite e delle borse, il modello ha sbagliato tutte e tre le volte, con risposte errate sparse invece di un singolo errore sistematico. Su retrieval, classificazione, formattazione e domande a singolo step, minimal ha mantenuto l’accuratezza e ha tagliato il conto di un ordine di grandezza.

La regola pratica rispecchia quanto trovato su Kimi K3: minimal è un default difendibile per estrazione, lookup e formattazione, ed è un autogol per qualsiasi cosa richieda passaggi intermedi. Impostalo per singola route, non globalmente, e verifica l’accuratezza sui tuoi task prima di usarlo su uno che richiede molto reasoning.

Due forme di produzione ad alto volume rendono il tutto concreto: sia l’output strutturato che il function calling consumano reasoning al default, ed entrambi si possono eseguire in sicurezza con minimal. Un’estrazione vincolata da schema (response_format con uno schema JSON) ha fatturato 337 reasoning token al default restituendo JSON valido; con minimal ha fatturato zero reasoning, ha comunque restituito JSON conforme allo schema ed è costato 9 volte meno. Una function call si è comportata allo stesso modo: 74 reasoning token e una chiamata get_weather(city) corretta al default, contro zero reasoning e la stessa chiamata corretta con minimal, 4 volte più economica. Sono task a singolo step travestiti da “strutturati”, e il modello non ha bisogno di ragionare per arrivare a un campo che gli è stato detto di riempire. Quindi se il tuo traffico è estrazione o tool routing, minimal è quasi denaro gratis.

Regge la promessa del “17% di token di output in meno”?

Dipende dal carico di lavoro, e il modo in cui i risultati si dividono è istruttivo. Al lancio Google ha presentato 3.6 Flash come un modello che consuma circa il 17% di token di output in meno rispetto a 3.5 Flash sull’Artificial Analysis Index (fino al 65% su singole valutazioni agentiche). Abbiamo fatto girare entrambi i modelli su due dei nostri banchi di prova e abbiamo ottenuto segni opposti:

Sui task brevi orientati al reasoning la promessa non solo si è confermata, ma ha superato il dato dichiarato: l’output totale è calato del 19%, vicino al 17% di Google, e il calo è arrivato quasi tutto dal thinking, non dalla risposta. Separando i token di output in una riesecuzione appaiata dei due modelli, la risposta visibile si è ridotta solo del 4%, mentre il reasoning è calato del 19%, concentrato nei task di matematica e scrittura dove 3.6 arriva allo stesso risultato con meno deliberazione. È questo il meccanismo dietro il benchmark: sul lavoro che si appoggia al budget di thinking, 3.6 è davvero più efficiente a parità di risposta.

Sul traffico agentico multi-turn il segno si inverte: 3.6 ha consumato circa il 9% di output in più rispetto a 3.5 sull’intera suite. Il guadagno di efficienza sta nella fase di reasoning, e i loop agentici spendono proporzionalmente meno del loro budget lì, quindi c’è meno da risparmiare e i turni leggermente più lunghi di 3.6 prevalgono. In entrambi i casi la spesa cala, perché i due effetti si sommano in modo diverso: i task orientati al reasoning risparmiano sia sui token sia sul taglio di tariffa da $9 a $7,50 (−32%), mentre il traffico agentico risparmia solo sul prezzo (−6%). La sintesi onesta è che il “17% di token di output in meno” è reale dove il thinking domina l’output e si inverte dove non lo domina: misura il tuo mix invece di dare per buono il dato dichiarato, e ricorda che la manopola della sezione precedente sposta l’ago molto più del salto di versione.

La finestra di contesto da 1M è reale?

Sì, e quando fallisce lo fa in modo rumoroso, non silenzioso. Abbiamo piazzato un ago di recall all’inizio di prompt di dimensioni crescenti: veniva ancora recuperato correttamente a 972K token di input, e un prompt oltre il limite restituiva un pulito 400 input token count exceeds the maximum invece di scartare contenuto in silenzio. Vale la pena dirlo perché non tutti i modelli “1M-context” sul mercato servono davvero la finestra che pubblicizzano. Una nota per chi vuole riprodurre il test: riempi con filler vario e a forma di frase, perché un prompt costruito da un singolo token ripetuto spingeva il modello in un delirio degenerato ben prima del limite di dimensione.

Il prompt caching è automatico e rispetta le specifiche sul numero che conta. Google documenta un minimo di 4.096 token per il context caching sui modelli Flash, e la nostra scansione è finita esattamente lì: i prefissi pari o inferiori a ~2,1K non sono mai stati messi in cache, gli hit sono iniziati intorno ai 4,1K token, e ogni hit lasciava fuori dalla cache circa gli ultimi 2,1K, dopo un warm-up di 5-8 chiamate. L’input in cache costa $0,15/M, uno sconto di 10x rispetto alla tariffa fresh di $1,50. Vale la pena dirlo chiaro perché è il caso rassicurante: a differenza di alcuni modelli che abbiamo misurato, i cui numeri dichiarati esagerano rispetto a quanto l’endpoint fornisce davvero, sia il floor di cache sia la finestra da 1M di Gemini 3.6 Flash fanno quello che dice la documentazione. Il caching conviene comunque solo con prefissi davvero lunghi e stabili, e nota che i tier Flash supportano solo il caching automatico (implicito), non l’API di cached-content esplicita: non puoi quindi fissare manualmente un documento grande e riusarlo sotto il floor.

Dove si colloca Gemini 3.5 Flash-Lite?

Flash-Lite è il tier a costo prevedibile. Non spende mai token di reasoning in modo silenzioso, quindi la fattura corrisponde uno a uno all’output visibile. Sullo stesso problema di matematica a più passaggi, Flash-Lite ha fatturato 0,00057 $ contro i 0,00368 $ di default di 3.6 Flash, circa 6 volte in meno, e ha svolto il calcolo alla luce del sole invece che in un campo di reasoning nascosto. A 0,30 $/M in input e 2,50 $/M in output è il default giusto per lavoro single-step ad alto volume e sensibile alla latenza; passa a 3.6 Flash quando un task ha bisogno del reasoning che la manopola può reintrodurre. Il tokenizer è invariato non solo tra i tre nuovi modelli, ma fino a Gemini 2.5 Flash: conteggi di token identici su inglese, cinese, giapponese, coreano e Python in ogni generazione che abbiamo verificato, così i budget per lingua costruiti per 2.5 valgono anche per 3.6 senza rifare la baseline.

FAQ

Si può disattivare completamente il reasoning su Gemini 3.6 Flash?

reasoning_effort: "minimal" (o thinking_level: "minimal") ha azzerato i token di reasoning nei nostri test ed è il fondo della manopola; i valori accettati sono minimal, low, medium e high. Non esiste uno stato “disabled” separato, e i tentativi di disattivare del tutto il reasoning vengono rifiutati a monte. Quindi minimal è il minimo possibile, e per i task single-step è già abbastanza basso.

Perché la mia fattura Gemini è più alta di quanto suggerisca la risposta visibile?

Perché i token di reasoning vengono fatturati alla tariffa piena dell’output e non fanno parte del testo che ricevi. Una risposta di due token può portarsi dietro da decine a migliaia di token di reasoning fatturati; leggi completion_tokens_details.reasoning_tokens (oppure ricava total_tokens − prompt − completion) per vedere il costo reale dell’output, e abbassa la manopola dove il task lo consente.

Gemini 3.6 Flash o Claude Haiku 4.5?

Occupano lo stesso slot fast-tier a prezzi simili, e la scelta dipende dal carico di lavoro, non da un vincitore unico. Dal nostro punto di vista sui costi, la manopola del thinking di 3.6 Flash è il fattore discriminante: minimal lo rende un ordine di grandezza più economico sul traffico single-step, mentre il suo default spende reasoning che Haiku 4.5, a 1 $/5 $, non spende. I benchmark pubblicati danno a Haiku 4.5 il vantaggio sulla profondità nel coding e a 3.6 Flash il primato su matematica e prezzo grezzo per token; scegli in base a com’è fatto il tuo traffico, e misura entrambi sui tuoi task prima di decidere.

Gemini 3.6 Flash è più economico di 3.5 Flash?

Sì, in ogni carico di lavoro che abbiamo misurato, anche se di quanto dipende dalla forma. L’output è sceso da 9 $/M a 7,50 $/M, e sui task brevi con molto reasoning 3.6 ha anche speso meno token di output, quindi il costo è calato di circa il 32%; sul traffico agent ha speso qualche token in più e il risparmio è arrivato dal solo taglio della tariffa, circa il 6%. In ogni caso è più economico; migra e rimisura il tuo mix. Per la scomposizione del costo per token tra famiglie di modelli, vedi il nostro studio sull’anatomia dell’uso dei token.

Misurato il 2026-07-24 su gemini-3.6-flash, gemini-3.5-flash e gemini-3.5-flash-lite tramite il gateway Synthorai; conteggi di token della task-matrix e dell’agent-suite dai record di utilizzo per chiamata, risultati della manopola effort da un’ablazione salted a cinque task (n=3 per cella), test su contesto e cache da needle-recall e prefix sweep. I conteggi di accuratezza usano task con una singola risposta verificabile. Prezzi e comportamento possono cambiare; verifica sui tuoi record di utilizzo.

← Torna al blog