Gemini Omni Prompting: The Tag Syntax Google Documents and Nobody Quotes

Most of the Omni prompting advice published this week is invented.

The "five-element framework from Google's official documentation" that half a dozen guides cite is on no Google page we could find, and the guides quoting it do not agree on whether there are five elements or six. The claim that putting dialogue in quotation marks switches the model into a lip-sync mode is not in any Google document either — quotation marks appear in Google's examples only for text rendered on screen.

What Google does document is more useful and almost nobody has written it up: a tag syntax that lets one prompt address specific images and clips by name. That is where this guide starts.

Two notes on what follows

Everything quoted here comes from Google's own pages — the prompt guide section of the Gemini Omni API documentation, and the shared prompting guide that covers Omni and Veo together. Where Google is silent, we say so rather than filling the gap with something that sounds authoritative.

The clips below were generated with Veo 3.1 Fast on our own API, not with Omni. Gemini Omni 1.1 Flash is not on E2X yet, and we are not going to illustrate a guide with footage from a model and pretend it came from another. The techniques they demonstrate — camera vocabulary, the single-shot instruction, sound direction — come from the prompt guide Google publishes for both models, so they transfer. The tag syntax in the next section does not: that part is Omni-only, and we show it as syntax rather than as output.

The tag syntax

Omni accepts inline tags that point at specific inputs. It is the part of the documentation with the least third-party coverage and the most to gain from reading.

For frames:

<FIRST_FRAME> a woman is walking

<LAST_FRAME> marks the frame to land on, and Google is explicit that it "must be used with" <FIRST_FRAME>. When a prompt gets complicated enough that position becomes ambiguous, there is an explicit declaration form:

[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image2]

Point both tags at the same image and you get a loop. Google documents this directly — the clip returns to where it began:

[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image1]

For references, the tags are numbered and start at zero:

in the style of <IMAGE_REF_0> a woman <IMAGE_REF_1> is walking

That single line pulls style from one image and subject from another. The video equivalent is <VIDEO_REF_0>, also zero-indexed, with a hard limit: "Video references support a maximum of 3 clips, up to 3 seconds each", and any audio in a reference clip is ignored.

The failure mode here is the model treating a reference as a literal opening frame. Google's fix is an instruction appended to the prompt:

Use the given image(s) as references for video generation.
The images should not be used as literal initial frames.

One boundary worth knowing before you design around it: "Referencing or reasoning across multiple videos is not supported." Multiple image references are fine — Google's own example runs six of them — but multi-video prompting degrades.

Omni cuts your clip into several shots unless you stop it

This is the single most surprising line in the documentation, and it explains a lot of confused output:

"By default Omni Flash will try to create a video with a few different shots. It'll attempt to craft an interesting narrative based on the prompt. If you need the output video to contain a single scene, you must prompt for that"

Ask for eight seconds of a person walking through a doorway and you may get three cuts of it. The model is not misreading you. It is doing what it defaults to.

The fix is one clause, and Google gives three phrasings: "In a single unbroken scene", "In a single continuous shot", or "No scene cuts".

Here is that instruction doing its job, with a documented camera move and a sound line attached:

In a single continuous shot, no scene cuts. Slow dolly in on a battered
enamel coffee pot sitting on a cast-iron stove in a dim cabin kitchen.
Steam rises and catches a hard shaft of morning light from a window to the
left. Medium shot, shallow depth of field, warm amber and deep green
palette. Sound design: the low hiss of steam and a wood fire ticking.
No dialogue.

Four seconds, 720p, generated with Veo 3.1 Fast at a cent a second. Note how little of that prompt is adjectives and how much of it is instructions the model can act on.

Sound is directed in its own sentences

Audio is generated with the picture, and Google's guidance is to describe it separately: "We recommend that you use separate sentences in your prompt to describe the audio." The documentation splits it three ways — sound effects, ambient noise, and dialogue — with distinct examples for each.

Dialogue is where the folklore is wrong. The documented convention is a colon and no quotation marks:

the man in the red hat says: Where is the rabbit?

Google's longer example runs two speakers in one prompt and closes with the ambience:

A medium shot in a dimly lit interrogation room. The seasoned detective
says: Your story has holes. The nervous informant, sweating under a single
bare bulb, replies: I'm telling you everything I know. The only other
sounds are the slow, rhythmic ticking of a wall clock and the faint sound
of rain against the window

Omni's own examples prefix the non-speech audio with Sound design:, as in "Sound design: Gentle breeze, distant bird chirps. No dialogue." And when you want music specifically, say so — Google flags this as the case most likely to be missed: "This is especially important if you want music in your video".

Two constraints to design around: voice editing is not supported, and "Uploading audio references is unsupported in the current version of the API". You direct sound with words or not at all.

Timecodes work, and they rebase when you extend

Timing needs no special syntax — "there is no precise syntax needed and you can use natural language", so "At 5s the chorus starts in the background audio" is a valid instruction. There is also a bracketed timecode form:

[0-3s] A person is walking
[3-6s] They stop and turn around
[6-10s] They start running

Now the trap, and it is a real one. When you extend an existing clip, 0s no longer means the start of the video. It means the start of the extension. Google spells it out:

"If using timestamps or a timecode syntax, 0s refers to the beginning of the extended part of the video. If extending a 10s video, the scene cut in this prompt will happen after 12s"

So After 2s cut to a new scene lands at the twelve-second mark of the finished piece. Anyone building a shot list against absolute timecodes will get this wrong once and then never again.

While you are there: extension prompts should describe the continuation, not restate the whole scene. Google's suggested forms are as short as "Extend this video" or "The scene continues", with additions only where something changes — "The music continues into the chorus" for audio, "Show the same characters in the next scene" for a cut. Extension appends only; you cannot prepend or splice into the middle.

Editing wants fewer words, not more

Everything above rewards detail. Editing inverts it: "Simple prompts work best for video editing. Overly descriptive prompts can lead to unintended changes."

Google publishes its own before-and-after pairs, and they are worth reading as a pattern rather than as two examples:

Avoid:    In the video of the man sitting on the sofa, please add a small
          black cat that runs from the right side of the screen, jumps onto
          his lap, and then he starts to stroke its head while looking down.

Simplify: Add a cat that jumps onto his lap, he begins to pet it.
          Keep everything else the same.

Avoid:    Please remove the cell phone that the person is holding in their
          hand and fill in the background so it looks like they are just
          holding their hand empty.

Simplify: Make the phone invisible. Keep everything else the same.

The clause doing the work in both is "Keep everything else the same", which Google recommends including whenever you edit one aspect of a shot. Every extra detail you supply is another thing the model may decide to regenerate.

Image-to-video runs the other way again: "Vague prompts like 'make it move' produce less compelling results than detailed descriptions of the camera movement, subject motion, and environmental effects." Detail for generation, brevity for editing.

The camera words Google actually names

Google publishes a vocabulary list, which is more reliable than the terms circulating in prompt-tip threads. Movements it names: static, pan, tilt, dolly in and out, truck left and right, pedestal up and down, zoom, crane, aerial or drone, handheld, whip pan, arc. Angles: eye-level, low, high, bird's-eye, worm's-eye, Dutch, close-up and extreme close-up, medium, full, wide or establishing, over-the-shoulder, point-of-view. Optical effects: wide-angle, telephoto, shallow and deep depth of field, lens flare, rack focus, fisheye, and the vertigo effect — the dolly zoom.

Google also distinguishes zoom from dolly explicitly, because models conflate them: a zoom changes focal length, and "This is different from a dolly, as the camera itself doesn't move."

Carry the caveat Google states twice, though: "Some advanced camera angles are not officially supported. The results and reliability may vary depending on the overall prompt and your specific use case." Naming a move is a request, not a guarantee.

Here is an arc shot, one of the documented movements, prompted plainly:

Slow arc shot travelling left around a weathered brass sextant resting on
an unrolled nautical chart on a scuffed wooden table. Low winter sunlight
rakes in from the right and the brass catches moving highlights as the
camera travels. Single continuous shot, no scene cuts, shallow depth of
field. Sound design: faint harbour ambience, rigging tapping in wind.
No dialogue.

Cinematic and editing terms are documented too — match cut, jump cut, establishing shot sequence, montage, split diopter effect. Terms you may have seen attributed to Google that are not on either page: oner, push in, and natural smartphone zoom.

Negative prompts: two Google pages disagree

Omni has no negative-prompt parameter. The API documentation is blunt: "System instructions, temperature, top_p, stop sequences, and negative prompts are not supported (you can put your negatives in the regular prompt: e.g., 'Do not do X')."

And the Omni prompt guide recommends exactly that, suggesting "No dialogue", "No embellishments", "No extra sound effects".

Google's shared Omni-and-Veo guide says the opposite about phrasing:

"Not recommended: using instructive language or words such as 'no' or 'don't'. For example, avoid prompts such as 'no walls' or 'don't show walls'. Recommended: Describe what you don't want to see. For example, 'wall, frame'"

We are not going to pretend to resolve that. The likeliest explanation is that the second page is describing Veo's dedicated negativePrompt field — which Omni does not have — while the Omni page describes prose negatives, which is all Omni offers. That is inference, not something Google states. In practice: use the Omni page's phrasing for Omni, and if a negative is being ignored, try the other form before assuming the model cannot do it.

One more honest contradiction, since it affects what you can promise a client. The Omni prompt guide says the model renders on-screen text "in a way that is correct and readable". The DeepMind model card lists "rendering perfectly accurate text" among the things that "remain a challenge". Both are Google. Test before you commit.

A checklist you can actually use

Working from the above, a prompt that respects how the model behaves usually carries:

1. A shot-count instruction, because multi-shot is the default and probably not what you want
2. The subject and its motion, specifically — not "make it move"
3. One documented camera move, named from Google's list
4. Light: direction, quality, colour
5. A separate sentence for sound, prefixed Sound design: if it is not dialogue
6. Dialogue as speaker says: line, colon, no quotation marks
7. Any negatives as short prose clauses at the end
8. For edits only: strip most of the above and add "Keep everything else the same"

Google's own summary of the structure is longer — subject, action, scene, camera angle, camera movement, lens, visual style, temporal elements, audio, cinematic terms, negatives — with the reassurance that "You don't need to use all elements in every prompt".

Where to run this today

Prompting is a skill you acquire by failing repeatedly, which makes the price per failure the number that matters most. A four-second test on Veo 3.1 Fast costs four cents. The same test on Gemini Omni 1.1 Flash, live here since 28 August 2026 at nine cents a second, costs thirty-six — or about twelve if you draft it at 360p first, which is the tier the 1.1 release added for exactly this. Over an afternoon of learning where a camera instruction stops being obeyed, that difference decides how many times you get to be wrong.

So drill the transferable half cheaply — shot count, camera vocabulary, sound direction, negatives — all of which come from the guide Google publishes for both models. Both clips above were made exactly that way. Move up to the Omni family when you need what only it does: the tag syntax, extension, and reference-driven consistency. One note on the frame tags this guide spends the most time on — they now have an endpoint of their own, start-end-frame-to-video, which takes the two frames as fields instead, and image-to-video does the same for a single opening still. Veo 3.1 Fast will still cover image-to-video and first and last frame practice along the way. Current rates as of 28 August 2026.

We wrote up what shipped in 1.1 and what the leaderboards actually say about it separately. Browse by job from text-to-video, or read the machine-readable spec if you would rather diff parameters than prose.

Prices and product terms can change. Check each provider's current pricing before making a purchasing decision.

Frequently asked questions

How do you write a prompt for Gemini Omni 1.1 Flash?

Name the shot count first, because Omni produces multiple shots by default and you usually want one. Then describe the subject and its motion, one named camera move, and the lighting. Put audio in its own sentence, prefixed "Sound design:" for non-speech, and write dialogue as "speaker says: line" with a colon and no quotation marks. Add any negatives as short clauses at the end.

What is the FIRST_FRAME tag in Gemini Omni?

It is an inline tag that tells Omni to use a supplied image as the opening frame, written as the tag followed by your description. Its partner LAST_FRAME marks the frame to end on and, per Google's documentation, must be used together with FIRST_FRAME. Pointing both tags at the same image produces a looping clip.

Does Gemini Omni support negative prompts?

Not as a parameter. Google's API documentation states that negative prompts are not supported and tells you to put negatives in the regular prompt instead, such as "Do not do X". The Omni prompt guide suggests short clauses like "No dialogue" or "No extra sound effects". Google's shared Omni and Veo guide advises against that phrasing, which appears to describe Veo's separate negative-prompt field rather than Omni.

Why does Gemini Omni add scene cuts I did not ask for?

Because multiple shots are the default. Google's documentation says Omni will try to create a video with several shots and craft a narrative from your prompt unless told otherwise. Adding "In a single continuous shot" or "No scene cuts" to the prompt is the documented fix.

How do timestamps work when extending an Omni video?

They rebase. Once you extend a clip, 0s refers to the start of the extension rather than the start of the original. Google's example: extending a 10-second video with an instruction at 2s places that moment at 12 seconds in the finished piece. Extension only appends — you cannot prepend content or edit the middle of a clip.

Should dialogue go in quotation marks for Gemini Omni?

No. Google's documented form is "speaker says: line" — a colon, without quotation marks. The widely repeated claim that quotation marks trigger a lip-sync mode does not appear in any Google documentation. Quotation marks show up in Google's examples only for text meant to be rendered on screen, which is likely where the confusion started.

How much does it cost to practise Omni prompting?

On our API, Gemini Omni 1.1 Flash runs at $0.09 per second at 720p, so a four-second test is $0.36, or about $0.12 if you draft at 360p, as of 28 August 2026. Veo 3.1 Fast is $0.01 per second, making the same test four cents. Since the camera, shot-count and audio techniques come from the prompt guide Google publishes for both models, practising on the cheaper one costs a ninth as much and drills the same habits.