Il 19 maggio 2026, al Google I/O, DeepMind ha rilasciato Gemini 3.5 Flash in GA con una model card che fa una cosa che i modelli tier Flash non dovrebbero fare: guida MCP Atlas all'83,6%, 4,5 punti sopra Opus 4.7 e 8,3 punti sopra GPT-5.5 [1][2]. Terminal-Bench 2.1 si ferma al 76,2%, CharXiv Reasoning all'84,2%. Nessuno di questi numeri è da Pro tier dell'anno scorso; sono maggio 2026, e sono il vertice frontier sui benchmark agentici.
Pricing: 1,50per1Mdiinput,9,00 per 1M di output, 0,15per1Mdiinputcacheato[1].Iltassocacheatoeˋlavocedafissare.Opus4.7staa15/$75. Sulle chiamate non cacheate Flash costa 10× meno in input e 8,3× meno in output. Sull'input cacheato il gap si allarga a circa 100× se confronti con Opus non cacheato, o circa 60× se confronti con il prezzo cacheato di Opus stesso. Stesso context window da 1M. Circa 4× più veloce end-to-end (>280 token/s).
Il problema: i prompt che hai scritto per Opus, GPT-5.5 o anche Gemini 3.1 Pro per la maggior parte gireranno, ma quasi nessuno catturerà il guadagno agentico o lo sconto cache. Il modello di reasoning è cambiato, il budget di reasoning di default si è spostato, e i preamboli chain-of-thought ora sono attivamente controproducenti. Ho fatto girare la migrazione su una manciata di workload agentici su cui mi appoggio e ho ri-scorato i prompt riscritti; le riscritture strutturali si compongono e i risparmi sono reali.
Questo articolo passa in rassegna cosa è stato rilasciato, le sei riscritture di prompt che catturano il guadagno vero, e cosa si è rotto durante la migrazione.
Migrazione Gemini 3.5 Flash featured
Cosa è Stato Rilasciato il 19 Maggio
Tre cose contano per il prompt engineering, in quest'ordine:
Revisione del modello di reasoning. Il parametro thinking_budget che potresti aver usato su Gemini 3.1 non c'è più. Il nuovo parametro è thinking_level con tre valori: low, medium, high. Il default per Gemini 3.5 Flash è sceso da high (il de-facto default Gemini 3.1 per l'agentico) a medium [3]. I prompt esistenti che non passavano un valore esplicito ora girano con un budget di reasoning inferiore a prima. La qualità di output sui prompt multi-step può calare silenziosamente se non controlli.
Lo sconto cache come nuovo centro di gravità. L'input cacheato a $0,15/M è uno sconto del 90% sul prezzo standard di input. Su ogni workload agentico multi-turno, il prefisso cacheato (system prompt più schema tool stabile più prefisso conversazionale) è ora responsabile della maggior parte dei token fatturati. Progettare il prompt attorno a un prefisso cacheabile non è più un "nice to have"; è la singola leva di costo più importante disponibile.
Le primitive agentiche fanno un salto. Gemini 3.5 Flash dichiara esecuzione parallela di sub-agent, workflow multi-step a lungo orizzonte e tool calling affidabile dentro un context da 1M token. Il lead su MCP Atlas è il titolo; la conseguenza pratica è che i prompt di orchestrazione che trattano le tool call come eccezioni sprecano cicli. Il modello si aspetta di chiamare strumenti e si aspetta che tu lo lasci pianificare l'ordine delle chiamate.
Il resto del keynote I/O (Gemini 3.5 Pro in test, Gemini Omni per video, Gemini Spark) è a valle di questi tre per un indie dev o un piccolo team. Flash è il cavallo da soma e la voce di costo.
Perché Flash È il Target Giusto Adesso
Tre percorsi di migrazione competono per l'attenzione in questo momento: DeepSeek V4 (10× più economico di Opus su chat, coperto in S9), GPT-5.5 Instant (il nuovo default ChatGPT, coperto in S12) e Gemini 3.5 Flash (questo articolo). Non sono intercambiabili.
Target
Più forte su
Più debole su
Migliore per
DeepSeek V4
Chat completion, costo grezzo
Tool calling, agentico frontier
Completion one-shot, batch job
GPT-5.5 Instant
Bilancio qualità/latenza, ecosistema ChatGPT
Agenti tool-using (Codex a parte), prezzo
App chat user-facing
Gemini 3.5 Flash
Agentico / tool use, multimodale, prezzo cache
Ecosistema nuovo, community più piccola
Agenti multi-step, MCP server, pipeline doc-heavy
Se il tuo workload è "un agente che usa strumenti, legge documenti e chiama 3-7 tool per turno", Gemini 3.5 Flash è il nuovo default. Se stai facendo girare un classificatore single-turn o una chat box, DeepSeek V4 vince ancora sul costo grezzo e GPT-5.5 Instant vince ancora sull'integrazione. Scegli per forma del workload, non per fedeltà al brand.
Vuoi sapere quanto sono efficaci i tuoi prompt? Prompt Score li analizza su 6 criteri.
Il fatto singolo che ha pesato sulla mia decisione di migrazione: Opus 4.7 cached input costa circa 1,50/M(1015). Gemini 3.5 Flash cached input costa $0,15/M. Lo stesso sconto cache del 90% su entrambe le piattaforme, ma Flash parte 10× più economico prima della cache. Per workload dove il 70%+ dei token mensili sono prefisso system+tool cacheato, Flash costa circa 60-100× meno della stessa workload su Opus non cacheato, e perfino contro il pricing cacheato di Opus stesso il gap è dell'ordine di grandezza.
Lo Spostamento di thinking_level, in Un Diagramma
Se non fai nient'altro da questo articolo, cambia un parametro e fai ri-girare i tuoi prompt.
Cambiamento thinking level Gemini 3.5
Il modello mentale: nell'era GPT-4 e Gemini 3.1, governavi la profondità di reasoning del modello scrivendo gli step nel prompt ("ragiona passo passo", "prima fai X, poi Y"). Il modello non poteva pianificare; pianificavi tu per lui.
Nell'era Gemini 3.5 Flash, il modello ha la sua manopola di budget di pianificazione. Imposti la manopola (thinking_level: low|medium|high) e scrivi un prompt più corto che nomina la missione invece della ricetta. Il modello spende il suo budget sul suo piano. Se scrivi anche la ricetta nel prompt, il modello spende il budget due volte: una volta per parsare la tua ricetta e una volta per il suo piano. La qualità cala, la latenza sale, il costo sale.
Il default che si è mosso da high a medium è la regressione silenziosa. I prompt di produzione che prima giravano con high di default ora girano con medium, senza alcun warning di migrazione. Se la qualità di output sui prompt multi-step sembra OK ma leggermente degradata dopo l'upgrade, è quasi certamente per questo.
Sei Riscritture che Ho Fatto Durante la Migrazione
Questi sono i sei pattern dove i miei prompt vecchi costavano più performance contro Gemini 3.5 Flash. Ogni before/after è illustrativo.
Ragiona passo passo. Prima identifica le tabelle rilevanti. Poi scrivi
la SQL. Poi spiega il risultato in italiano piano.
Dopo:
generation_config = {"thinking_level": "high"}
Dato lo schema nel system prompt, rispondi alla domanda dell'utente
con una query SQL e una frase di interpretazione del risultato.
Il modello pianifica gli step. Tu imposti la profondità. I preamboli verbose chain-of-thought competono con il pianificatore del modello e gonfiano i token di output senza aggiungere accuratezza.
Riscrittura 2: Ri-controlla ogni prompt che si appoggiava al vecchio default
Se non hai mai passato thinking_budget o thinking_level esplicitamente su Gemini 3.1, il tuo prompt girava di fatto con high. Il default di Gemini 3.5 Flash è medium. I prompt dove la qualità di output conta più della latenza vanno alzati a high esplicitamente. I prompt dove la latenza conta più dell'ultimo 5% di qualità vanno impostati a low per il risparmio.
Il mio pattern di audit: prendi i prompt di produzione che chiami più spesso, ri-scoreli con thinking_level: low, poi medium, poi high. Scegli il livello più basso dove lo score non cala. Tre dei miei cavalli da soma andavano bene con low e uno aveva bisogno di high. Il default medium era sbagliato in entrambe le direzioni.
Riscrittura 3: Sostituisci le ricette step-by-step con dichiarazioni di missione
Prima:
Il tuo lavoro è:
1. Leggere la richiesta dell'utente.
2. Determinare quali strumenti sono rilevanti.
3. Chiamare gli strumenti in quest'ordine esatto: search_docs, poi summarize, poi format_output.
4. Restituire JSON con campi: result, confidence, sources.
Dopo:
Missione: rispondi alla richiesta dell'utente usando gli strumenti disponibili.
Strumenti: search_docs, summarize, format_output. Chiamali nell'ordine
che la richiesta richiede.
Output: JSON {result, confidence, sources}.
Gemini 3.5 Flash pianifica la sua sequenza di tool da solo e ora batte GPT-5.5 e Opus 4.7 sui benchmark agentici proprio per questa pianificazione. Hard-codare l'ordine strappa via il guadagno. Hard-coda solo l'ordine che è un vero invariante downstream (una scrittura su database che deve avvenire dopo lo step di validazione).
Riscrittura 4: Sposta il system prompt dentro il cache breakpoint
Prima: dati dinamici e identità stabile mischiati nel system prompt, rigenerati per richiesta.
Dopo: identità stabile, ruolo, schema tool e dati di riferimento condivisi vanno nel blocco system cacheato. I dati per-richiesta (input utente, timestamp, session ID) vivono nel primo messaggio user dopo il cache breakpoint.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
La matematica: input cacheato a 0,15/M,noncacheatoa1,50/M. Se il 70% dei tuoi token mensili Gemini Flash sono prefisso cacheabile, la tua bolletta su quel workload cala di circa il 60% solo da questa riscrittura. Se sono il 90%, il calo è più vicino all'80%. È la riscrittura a più alto ROI di questo articolo.
Il corollario è la stabilità byte-level: il system prompt cacheato deve essere esattamente la stessa stringa tra richieste, altrimenti la cache salta. Niente f"Ora corrente: {now()}". Niente UUID per-richiesta per il tracing. (S11 sulle Anthropic cache diagnostics copre la stessa disciplina per Claude; la regola è identica qui.)
Riscrittura 5: Taglia le tool call che esistono per difendersi dai vecchi modelli
Prima:
Prima di rispondere, chiama sempre validate_input per verificare che
la richiesta dell'utente sia ben formata. Poi procedi.
Dopo: (nessun tool di validazione, regola di validazione spostata in una decisione nel prompt)
Se nella richiesta manca un parametro obbligatorio, chiedi all'utente
una volta invece di chiamare strumenti.
L'affidabilità di Gemini 3.5 Flash sul tool calling è migliorata abbastanza che il pattern difensivo "valida tutto prima", scritto per l'era GPT-4 / Gemini 3.1 quando i modelli chiamavano tool con argomenti malformati, ora è puro overhead. Ogni tool call non necessaria costa un round trip e una porzione di token di output. La guidance di Google è esplicita: riduci le tool call inutili abbassando prima thinking_level, poi tagliando le difese "fai sempre X" del prompt [3].
Riscrittura 6: Alza media_resolution_high per i prompt su documenti densi
Se il tuo prompt manda un PDF o un deck di slide via Gemini API, la risoluzione media di default su 3.5 Flash è tarata per documenti generici. Materiale di riferimento denso (paper di ricerca, report finanziari, qualunque cosa pesante di tabelle e testo piccolo) beneficia di media_resolution_high. Il costo sono più token di input; il guadagno sono meno allucinazioni e meno loop di ri-estrazione downstream.
Questo è workload-specifico. Testa prima di accenderla universalmente. Per i miei prompt doc-heavy la risoluzione più alta si è ripagata; per i prompt chat che ogni tanto citano un PDF, sarebbe stata eccessiva.
Cosa si è Rotto Quando Ho Migrato
Tre workload miei hanno incontrato sorprese durante la migrazione. Il pattern vale la segnalazione.
Workload A: un agente research assistant. Ha funzionato perfettamente al primo run. Qualità percepita come storta dopo qualche ora di uso. Il problema: il prompt girava con il default Gemini 3.1 thinking_budget: high, e il nuovo default thinking_level: medium era appena sufficiente a smorzare il reasoning sulle domande più lunghe. Aggiungere thinking_level: "high" esplicitamente ha ripristinato il vecchio comportamento. Lezione: ri-controlla ogni prompt che non passava il parametro esplicitamente.
Workload B: una pipeline di review contratti. Throughput dimezzato. Causa radice: avevo avvolto le tool call in una guardia "valida prima" che faceva partire tre tool call pre-flight per turno. Su Opus 4.7 quelle guardie erano difese necessarie contro chiamate occasionali malformate; su Flash bruciavano round trip senza beneficio. Rimuovere le guardie e fidarsi del modello ha riportato il throughput sopra la baseline vecchia.
Workload C: un agente di triage inbox. Cache hit rate inizialmente vicino a zero. Causa radice: non avevo spostato i dati dinamici per-richiesta fuori dal system prompt. La stringa cambiava a ogni richiesta per via di un timestamp dentro per la telemetria. La cache invalidava a ogni turno. Spostare il timestamp dentro il primo messaggio user ha portato il cache hit rate intorno al 92% entro un'ora.
Tre rotture diverse, tutte catturate dalle riscritture sopra. Nessuna sembrava un bug Gemini. Tutte erano assunzioni cotte nei vecchi prompt che non si applicavano più.
Matrice Decisionale: Migrare a Flash, Restare su Opus o Spaccare
Flash non è il target giusto per ogni workload. La decisione si poggia su forma dell'agente e utilizzo della cache, non sui benchmark da soli.
Matrice decisionale migrazione Gemini 3.5 Flash
Migra a Gemini 3.5 Flash se...
Resta su Opus 4.7 o spacca se...
Workload è agentico multi-turno con 3+ tool call per sessione
Workload è completion one-shot o classificazione single-turn
50%+ dei token mensili stanno in un prefisso cacheabile stabile
Ogni richiesta ha un nuovo system prompt o tool che cambiano in fretta
Stai costruendo MCP server o pipeline doc-heavy
Hai bisogno di feature Claude-specifiche (artifact, code execution)
Il costo è il vincolo binding o la latenza conta
La qualità di output su long-form creative writing è il vincolo binding
Puoi ri-testare e ri-scorare i prompt migrati
Sei pinnato a uno snapshot Opus per compliance
Se tre o più voci della colonna sinistra si applicano a un dato workload, la migrazione è un pomeriggio e i risparmi si compongono dal giorno uno. Se sono due o meno, lascialo sul modello corrente e torna a guardare solo quando prezzo o qualità si muovono.
Cosa Significa per Solo Dev e Team Piccoli
Tre asporti da una settimana facendo girare entrambe le versioni.
La tua bolletta Opus è ora opzionale. Se hai un workload agentico che gira su Opus 4.7 a maggio 2026 e non hai ancora guardato Gemini 3.5 Flash, stai pagando un premio di brand di 8-10× prima dello sconto cache. La migrazione è l'ora ad alto impatto che spenderai questo mese se la bolletta su quel workload conta qualcosa.
Il design della cache è la leva vera. I numeri di benchmark in apertura sono carini, ma la riga che conta sulla fattura è $0,15 per 1M di token cacheati. Tratta il prefisso cacheato come un artefatto compilato. Stessa disciplina di S8 e S11 su Claude. La regola generalizza: i prompt di produzione a maggio 2026 sono byte-stable by design oppure lasciano soldi sul tavolo.
Testa il thinking level, non tirare a indovinare. Il default si è mosso da high a medium senza un warning di upgrade. Ogni prompt che non passava il parametro esplicitamente sta girando con un budget di reasoning diverso da quello che aveva la settimana scorsa. Ri-scora prima di shippare. Il costo di testare tre valori sui prompt che usi di più è un pomeriggio corto; il costo di shippare un agente silenziosamente degradato è una segnalazione cliente da rincorrere.
Se la tua bolletta AI mensile ha voci sopra i $100, la migrazione a Flash probabilmente si ripaga la prima settimana. I prompt che ne traggono di più sono quelli agentici, dove la pianificazione del modello sostituisce la ricetta che scrivevi nel system prompt.
Fonti
[1] Google DeepMind, Gemini 3.5 Flash Model Card, deepmind.google/models/model-cards/gemini-3-5-flash. Score di benchmark (MCP Atlas 83,6%, Terminal-Bench 2.1 76,2%, CharXiv Reasoning 84,2%), context window, pricing.
[3] Google AI for Developers, What's new in Gemini 3.5 Flash, ai.google.dev/gemini-api/docs/whats-new-gemini-3.5. Parametro thinking_level, cambio di default da high a medium, guidance sulla riduzione delle tool call, impostazione media_resolution_high.
Vuoi sapere quali dei tuoi prompt scoreranno peggio sui nuovi default prima di scoprirlo in produzione? Falli scorare con Keep My Prompts e guarda i 6 criteri di qualità che mappano direttamente sul pattern di riscrittura mission-first.