Costi Gemini 3.7 Flash: task 2.5-8x più economici di 3.6

Gemini 3.7 Flash costa da 2.5x a 8x meno di Gemini 3.6 Flash sugli stessi task, e solo metà del risparmio deriva dal taglio di prezzo pubblicizzato. La tariffa promozionale di $0.75 per milione di token in input e $3.75 per milione di token in output costa il 50% in meno rispetto a 3.6. Sul nostro contatore, lo stesso prompt da 6.9K token è costato esattamente la metà ($0.00529 contro $0.01057). L’altra metà è meno evidente: sugli stessi quattro task misurati, gemini-3.7-flash ha consumato dal 26% al 77% di thinking token in meno rispetto a 3.6. Abbiamo testato il modello due giorni dopo il rilascio: condizioni economiche, controlli del thinking (una posizione è sparita), incompatibilità segnalate dalla documentazione di Google e altre sottovalutate, oltre alla continuità di cache, contesto e tokenizer.

TL;DR

• Il prezzo promozionale di $0.75/$3.75 resta valido fino al 31 dicembre 2026, poi passa a $1.50/$7.50; sul nostro contatore, lo stesso prompt è costato esattamente la metà rispetto a 3.6.
• Il thinking predefinito è sceso del 26-77% rispetto a 3.6 (144 contro 384 token su un task in 5 passaggi), quindi il costo per task cala di 2.5-8x, non solo di 2x.
• L’interruttore off non esiste più: tutte le varianti per disattivarlo restituiscono un 400 (“Thinking level is unsupported”); low è ora il livello minimo.
• In un ciclo con tool su due turni, 3.7 ha dimezzato la deliberazione nel turno successivo al risultato del tool (32 contro 61 token); rifiutare una domanda senza risposta è costato 500 token a entrambi i modelli.

Quanto costa davvero Gemini 3.7 Flash?

Fino al 31 dicembre 2026 costa la metà di 3.6 e, in tutti i task misurati, usa meno della metà dei suoi token. Al lancio Google applica una tariffa promozionale di $0.75 per milione di token in input e $3.75 per milione di token in output; dal 1° gennaio 2027 torna a $1.50/$7.50, esattamente il listino di 3.6. Le letture dalla cache costano $0.075 per milione, il 10% dell’input al prezzo promozionale. Il contatore conferma il listino: lo stesso prompt da 6.9K token è costato $0.0052875 su 3.7 e $0.0105675 su 3.6, esattamente la metà.

L’effetto maggiore viene dai token che il modello non consuma più. Abbiamo eseguito gli stessi task con salt tre volte ciascuno. Di seguito, la mediana dei reasoning token e il relativo costo di output:

Al lancio, Google afferma che 3.7 “ragiona in modo più accurato”; nei nostri task, questo significa meno token, non di più. Entrambi i modelli hanno mantenuto un’accuratezza di 3/3 in tutti i casi. Combinando la tariffa dimezzata con un consumo di thinking token dimezzato o inferiore, l’upgrade riduce in pratica il costo per task del 61-88%, prima ancora della cache. C’è una sola riserva: dal 1° gennaio il prezzo torna al livello precedente, secondo lo stesso schema già visto con il prezzo promozionale di Sonnet 5.

Un tipo di task non segue questa tendenza, ed è proprio quello che nessuno mette a budget: il rifiuto. Abbiamo posto domande su cinque entità inventate, cioè un’azienda, un istituto, lo statuto di una città, una lega metallica e un premio. Entrambi i modelli hanno rifiutato di rispondere in tutti e cinque i casi, consumando più thinking token che in qualsiasi altro task misurato: mediana di 511 reasoning token su 3.7 e 494 su 3.6. Dire “non esistono informazioni al riguardo” è costato 3.5x il thinking necessario per risolvere la catena aritmetica in 5 passaggi. Le pipeline RAG che incontrano spesso dati mancanti pagano questo costo a ogni mancato riscontro. È l’unico caso in cui il vantaggio di efficienza di 3.7 scompare. Il dato ridimensiona anche un timore emerso nella settimana di lancio: alcuni reviewer hanno segnalato un tasso di allucinazioni più elevato per 3.7, ma sulle domande relative a entità inventate ha espresso riserve in 5 casi su 5, esattamente come 3.6.

Quali controlli del thinking restano disponibili su 3.7?

Tre livelli, senza off, esattamente come indicato nella documentazione: low, medium (predefinito), high. La documentazione non specifica che le scappatoie disponibili su 3.6 non funzionano più. Tutte le varianti per disattivare il thinking che abbiamo inviato, reasoning_effort: "none", "minimal", thinking_budget: 0, thinking: {"type": "disabled"}, enable_thinking: false, hanno restituito lo stesso 400 upstream: “Thinking level is unsupported: THINKING_LEVEL_MINIMAL”. Un secondo percorso di richiesta indipendente lo dice in modo ancora più esplicito: “Reasoning is mandatory for this endpoint and cannot be disabled”. Il vincolo viene quindi dal modello, non dal layer di traduzione di un client. Su 3.6-flash, misurato nello stesso batch, none e minimal continuano ad azzerare il consumo. La linea Flash adotta ora la stessa policy del tier pro: il thinking non può essere disattivato, e 3.6 è l’ultimo Flash su cui è ancora possibile farlo.

Questi sono i risultati dei livelli ancora disponibili sul task in 5 passaggi (mediana di 3 esecuzioni, tutte corrette 3/3):

Due note operative. Abbiamo verificato che il livello predefinito sia davvero medium: le esecuzioni senza configurazione hanno consumato 154 token, un valore praticamente identico ai 147 del ramo medium esplicito. Inoltre, thinking_budget è effettivamente deprecato: tutti i valori diversi da zero che abbiamo inviato (da 16 a 1,024) sono stati accettati, ma hanno prodotto lo stesso consumo di 135-138 token. Su 3.7 non hanno quindi alcun effetto, mentre 3.6 continua a interpretare i budget più bassi come off e quelli più alti come limite. Se l’integrazione con 3.6 controlla i costi tramite budget, su 3.7 bisogna scegliere un livello: l’interfaccia si riduce a questo. Per un confronto tra vendor sui controlli che hanno davvero effetto, consulta la nostra matrice dei controlli del thinking.

Quanto costa ogni passaggio di un agent?

La selezione dei tool non cambia rispetto a 3.6; a costare meno è la deliberazione tra un passaggio e l’altro. Abbiamo eseguito un ciclo su due turni con due funzioni: cercare un incidente e riavviare il servizio indicato nel risultato. Tre esecuzioni per modello:

Entrambi i modelli hanno scelto prima get_incident e poi restart_service, con 3/3 esecuzioni corrette e lo stesso numero di prompt token. La differenza emerge al secondo turno, quando 3.7 usa circa la metà dei thinking token prima di effettuare la chiamata successiva. È proprio il passaggio che un agent ripete: ai valori mediani misurati, un ciclo di 20 passaggi costa circa $0.0043 di output su 3.7 contro $0.0131 su 3.6. Il rapporto resta invariato anche dopo il ritorno ai prezzi di gennaio, perché dipende dai token, non dalle tariffe. È questo il meccanismo che permette a Google di presentare il miglioramento nei benchmark agentici anche in termini di costi: meno token di deliberazione per passaggio, moltiplicati per molti passaggi.

Il confronto con i concorrenti dipende dal benchmark e va valutato prima di migrare un coding agent. Secondo analisi indipendenti, 3.7 Flash è davanti su FrontierCode (43.6% contro 42.7% di Sonnet 5) e ottiene quasi 3x il risultato di Sonnet 5 su AutomationBench. Nella stessa analisi e nella copertura della settimana di lancio, GPT-5.6 Terra guida Terminal-bench, mentre Sonnet 5 è primo nel test sui task desktop. Sul costo minimo, invece, il vantaggio di 3.7 è netto.

Cosa si rompe passando da 3.6?

Due casi restituiscono sempre un 400, mentre altri falliscono in modo meno evidente di quanto suggerisca la documentazione. La guida alla migrazione di Google indica di rimuovere temperature, top_p, top_k, candidate_count e i turni precompilati del modello. Questi sono i risultati delle nostre misurazioni:

La differenza di comportamento è rilevante: il controllo del thinking esegue una validazione esplicita e restituisce un 400 chiaro con il valore non supportato, mentre i parametri di sampling e i limiti di output vengono accettati senza avvisi. Se la libreria client imposta temperature per impostazione predefinita, oggi non si rompe nulla. Se usa turni assistant precompilati per guidare l’output, era già incompatibile prima dell’upgrade.

Cache, contesto e tokenizer restano compatibili?

Sì, ma la cache impiega più tempo ad attivarsi. La cache implicita produce hit nelle stesse condizioni di 3.6: alla seconda chiamata con un prompt identico, 4,076 dei 6,905 token sono arrivati dalla cache, riducendo del 52% il costo della chiamata. Le letture costano il 10% dell’input alla tariffa promozionale. È però aumentato il ritardo di preparazione: 3.6 ha restituito un hit 4 secondi dopo la chiamata di priming; 3.7 non ha restituito nulla dopo 4 secondi e ha prodotto un hit dopo 30. Il traffico duplicato inviato a raffica arriva prima che la cache sia pronta; i costi di scrittura restano invece invariati.

Il modello ha accettato 708,912 token in input in una sola chiamata e ha risposto correttamente a una domanda needle, in linea con il contesto dichiarato di 1M e senza una fascia di prezzo separata per il long context. Il tokenizer testuale produce risultati identici, byte per byte, su quattro generazioni: gemini-3.1-pro-preview, 3.5-flash, 3.6 e 3.7 hanno tutti contato 50 token sullo stesso corpus misto di inglese, cinese e codice. I budget di token possono quindi essere riutilizzati senza modifiche. Gli input immagine continuano a costare 1,089 token fissi a qualsiasi dimensione in tutti i modelli Gemini che abbiamo misurato. Nessuna delle due generazioni restituisce il testo del reasoning: reasoning_content era vuoto in tutte le chiamate, quindi il thinking fatturato resta invisibile su entrambe. È una critica ricorrente anche nelle discussioni della settimana di lancio. L’output strutturato resta affidabile: json_schema in modalità strict ha restituito JSON valido e corretto in 3/3 esecuzioni, mentre reasoning_effort: "low" ha azzerato il thinking per l’estrazione, la stessa zona sicura per i task a passaggio singolo rilevata ovunque nella nostra matrice.

FAQ

Quanto costa l’API Gemini 3.7 Flash?

La tariffa promozionale fino al 31 dicembre 2026 è di $0.75 per milione di token in input e $3.75 per milione di token in output. Dal 1° gennaio 2027 torna a $1.50/$7.50, lo stesso listino di Gemini 3.6 Flash. Le letture dalla cache costano $0.075 per milione. A parità di prompt, il nostro contatore ha fatturato 3.7 esattamente la metà di 3.6.

È possibile disattivare il thinking su Gemini 3.7 Flash?

No. Tutte le varianti per disattivarlo restituiscono un 400 (“Thinking level is unsupported”). I livelli disponibili sono low, medium (predefinito) e high; nel nostro task in 5 passaggi, anche low ha consumato 133 reasoning token. Gemini 3.6 Flash resta il modello Flash più recente su cui reasoning_effort: "none" funziona, allo stesso prezzo che 3.7 avrà dopo la promozione.

Gemini 3.7 Flash costa davvero meno di 3.6 per richiesta?

Il risparmio supera il 50% pubblicizzato: sugli stessi task usa anche il 26-77% di thinking token in meno. Nei nostri test, il costo per task è sceso del 61-88% (un problema verbale in 2 passaggi è passato da $0.0020 a $0.0002). Dopo il 31 dicembre, la tariffa torna allo stesso livello di 3.6 e resta solo il risparmio dovuto al thinking.

Il codice scritto per Gemini 3.6 Flash funziona su 3.7?

Nella maggior parte dei casi. I parametri di sampling (temperature, top_p, top_k) vengono ancora accettati nonostante la documentazione indichi di rimuoverli, mentre un valore eccessivo di max_tokens viene limitato senza avvisi. Le due incompatibilità nette sono queste: i turni assistant precompilati restituiscono un 400, come già avveniva su 3.6, e tutti gli interruttori per disattivare il thinking ora restituiscono un 400. Il controllo dei costi deve quindi passare da thinking_budget ai tre livelli disponibili.

Misurazioni effettuate il 2026-08-15 tramite il gateway Synthorai, due giorni dopo il rilascio: matrice di livelli e interruttori off (7 valori di effort, 5 budget, 2 parametri off, n=3, con gemini-3.6-flash rieseguito nello stesso batch per ogni confronto), misurazione dei costi di reasoning su quattro task, output strutturato con JSON strict, test dei parametri deprecati, verifica del limite di output e accettazione di un contesto da 708K, coppie di chiamate per la cache implicita con due tempi di attesa, confronto del tokenizer su un corpus fisso e quattro generazioni Gemini, ciclo di function calling su due turni (n=3 per modello) e test di rifiuto su cinque domande relative a entità inventate. I costi in dollari dei task sono calcolati applicando ai completion token misurati la tariffa di output corrente di ciascun modello. Due risultati sono stati verificati anche su un secondo percorso di richiesta indipendente: l’accettazione di valori eccessivi di max_tokens e l’assenza di un livello off. Prezzi promozionali e date sono quelli pubblicati da Google; il comportamento potrebbe cambiare con il consolidarsi del rollout.

← Torna al blog