Nano Banana 2 Lite Is GA, but Gemini Omni Flash Remains a Preview
Google’s two June 30 generative-media releases remain available to developers, but their production status is not equal. As of August 13, 2026, Nano Banana 2 Lite is generally available, while Gemini Omni Flash remains in public preview; the Gemini API release notes identify the corresponding model IDs as gemini-3.1-flash-lite-image and gemini-omni-flash-preview.
That distinction is the most important change to carry into a new integration. Google introduced both models on June 30, 2026, through Google AI Studio and the Gemini API, but its launch announcement positioned the image model as a high-throughput option producing a 1K image in about four seconds for $0.034, while pricing Omni Flash video output at $0.10 per second and explicitly labeling it a preview.
One launch, two different deployment decisions
Nano Banana 2 Lite is the more conventional production choice of the pair. It generates and edits images from text and image inputs, and Google presents it as the speed-and-cost tier of the Nano Banana family. Its stable model ID and GA status make it suitable for applications that need a defined image-generation component rather than an experiment tied to a preview endpoint.
The trade-off is scope. Nano Banana 2 Lite supports 1K output, not the higher-resolution options associated with more capable members of Google’s image-model range. It therefore fits thumbnail creation, rapid drafts, large batches of variants and interactive ideation better than work in which maximum resolution or the most exacting visual control is the overriding requirement.
Gemini Omni Flash addresses a broader and less settled problem: generating video and revising it through successive natural-language instructions. It can begin with text or a reference image, return video with audio, and use the Interactions API to preserve the relationship between an output and a later editing request. That conversational loop is materially different from submitting an isolated video prompt each time.
Preview status does not mean the model is merely a demonstration. Developers can call it through the API and build working experiences around it. It does mean teams should expect a less stable contract than they would from a GA model and should avoid treating today’s supported inputs, regional behavior or endpoint details as permanent.
The useful workflow is a handoff, not a merged model
The models can form a practical image-to-video pipeline, but they remain separate services with separate outputs and lifecycle risks. A developer can create a still frame with Nano Banana 2 Lite, review or modify that asset, and then provide the approved image to Omni Flash with an instruction describing subject motion, camera movement and sound.
This separation offers a useful control point. Applications can retain the generated still as an intermediate asset, attach prompt and approval metadata to it, and retry the video stage without paying to regenerate the image. A rejected video therefore does not have to erase an accepted composition.
A production design should also keep the two model calls behind distinct interfaces. The image component can rely on the stable GA identifier, while the video component can be feature-flagged, rate-limited or replaced independently if its preview behavior changes. Job records should store the exact model ID, prompt, input asset and returned interaction ID rather than recording only a generic “Gemini” provider label.
Because video generation is a longer-running operation than a four-second image request, the user experience should not assume both stages finish inside one synchronous screen action. A queue, visible processing state and recoverable retry path make the combined workflow more resilient even when the image stage feels nearly immediate.
Omni Flash’s preview limits affect product scope
The current constraints are substantial enough to shape which features can safely be advertised. Google’s live Omni Flash documentation says uploaded audio references, voice editing, multi-video reasoning, video extension and interpolation are unsupported; video references up to three seconds may be accepted by the schema but are not processed correctly, and editing uploaded videos is unavailable in the EEA, Switzerland and the United Kingdom even though editing model-generated video is supported there.
Those boundaries rule out several seemingly obvious implementations. An application should not promise that a customer can upload a soundtrack for the model to follow, extend an existing clip beyond its ending, or combine several source videos into one reasoned edit. A schema accepting a file is also not proof that the model uses it correctly, which is particularly relevant to short video references.
Regional restrictions deserve enforcement in the product layer, not just a note in documentation. If uploaded-video editing is presented to users in an unsupported market, the result may be a broken workflow after the customer has already selected and transferred an asset. Eligibility checks and interface copy should occur before upload.
The documentation also says every generated video carries an invisible SynthID watermark, while safety filters apply to prompts and outputs. Applications still need their own moderation, disclosure and retention decisions: a model-level watermark establishes provenance support, but it does not define the surrounding product’s publication policy.
The prices favor iteration, but video multiplies the bill
The published rates make the contrast easy to quantify. At $0.034 per 1K image, 1,000 successful image outputs would cost $34. At $0.10 for each second of video output, a ten-second clip would cost $1, so 1,000 such outputs would cost $1,000 before accounting for retries, discarded generations or any other charge that may apply.
That arithmetic changes how an application should expose iteration. Image variants can be generated relatively freely when latency and budget permit, while unrestricted video retries can accumulate cost much faster. Product controls such as a maximum clip count, an explicit regenerate action and per-project usage reporting are therefore more consequential on the Omni side of the pipeline.
For evaluation, teams should measure accepted outputs rather than the price of a single request. A low per-unit rate does not guarantee a low cost per usable asset if prompts require repeated attempts or if preview limitations invalidate a workflow. The relevant internal metric is total generation spend divided by the number of outputs that pass the application’s own quality and policy checks.
What developers can safely conclude now
Nano Banana 2 Lite can be treated as Google’s stable, cost-focused image endpoint, subject to its 1K-output ceiling and the normal need for quality testing. Gemini Omni Flash is usable for controlled experiments and bounded customer features, especially text-to-video, image-to-video and conversational revision, but its preview label should remain visible in technical planning.
The strongest architecture uses the models together without giving them the same operational guarantees. Pin the exact identifiers, preserve intermediate assets, isolate the preview dependency and monitor Google’s release notes for status or compatibility changes. That approach captures the speed of the image model and the editing flexibility of the video model without mistaking a coordinated launch for identical production readiness.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.