Gemini Omni 1.2 Flash vs Nano Banana 2.1: Thirty-One Stills for One Clip

Budget a thirty-second product ad and you will need two Google models, not one. Nano Banana 2.1 is the stills machine — endpoint gemini-nano-banana-2.1, generally available since 6 October 2026, $0.0336 for a 1K image, $0.0504 at 2K and $0.113 at 4K. Gemini Omni 1.2 Flash is the motion machine: generally available since 5 November 2026, about $0.07 per second of 720p video, which puts a fifteen-second clip near $1.05. Divide one by the other and a single fifteen-second render costs roughly what thirty-one 1K stills cost. That ratio is the entire decision, and it is a ratio most teams get backwards because they price the model instead of the deliverable.

Both are Google, both are metered, both carry SynthID, and both have a naming quirk that trips up integrations: the display name and the endpoint ID are not shaped the way you expect. Nano Banana is Google's product name for Gemini's native image generation, and the newest one answers to gemini-nano-banana-2.1 while its predecessor is gemini-3.1-flash-image. Omni's newest answers to gemini-omni-1.2-flash. Neither name tells you which modality you are buying.

What each one hands back

Nano Banana 2.1 takes text, image, video and PDF in, and returns images and text out, at 1K, 2K or 4K with thinking levels of minimal, medium or high. It holds up to 14 reference images for multi-image fusion — enough for four characters and object fidelity across ten objects — and it does Google Search and Image Search grounding. Its token limits are 131,072 in and 32,768 out.

Gemini Omni 1.2 Flash takes text, image and video in, and returns video with native synchronized audio, three to fifteen seconds at 24 frames per second, in 360p, 720p, 1080p or 4K where the top two are upscaled. It holds up to six reference images per request, plus reference videos of up to three seconds. It accepts the same 131,072 input tokens and returns up to 65,536.

• Output — images and text against video with native audio.

• Duration — one frame against three to fifteen seconds, extendable to a 30-second total.

• Reference images — up to 14 against up to six.

• Resolutions — 1K, 2K, 4K native tiers against 360p, 720p, 1080p, 4K with the top two upscaled.

• Thinking control — minimal, medium, high against none; Omni exposes no temperature, top_p or system instructions at all.

• Input types — text, image, video and PDF against text, image and video.

• Price — $0.0336 per 1K image against roughly $0.07 per second of 720p.

The arithmetic of a thirty-second ad

Take a realistic workflow rather than a benchmark. You have eight shots to fill thirty seconds, each two to four seconds, and you want to pick the frame that sells before you pay for motion.

On the stills side, generate four candidates per shot at 2K: thirty-two images at $0.0504, or $1.61. Review them, pick eight, upscale the winners to 4K at $0.113 each: another $0.90. You are into the project for about $2.51 and you have eight approved frames.

Now animate. Eight shots at roughly three seconds each is 24 seconds of 720p, plus retries — and Omni's conversational editing means retries are the normal workflow, not the exception. Call it two takes per shot: 48 seconds of output at $0.07, about $3.36. Then upscale the finals: 24 seconds at $0.104 per second for 1080p, about $2.50, or double that for 4K.

Call it $8 to $9 all in, with roughly a third of it spent on stills. That is the shape of a real bill, and it is why the "31 stills per clip" ratio is misleading if you take it as advice. The stills are not an alternative to the clip. They are the cheap part that decides whether the clip is worth making.

Where the ratio does bite is a different question: is this deliverable a picture or a motion sequence? A catalogue of 500 product images is a $25 Nano Banana job or a $525 Omni job, and in that comparison there is no contest to referee. The mistake is generating video because the prompt described something that moves.

Reference images, where the cheaper model is the more capable one

This is the counterintuitive finding of the comparison and it is checkable in both docs. Nano Banana 2.1 accepts up to 14 reference images. Gemini Omni 1.2 Flash accepts up to six.

Google's own framing for Omni's six is specific: up to three images per character, for up to two characters, plus product and style references. The model card calls it "improved character and subject consistency across up to 6 reference images" and the launch post describes holding faces, garments, packaging typography and brand colours consistent across angles. The reference-video path is separate and tiered by duration — eleven to fifteen second outputs take one reference video of up to three seconds, three to ten second outputs take up to three — and reference videos work only for new generation, not for editing or extending.

Nano Banana 2.1's fourteen are aimed at a different problem: fusing several subjects into one scene, with the card claiming fidelity for four characters and ten objects. That is a compositing capability, not a continuity capability, and it suits catalogue work — put the same bag in ten different rooms without redrawing the bag.

The practical consequence: if your job is "same character, many shots," Omni's six references with three-per-character framing is the better-specified tool. If your job is "many objects, one frame," Nano Banana's fourteen is. Counting references and declaring a winner gets this exactly wrong.

Text rendering, which is where these models actually differ

Both models are unusually good at legible type, and for both it is the capability that most changes what you can ship.

Nano Banana 2.1's listed advances over Nano Banana 2 are visual quality, prompt adherence, multi-turn character consistency and text rendering, plus a fix for wide panoramic ratios — 1:4, 4:1, 1:8 and 8:1 no longer tile at 2K and 4K. If your deliverable is an infographic, a poster or a UI mock, that combination is the whole product.

Omni 1.2's equivalent claim is about text inside motion: label legibility, chart animation, on-screen callouts. Google's launch material leans on it, and the one independent hands-on test available — twenty generations by Segmind's Rohit Rao, $16.17 in credits — found labelled explainers and chart animation from a supplied final frame were where the model performed best, while photoreal people from scratch were where it failed. His summary line was that it is "the most instruction-exact video model I have tested," with the caveat that about one instruction in four gets skipped.

Notice what that means for the pairing: the strongest documented use of Omni 1.2 is animating a graphic you already designed. Which is a Nano Banana 2.1 job.

Resolution, upscaling, and what "4K" is worth

Both advertise 4K and neither means the same thing by it.

Nano Banana 2.1 generates at 1K, 2K or 4K as selectable output tiers, and Google prices them separately: $0.0336, $0.0504 and $0.113 per image. The token accounting reflects real pixels — 1,120 tokens for a 1K image, 1,680 for 2K, 3,780 for 4K.

Gemini Omni 1.2 Flash's guide is explicit that 1080p and 4K are upscaled. The pricing follows token consumption rather than a native render, at 8,688 tokens per second for 1080p and 17,376 for 4K against 5,792 at 720p. So a fifteen-second 4K clip costs about $3.14, and the top tier is an enlargement of a smaller render rather than detail captured at capture time. For social delivery that is fine. For broadcast, test it before you promise it.

The workflow both belong in

Google's own recommended Omni discipline is draft cheap, iterate, then upscale the winner: 360p or 720p for exploration, 1080p or 4K for the final. Nano Banana's equivalent is generate at 1K, upscale the pick. Run them in series and the sequence writes itself — stills first to fix composition and type, then motion on the frames that survived review, then a final upscale on both.

There is one hard boundary. Omni does not take an image as a video deliverable, and Nano Banana does not take a video as an image deliverable. Neither model's output can be fed back to the other as a same-modality edit — Omni can extend and conversationally edit its own clips, Nano Banana can edit its own stills, and neither crosses over.

Buying either through OrcaRouter

Neither of these two endpoints is on our catalogue today. google/gemini-nano-banana-2.1 and google/gemini-omni-1.2-flash both return 404 against OrcaRouter's model pages, so the vendor API is the route for both. What we do serve from the same family is the previous image generation endpoint, google/gemini-3.1-flash-image-preview — Nano Banana 2 — alongside Nano Banana Pro and the Gemini 3.8 Flash text models, which means an image pipeline that is not pinned to the newest checkpoint can run its planning, prompt expansion and QA steps on one key.

That is the honest shape of it: the media calls go direct, the text calls around them do not have to. OrcaRouter bills at 0% markup with provider list price passed through, so if Google moves the Nano Banana or Omni rates, the change appears on our side the same day it appears on theirs, and automatic failover keeps a prompt-expansion step alive when one provider degrades.

What to actually choose

If the deliverable is a frame someone will look at — a pack shot, an infographic, a hero image, a UI mock — Nano Banana 2.1 is thirty times cheaper per output, takes more than twice the references, accepts PDFs, and has thinking control Omni does not expose. There is no version of that decision where Omni wins on merit.

If the deliverable is motion, Nano Banana 2.1 cannot make it at any price, and the comparison ends there.

The trap is the middle case: a project that wants a "video ad" but whose hard problems are all composition, typography and consistency. Those are still problems. Solve them on the model that costs three cents a frame, and let Omni animate eight approved frames rather than thirty-two speculative ones. The thirty-one-to-one ratio is not an argument for the stills model. It is an argument for using it first.