Google rilascia Nano Banana 2 Lite e Gemini Omni Flash agli sviluppatori, con un percorso da immagine a video in 4 secondi

I numeri sulla latenza sono un budget per il frontend, non un benchmark

La specifica di punta di Nano Banana 2 Lite è un output text-to-image in 4 secondi a 0,034$ per immagine a risoluzione 1K. Google la descrive come pensata per "ideazione rapida e pipeline di sviluppo ad alta velocità, dove la priorità è velocità e costo."

Per chi costruisce un'interfaccia intorno alla generazione, 4 secondi è il numero che decide se mostrare uno spinner o un'anteprima live. È una via di mezzo scomoda: troppo lungo per sembrare istantaneo, abbastanza breve da giustificare un'interfaccia di bozza interattiva dove l'utente modifica un prompt e rilancia più volte. Il costo conta per lo stesso motivo: a 3,4 centesimi per immagine, un'interfaccia che genera a ogni pausa di digitazione o movimento di uno slider diventa sostenibile a livello economico in un modo che con un modello premium non sarebbe.

Google la posiziona esplicitamente come sostituto diretto dell'originale Nano Banana (gemini-2.5-flash-image), dicendo agli sviluppatori che possono "sostituirlo subito." È un messaggio pensato per chi ha già integrazioni frontend esistenti, non solo per nuovi progetti.

Le Interactions API e il tetto delle tre modifiche

Il dettaglio più concreto per il frontend passa quasi inosservato: le Interactions API mantengono la cronologia della sessione e il contesto, così che "gli utenti possano accumulare fino a tre modifiche sequenziali." È un vincolo reale da progettare, non uno slogan di marketing.

L'editing conversazionale, cioè la premessa di Gemini Omni Flash, funziona solo se l'interfaccia mantiene lo stato tra i vari turni. Un limite di tre modifiche significa che l'interfaccia deve comunicare questo budget all'utente: quali modifiche sono già state applicate, quando si sta per raggiungere il limite, e come ramificare o ripartire da zero. Costruire un editor multi-turno senza mostrare questo tetto porterebbe a vicoli ciechi confusi per l'utente.

Omni Flash genera video di 10 secondi a 0,10$ al secondo, un prezzo che Google segnala essere "identico a Veo 3.1 Fast." Avere una parità di prezzo con un modello già esistente dà ai team frontend un riferimento di costo noto su cui basare il calcolo per ogni render.

Il vero prodotto che Google vende è lo schema di concatenazione

La vera magia avviene quando questi modelli vengono concatenati tra loro. Usa Nano Banana 2 Lite come modello di generazione immagini ad alta velocità, poi passa quell'immagine come riferimento a Gemini Omni Flash per animarla in un video di alta qualità.Montana Labs

Le tre app demo codificano tutte lo stesso flusso di interfaccia: genera uno still con il modello immagine veloce, poi lascia che un clic o un tasto trasformi quello still in una clip animata. Anywhere trasporta un selfie verso luoghi famosi e poi lo anima al clic; Space Lift genera ridesign di stanze e poi mostra una presentazione cinematografica al tocco; Omni product studio trasforma immagini statiche in video e-commerce.

Ognuna è un'interazione a due fasi in cui il modello economico e veloce gestisce la fase di navigazione, mentre il modello video costoso viene invocato solo quando l'utente si impegna esplicitamente. È uno schema sensato per controllare i costi in un'interfaccia media: non animi tutto, animi solo la cosa che l'utente ha scelto.

I limiti che definiscono cosa puoi rilasciare oggi

Omni Flash è in anteprima pubblica, e gli avvertimenti condizionano direttamente l'ambito dell'interfaccia. I video sono limitati a 10 secondi. Il caricamento di riferimenti audio e l'estensione delle scene non sono ancora supportati nell'API di Gemini. I riferimenti video fino a 3 secondi sono accettati dallo schema dell'API ma "al momento non vengono elaborati correttamente dal modello" — una trappola per chi valida solo contro lo schema e assume che funzioni.

Google segnala anche che la coerenza dei personaggi si degrada tra cambi di scena e movimenti di camera. Per un frontend che promette un personaggio coerente su più clip generate, questo limite definisce il confine tra una demo e una funzionalità pronta per il rilascio.

Entrambi i modelli applicano la filigrana SynthID, verificabile tramite l'app Gemini, Chrome o Search — un meccanismo di trasparenza che vive fuori dall'app che costruisci, ma che vale la pena mostrare agli utenti che generano contenuti media condivisibili.

Cosa chiede questa suddivisione in due modelli ai team che lavorano sulle interfacce media

L'implicazione specifica di questo rilascio è che Google sta affidando ai team frontend uno stack di generazione a livelli, aspettandosi che sia l'interfaccia a instradare tra i vari livelli. Nano Banana 2 Lite per bozze ad alto volume, Nano Banana 2 come modello generalista, Nano Banana Pro per il lavoro dove serve precisione, e Omni Flash per la resa video finale.

Costruire bene attorno a questo significa che è l'interfaccia, non il modello, a decidere quando conta la velocità e quando conta la qualità — economico e veloce nella fase esplorativa, costoso e lento nel momento dell'intento reale dell'utente. Le app demo sono il modo in cui Google mostra che il prodotto è l'orchestrazione tra questi modelli, e il frontend è il punto in cui quell'orchestrazione diventa visibile all'utente.