Prompting en Gemini Omni: la sintaxis de etiquetas que Google documenta y nadie cita
Casi todos los consejos de prompting para Omni publicados esta semana están inventados.
El «marco de cinco elementos de la documentación oficial de Google» que citan media docena de guías no está en ninguna página de Google que hayamos podido encontrar, y las guías que lo citan no se ponen de acuerdo en si son cinco elementos o seis. La afirmación de que poner el diálogo entre comillas cambia el modelo a un modo de sincronización labial tampoco está en ningún documento de Google: las comillas aparecen en los ejemplos de Google únicamente para texto renderizado en pantalla.
Lo que Google sí documenta es más útil y casi nadie lo ha escrito: una sintaxis de etiquetas que permite que un mismo prompt se dirija a imágenes y clips concretos por su nombre. Ahí es donde empieza esta guía.
Dos notas sobre lo que viene a continuación
Todo lo que se cita aquí viene de páginas del propio Google: la sección de guía de prompts de la documentación de la API de Gemini Omni, y la guía de prompting compartida que cubre Omni y Veo juntos. Donde Google guarda silencio, lo decimos, en lugar de rellenar el hueco con algo que suene autorizado.
Los clips de abajo se generaron con Veo 3.1 Fast en nuestra propia API, no con Omni. Gemini Omni 1.1 Flash todavía no está en E2X, y no vamos a ilustrar una guía con metraje de un modelo fingiendo que viene de otro. Las técnicas que demuestran —vocabulario de cámara, la instrucción de plano único, la dirección de sonido— vienen de la guía de prompts que Google publica para los dos modelos, así que se transfieren. La sintaxis de etiquetas de la sección siguiente no: esa parte es exclusiva de Omni, y la mostramos como sintaxis y no como resultado.
La sintaxis de etiquetas
Omni acepta etiquetas en línea que apuntan a entradas concretas. Es la parte de la documentación con menos cobertura de terceros y con más que ganar si se lee.
Para fotogramas:
<FIRST_FRAME> a woman is walking
<LAST_FRAME> marca el fotograma en el que aterrizar, y Google es explícito en que «must be used with» <FIRST_FRAME>. Cuando un prompt se complica lo bastante como para que la posición resulte ambigua, existe una forma de declaración explícita:
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image2]
Apunte las dos etiquetas a la misma imagen y obtiene un bucle. Google lo documenta directamente: el clip vuelve al punto en el que empezó.
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image1]
Para las referencias, las etiquetas están numeradas y empiezan en cero:
in the style of <IMAGE_REF_0> a woman <IMAGE_REF_1> is walking
Esa única línea toma el estilo de una imagen y el sujeto de otra. El equivalente en vídeo es <VIDEO_REF_0>, también indexado desde cero, con un límite duro: «Video references support a maximum of 3 clips, up to 3 seconds each», y cualquier audio de un clip de referencia se ignora.
El modo de fallo aquí es que el modelo trate una referencia como un fotograma inicial literal. La solución de Google es una instrucción añadida al prompt:
Use the given image(s) as references for video generation.
The images should not be used as literal initial frames.
Un límite que conviene conocer antes de diseñar alrededor de él: «Referencing or reasoning across multiple videos is not supported». Varias referencias de imagen no dan problema —el propio ejemplo de Google usa seis—, pero el prompting con varios vídeos se degrada.
Omni corta su clip en varios planos salvo que se lo impida
Esta es la línea más sorprendente de toda la documentación, y explica bastante output confuso:
"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"
Pida ocho segundos de una persona cruzando una puerta y puede recibir tres cortes de ello. El modelo no le está malinterpretando. Está haciendo aquello que hace por defecto.
El arreglo es una sola cláusula, y Google da tres formulaciones: «In a single unbroken scene», «In a single continuous shot» o «No scene cuts».
Aquí está esa instrucción haciendo su trabajo, con un movimiento de cámara documentado y una línea de sonido añadidos:
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.
Cuatro segundos, 720p, generado con Veo 3.1 Fast a un céntimo por segundo. Fíjese en qué poco de ese prompt son adjetivos y cuánto son instrucciones sobre las que el modelo puede actuar.
El sonido se dirige en frases propias
El audio se genera junto con la imagen, y la recomendación de Google es describirlo por separado: «We recommend that you use separate sentences in your prompt to describe the audio». La documentación lo divide en tres: efectos de sonido, ruido ambiente y diálogo, con ejemplos distintos para cada uno.
El diálogo es donde el folclore se equivoca. La convención documentada son dos puntos y ninguna comilla:
the man in the red hat says: Where is the rabbit?
El ejemplo más largo de Google mete dos hablantes en un mismo prompt y cierra con la ambientación:
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
Los propios ejemplos de Omni prefijan el audio que no es habla con Sound design:, como en «Sound design: Gentle breeze, distant bird chirps. No dialogue.». Y cuando quiera música específicamente, dígalo: Google señala este como el caso que más probablemente se pasa por alto: «This is especially important if you want music in your video».
Dos restricciones alrededor de las cuales diseñar: la edición de voz no está soportada, y «Uploading audio references is unsupported in the current version of the API». El sonido se dirige con palabras o no se dirige.
Los timecodes funcionan, y se rebasan al extender
La temporización no necesita sintaxis especial —«there is no precise syntax needed and you can use natural language»—, así que «At 5s the chorus starts in the background audio» es una instrucción válida. Existe además una forma de timecode entre corchetes:
[0-3s] A person is walking
[3-6s] They stop and turn around
[6-10s] They start running
Ahora la trampa, y es una trampa real. Cuando extiende un clip existente, 0s ya no significa el principio del vídeo. Significa el principio de la extensión. Google lo deja escrito:
"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"
Así que After 2s cut to a new scene cae en el segundo doce de la pieza terminada. Cualquiera que construya un desglose de planos contra timecodes absolutos se equivocará una vez y nunca más.
Ya que estamos: los prompts de extensión deberían describir la continuación, no volver a enunciar la escena entera. Las formas que sugiere Google son tan cortas como «Extend this video» o «The scene continues», con añadidos solo donde algo cambia: «The music continues into the chorus» para el audio, «Show the same characters in the next scene» para un corte. La extensión solo añade al final; no se puede anteponer ni insertar en medio.
La edición quiere menos palabras, no más
Todo lo anterior recompensa el detalle. La edición lo invierte: «Simple prompts work best for video editing. Overly descriptive prompts can lead to unintended changes.»
Google publica sus propios pares de antes y después, y merece la pena leerlos como un patrón y no como dos ejemplos:
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.
La cláusula que hace el trabajo en los dos es «Keep everything else the same», que Google recomienda incluir siempre que edite un aspecto de un plano. Cada detalle de más que aporte es otra cosa que el modelo puede decidir regenerar.
El image-to-video va otra vez en sentido contrario: «Vague prompts like 'make it move' produce less compelling results than detailed descriptions of the camera movement, subject motion, and environmental effects.» Detalle para generar, brevedad para editar.
Las palabras de cámara que Google nombra de verdad
Google publica una lista de vocabulario, que es más fiable que los términos que circulan por los hilos de consejos de prompting. Movimientos que nombra: static, pan, tilt, dolly in y out, truck left y right, pedestal up y down, zoom, crane, aerial o drone, handheld, whip pan, arc. Ángulos: eye-level, low, high, bird's-eye, worm's-eye, Dutch, close-up y extreme close-up, medium, full, wide o establishing, over-the-shoulder, point-of-view. Efectos ópticos: wide-angle, telephoto, shallow y deep depth of field, lens flare, rack focus, fisheye, y el efecto vértigo: el dolly zoom.
Google además distingue explícitamente el zoom del dolly, porque los modelos los confunden: un zoom cambia la distancia focal, y «This is different from a dolly, as the camera itself doesn't move.»
Lleve consigo, eso sí, la advertencia que Google repite dos veces: «Some advanced camera angles are not officially supported. The results and reliability may vary depending on the overall prompt and your specific use case.» Nombrar un movimiento es una petición, no una garantía.
Aquí hay un plano en arco, uno de los movimientos documentados, pedido de forma llana:
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.
Los términos cinematográficos y de montaje también están documentados: match cut, jump cut, establishing shot sequence, montage, split diopter effect. Términos que quizá haya visto atribuidos a Google y que no están en ninguna de las dos páginas: oner, push in y natural smartphone zoom.
Prompts negativos: dos páginas de Google se contradicen
Omni no tiene parámetro de prompt negativo. La documentación de la API es tajante: «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').»
Y la guía de prompts de Omni recomienda exactamente eso, sugiriendo «No dialogue», «No embellishments», «No extra sound effects».
La guía compartida de Omni y Veo de Google dice lo contrario sobre la formulación:
"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'"
No vamos a fingir que resolvemos eso. La explicación más probable es que la segunda página esté describiendo el campo dedicado negativePrompt de Veo —que Omni no tiene— mientras que la página de Omni describe negativos en prosa, que es todo lo que Omni ofrece. Eso es una inferencia, no algo que Google afirme. En la práctica: use la formulación de la página de Omni para Omni, y si un negativo se está ignorando, pruebe la otra forma antes de dar por hecho que el modelo no puede hacerlo.
Una contradicción honesta más, porque afecta a lo que puede prometerle a un cliente. La guía de prompts de Omni dice que el modelo renderiza el texto en pantalla «in a way that is correct and readable». La model card de DeepMind incluye «rendering perfectly accurate text» entre las cosas que «remain a challenge». Las dos son de Google. Pruebe antes de comprometerse.
Una lista de comprobación que sí puede usar
Trabajando a partir de lo anterior, un prompt que respeta cómo se comporta el modelo suele llevar:
- Una instrucción de número de planos, porque el multiplano es lo que hay por defecto y probablemente no es lo que quiere
- El sujeto y su movimiento, en concreto, no «make it move»
- Un movimiento de cámara documentado, nombrado desde la lista de Google
- Luz: dirección, cualidad, color
- Una frase aparte para el sonido, prefijada con
Sound design:si no es diálogo - El diálogo como
speaker says: line, con dos puntos y sin comillas - Los negativos, si los hay, como cláusulas breves en prosa al final
- Solo para ediciones: quite casi todo lo anterior y añada «Keep everything else the same»
El propio resumen de la estructura que hace Google es más largo —sujeto, acción, escena, ángulo de cámara, movimiento de cámara, óptica, estilo visual, elementos temporales, audio, términos cinematográficos, negativos—, con la tranquilidad de que «You don't need to use all elements in every prompt».
Dónde ejecutar esto hoy
El prompting es una habilidad que se adquiere fallando repetidamente, lo que convierte el precio por fallo en el número que más importa. Una prueba de cuatro segundos en Veo 3.1 Fast cuesta cuatro céntimos. La misma prueba en Gemini Omni 1.1 Flash, en producción aquí desde el 28 de agosto de 2026 a nueve céntimos por segundo, cuesta treinta y seis, o unos doce si primero la esboza a 360p, el nivel que la 1.1 añadió justo para esto. A lo largo de una tarde aprendiendo dónde deja de obedecerse una instrucción de cámara, esa diferencia decide cuántas veces puede equivocarse.
Así que entrene barato la mitad transferible —número de planos, vocabulario de cámara, dirección de sonido, negativos—, que viene toda de la guía que Google publica para los dos modelos. Los dos clips de arriba se hicieron exactamente así. Suba a la familia Omni cuando necesite lo que solo ella hace: la sintaxis de etiquetas, la extensión y la consistencia guiada por referencias. Una nota sobre las etiquetas de fotograma a las que esta guía dedica más espacio: ahora tienen endpoint propio, start-end-frame-to-video, que toma los dos fotogramas como campos en lugar de como etiquetas, y image-to-video hace lo mismo con un único fotograma de apertura. Veo 3.1 Fast seguirá cubriendo por el camino la práctica de image-to-video y de primer y último fotograma. Tarifas vigentes a 28 de agosto de 2026.
Escribimos por separado qué trae la 1.1 y qué dicen realmente las tablas de clasificación sobre ella. Explore por tipo de trabajo desde text-to-video, o lea la especificación legible por máquina si prefiere comparar parámetros antes que leer prosa.
Los precios y las condiciones de producto pueden cambiar. Compruebe el precio vigente de cada proveedor antes de tomar una decisión de compra.
Preguntas frecuentes
¿Cómo se escribe un prompt para Gemini Omni 1.1 Flash?
Nombre primero el número de planos, porque Omni produce varios planos por defecto y normalmente usted quiere uno. Después describa el sujeto y su movimiento, un movimiento de cámara con nombre y la iluminación. Ponga el audio en su propia frase, prefijada con «Sound design:» si no es habla, y escriba el diálogo como «speaker says: line», con dos puntos y sin comillas. Añada los negativos como cláusulas breves al final.
¿Qué es la etiqueta FIRST_FRAME en Gemini Omni?
Es una etiqueta en línea que le dice a Omni que use una imagen aportada como fotograma de apertura, escrita como la etiqueta seguida de su descripción. Su compañera LAST_FRAME marca el fotograma en el que terminar y, según la documentación de Google, tiene que usarse junto con FIRST_FRAME. Apuntar las dos etiquetas a la misma imagen produce un clip en bucle.
¿Admite Gemini Omni prompts negativos?
No como parámetro. La documentación de la API de Google indica que los prompts negativos no están soportados y le dice que ponga los negativos en el prompt normal, del tipo «Do not do X». La guía de prompts de Omni sugiere cláusulas breves como «No dialogue» o «No extra sound effects». La guía compartida de Omni y Veo de Google desaconseja esa formulación, algo que parece describir el campo separado de prompt negativo de Veo y no Omni.
¿Por qué añade Gemini Omni cortes de escena que no he pedido?
Porque los planos múltiples son lo que hay por defecto. La documentación de Google dice que Omni intentará crear un vídeo con varios planos y componer una narrativa a partir de su prompt salvo que se le indique otra cosa. Añadir «In a single continuous shot» o «No scene cuts» al prompt es el arreglo documentado.
¿Cómo funcionan los timestamps al extender un vídeo de Omni?
Se rebasan. Una vez que extiende un clip, 0s se refiere al inicio de la extensión y no al inicio del original. El ejemplo de Google: extender un vídeo de 10 segundos con una instrucción en el segundo 2 sitúa ese momento en el segundo 12 de la pieza terminada. La extensión solo añade al final: no se puede anteponer contenido ni editar el medio de un clip.
¿Debe ir el diálogo entre comillas en Gemini Omni?
No. La forma documentada por Google es «speaker says: line», con dos puntos y sin comillas. La afirmación tan repetida de que las comillas activan un modo de sincronización labial no aparece en ninguna documentación de Google. Las comillas aparecen en los ejemplos de Google solo para el texto que se va a renderizar en pantalla, que es probablemente donde empezó la confusión.
¿Cuánto cuesta practicar el prompting de Omni?
En nuestra API, Gemini Omni 1.1 Flash va a $0.09 por segundo a 720p, así que una prueba de cuatro segundos son $0.36, o unos $0.12 si la esboza a 360p, a fecha de 28 de agosto de 2026. Veo 3.1 Fast cuesta $0.01 por segundo, lo que deja la misma prueba en cuatro céntimos. Como las técnicas de cámara, número de planos y audio vienen de la guía de prompts que Google publica para los dos modelos, practicar en el más barato cuesta una novena parte y entrena los mismos hábitos.