Gemini 3.6 Flash: il selettore del reasoning che fa variare i costi di 30x (misurato)

Gemini 3.6 Flash fattura i token di reasoning oltre a quelli della risposta, e puoi controllarne la quantità per ogni richiesta. Sullo stesso task di scrittura da 120 parole, l’impostazione predefinita è costata $0.03316, mentre minimal è costata $0.00110: una differenza di 30x per un output che un lettore non saprebbe distinguere. Questo selettore è il fattore più importante per controllare i costi del modello, ma nasconde un rischio preciso. Gemini 3.6 Flash è diventato generalmente disponibile il 2026-07-21 al prezzo di $1.50 per milione di token di input e $7.50 per milione di token di output, contro i $9 di 3.5 Flash. È stato rilasciato insieme a Gemini 3.5 Flash-Lite e a 3.5 Flash Cyber, ottimizzato per la sicurezza; in questo articolo misuriamo i due tier general purpose, 3.6 Flash e Flash-Lite.

TL;DR

• reasoning_effort: "minimal" ha ridotto il costo per chiamata del 91-97% rispetto all’impostazione predefinita, con una differenza di 30x su un task da 120 parole. Non ha inciso sui task single-step, con output strutturato o tool calling, ma ha portato l’accuratezza nella matematica multi-step da 3/3 a 0/3.
• Il “17% di token di output in meno” dichiarato da Google dipende dal workload: sui nostri task con molto reasoning i token sono diminuiti del 19% e il costo del 32%; nella suite agentica i token sono aumentati del 9%, ma il costo è sceso del 6%.
• La finestra di contesto da 1M è reale: il modello ha recuperato correttamente un’informazione a 972K token. Anche il prompt caching rispetta esattamente la soglia minima di 4,096 token pubblicata da Google. Le specifiche corrispondono ai risultati, a differenza di alcuni modelli con “contesto da 1M” che non raggiungono quanto dichiarato.

Tutte le misure riportate di seguito sono state raccolte il 2026-07-24 tramite il gateway Synthorai. Per evitare hit della cache, i prompt ripetuti includevano un salt; ogni valore è verificabile nei record di utilizzo grezzi.

Quanto costa un task con Gemini 3.6 Flash e le impostazioni predefinite?

Il reasoning domina il costo dell’output e viene fatturato anche se non è visibile. Con il livello predefinito, il modello usa molti più token per ragionare che per rispondere. Questi token vengono fatturati alla tariffa piena dell’output, pari a $7.50/M:

Il dato da tenere a mente è questo: una risposta fattuale di due token ha richiesto comunque 69 token di reasoning, mentre per il paragrafo da 120 parole il modello ha usato per ragionare 30x più token di quanti ne abbia usati per scrivere. I token di reasoning sono indicati separatamente in completion_tokens_details.reasoning_tokens, quindi puoi conoscerne il numero, ma non il contenuto. Gemini non restituisce né un riepilogo né una traccia del ragionamento. Tra i modelli analizzati nel nostro studio sull’anatomia dell’utilizzo dei token, è l’approccio più chiuso: Kimi K3 restituisce l’intera chain of thought, mentre GPT-5.6 ne fornisce un riepilogo. Vediamo ora come ridurre questa spesa.

Cosa fa davvero il selettore del reasoning?

È una leva di costo reale e monotona e, per la maggior parte dei task, consente di risparmiare senza conseguenze. Impostando reasoning_effort oppure il parametro nativo thinking_config.thinking_level su minimal, i token di reasoning sono scesi a zero e il costo di ogni task è diminuito del 91-97%:

I valori accettati sono minimal, low, medium (predefinito) e high. Nei nostri test, ogni livello ha aumentato progressivamente il reasoning: 0 token con minimal, circa 180 con low, circa 530 con medium e circa 650 con high. minimal, però, non permette al modello di ragionare, e l’aritmetica multi-step ne ha bisogno. Quando gli abbiamo imposto di rispondere in modo conciso al problema di matite e sacchetti, il modello ha sbagliato tutte e tre le volte. Le risposte errate erano diverse tra loro, quindi non si trattava di un singolo errore sistematico. Nei task di retrieval, classificazione, formattazione e nelle domande single-step, minimal ha mantenuto l’accuratezza riducendo il costo di un ordine di grandezza.

La regola pratica coincide con quanto avevamo osservato su Kimi K3: minimal è un’impostazione predefinita ragionevole per estrazione, lookup e formattazione, ma è pericolosa per qualsiasi task che richieda passaggi intermedi. Configurala per singola route, non a livello globale, e verifica l’accuratezza sui tuoi task prima di usarla in produzione per workload con molto reasoning.

Due pattern molto comuni in produzione mostrano concretamente il vantaggio: sia l’output strutturato sia il function calling consumano token di reasoning con l’impostazione predefinita, ma possono essere eseguiti senza problemi con minimal. Un’estrazione vincolata da schema, tramite response_format e uno schema JSON, ha fatturato 337 token di reasoning con l’impostazione predefinita e ha restituito JSON valido. Con minimal non ha fatturato alcun token di reasoning, ha comunque prodotto JSON valido e conforme allo schema ed è costata 9x meno. Il function calling si è comportato allo stesso modo: con l’impostazione predefinita ha usato 74 token di reasoning e generato correttamente la chiamata get_weather(city); con minimal ha prodotto la stessa chiamata corretta senza token di reasoning, a un costo 4x inferiore. Sono task single-step presentati come “strutturati”: per compilare un campo indicato esplicitamente, il modello non ha bisogno di ragionare. Se il tuo traffico consiste soprattutto in estrazione o tool routing, minimal offre quindi un risparmio quasi gratuito.

Il “17% di token di output in meno” trova riscontro nei test?

Dipende dal workload, e la differenza tra i casi è significativa. Al lancio, Google ha dichiarato che 3.6 Flash usa circa il 17% di token di output in meno rispetto a 3.5 Flash nell’Artificial Analysis Index, arrivando fino al 65% in meno in singole valutazioni agentiche. Abbiamo eseguito entrambi i modelli su due dei nostri testbed e ottenuto risultati di segno opposto:

Sui task brevi con molto reasoning, non solo abbiamo replicato il dato dichiarato, ma lo abbiamo superato: l’output totale è diminuito del 19%, vicino al 17% di Google, e quasi tutto il risparmio è arrivato dal reasoning, non dalla risposta. In una nuova esecuzione affiancata dei due modelli, abbiamo separato i token di output: quelli della risposta visibile sono diminuiti solo del 4%, mentre quelli di reasoning sono scesi del 19%. La riduzione si è concentrata nei task matematici e di scrittura, dove 3.6 raggiunge lo stesso risultato con meno elaborazione. È questo il meccanismo alla base del benchmark: nei workload che sfruttano molto il budget di reasoning, 3.6 è effettivamente più efficiente a parità di risposta.

Sul traffico agentico e multi-turn il risultato si inverte: nell’intera suite, 3.6 ha usato circa il 9% di token di output in più rispetto a 3.5. Il guadagno di efficienza si concentra nella fase di reasoning; i loop agentici vi destinano una quota proporzionalmente minore del budget, quindi c’è meno margine di risparmio e prevalgono i turn leggermente più lunghi di 3.6. La fattura diminuisce comunque, perché i due fattori si combinano in modo diverso: i task con molto reasoning risparmiano sia sui token sia sulla riduzione della tariffa da $9 a $7.50, per un totale del 32%; il traffico agentico risparmia solo grazie al prezzo, con un calo del 6%. In sintesi, il “17% di token di output in meno” è reale quando il reasoning domina l’output, ma si inverte negli altri casi. Misura il tuo mix di traffico invece di applicare il dato generale. Inoltre, il selettore descritto nella sezione precedente incide molto più del passaggio da una versione all’altra.

La finestra di contesto da 1M è reale?

Sì, e oltre il limite il modello restituisce un errore esplicito invece di fallire silenziosamente. Abbiamo inserito un’informazione da recuperare all’inizio di prompt di dimensioni crescenti: il modello l’ha richiamata correttamente anche con 972K token di input. Superato il limite, ha restituito un chiaro 400 input token count exceeds the maximum invece di eliminare contenuto senza segnalarlo. Il dato conta perché non tutti i modelli pubblicizzati con un “contesto da 1M” espongono davvero l’intera finestra dichiarata. Per riprodurre il test, usa filler vari e con una struttura simile a frasi: un prompt composto dalla ripetizione di un unico token ha portato il modello a produrre testo incoerente molto prima di raggiungere il limite.

Il prompt caching è automatico e rispetta la specifica sul valore più importante. Google dichiara una soglia minima di 4,096 token per il context caching sui modelli Flash, e i nostri test hanno rilevato esattamente lo stesso limite: i prefissi fino a circa 2.1K token inclusi non venivano mai messi in cache; gli hit iniziavano intorno a 4.1K token e, dopo un warm-up di 5-8 chiamate, lasciavano fuori dalla cache circa gli ultimi 2.1K. La lettura dell’input dalla cache costa $0.15/M, 10x meno della tariffa di $1.50 per l’input non memorizzato. È un risultato rassicurante: a differenza di altri modelli che abbiamo misurato, dove i valori pubblicizzati sovrastimavano le capacità effettive dell’endpoint, sia la soglia minima della cache sia la finestra da 1M di Gemini 3.6 Flash corrispondono alla documentazione. Il caching conviene comunque solo per prefissi davvero lunghi e stabili. I tier Flash supportano inoltre soltanto il caching automatico, o implicito, e non l’API per i contenuti memorizzati esplicitamente. Non puoi quindi fissare manualmente in cache un documento voluminoso e riutilizzarlo al di sotto della soglia.

Qual è il ruolo di Gemini 3.5 Flash-Lite?

Flash-Lite è il tier dal costo prevedibile. Non usa mai token di reasoning nascosti, quindi la fattura segue direttamente l’output visibile. Sullo stesso problema matematico multi-step, Flash-Lite è costato $0.00057, contro i $0.00368 di 3.6 Flash con le impostazioni predefinite: circa 6x meno. Inoltre, ha mostrato lo svolgimento nella risposta invece di inserirlo in un campo di reasoning nascosto. Con prezzi di $0.30/M per l’input e $2.50/M per l’output, è la scelta predefinita adatta a task single-step, ad alto volume e sensibili alla latenza. Passa a 3.6 Flash quando il task richiede il reasoning che il selettore permette di aggiungere. Il tokenizer non è cambiato né tra i tre nuovi modelli né rispetto a Gemini 2.5 Flash: in tutte le generazioni verificate abbiamo ottenuto conteggi identici per inglese, cinese, giapponese, coreano e Python. I budget per lingua definiti su 2.5 restano quindi validi su 3.6 senza dover ricalcolare la baseline.

FAQ

È possibile disattivare completamente il reasoning su Gemini 3.6 Flash?

Nei nostri test, reasoning_effort: "minimal" oppure thinking_level: "minimal" ha portato a zero i token di reasoning ed è il livello più basso disponibile. I valori accettati sono minimal, low, medium e high. Non esiste uno stato separato per disabilitarlo, e i tentativi di forzarne la disattivazione vengono rifiutati a monte. Minimal è quindi il minimo consentito e, per i task single-step, è sufficiente.

Perché la fattura di Gemini è più alta di quanto faccia pensare la risposta visibile?

Perché i token di reasoning vengono fatturati alla tariffa piena dell’output, ma non compaiono nel testo restituito. Una risposta di due token può includere da decine a migliaia di token di reasoning fatturati. Controlla completion_tokens_details.reasoning_tokens, oppure calcola total_tokens − prompt − completion, per conoscere il costo reale dell’output. Riduci il livello di reasoning quando il task lo consente.

Gemini 3.6 Flash o Claude Haiku 4.5?

Occupano entrambi la fascia dei modelli veloci, con prezzi simili. La scelta dipende dal workload, non c’è un vincitore assoluto. Dal punto di vista dei costi, il selettore del reasoning distingue 3.6 Flash: minimal lo rende un ordine di grandezza più economico sul traffico single-step, mentre con l’impostazione predefinita consuma token di reasoning che Haiku 4.5, al prezzo di $1/$5, non usa. Nei benchmark pubblicati, Haiku 4.5 è superiore nei task di coding più complessi, mentre 3.6 Flash prevale in matematica e nel prezzo grezzo per token. Scegli in base alla composizione del tuo traffico e misura entrambi sui tuoi task prima di decidere.

Gemini 3.6 Flash è più economico di 3.5 Flash?

Sì, in tutti i workload che abbiamo misurato, anche se l’entità del risparmio dipende dal tipo di traffico. Il prezzo dell’output è sceso da $9/M a $7.50/M. Nei task brevi con molto reasoning, 3.6 ha anche usato meno token di output, riducendo il costo di circa il 32%. Nel traffico agentico ha consumato leggermente più token, quindi il risparmio, pari a circa il 6%, è derivato solo dalla riduzione della tariffa. In entrambi i casi costa meno: migra e misura nuovamente il tuo mix. Per una scomposizione del costo per token tra diverse famiglie, consulta il nostro studio sull’anatomia dell’utilizzo dei token.

Misurazioni effettuate il 2026-07-24 su gemini-3.6-flash, gemini-3.5-flash e gemini-3.5-flash-lite tramite il gateway Synthorai; i conteggi dei token della matrice di task e della suite agentica provengono dai record di utilizzo di ogni chiamata, mentre i risultati dei livelli di reasoning derivano da un’ablazione con salt su cinque task (n=3 per cella). Le misure del contesto e della cache provengono da test di needle recall e scansioni dei prefissi. I conteggi di accuratezza riguardano task con una sola risposta verificabile. Prezzi e comportamento possono cambiare; verifica sempre i tuoi record di utilizzo.

← Torna al blog