OmniHuman-1.5 Prompt Recipes: Copy-Paste Prompts for Talking-Head Video

Why prompt structure beats prompt wording

Most teams write their first talking-avatar prompt as a single sentence, then spend hours rewording it looking for a magic phrase. That approach fails because OmniHuman-1.5 is not responding to cleverness—it is responding to a specification. The prompt is the spec for a short video: who is on camera, what they say, how the frame is composed, and how the line is delivered. When any one of those is missing or tangled with the others, the model has to guess, and guessing is where inconsistent output comes from.

A useful mental model is to think of the prompt as four stacked blocks feeding one output:

• Subject — who appears on camera and what they look like at a stable, describable level.
• Script — the exact words to be spoken, written out literally.
• Framing — shot size, camera angle, background, and where the subject sits in the frame.
• Delivery — pace, energy, tone, and the small physical behaviors that make a line read as spoken rather than recited.

Once you separate these, iteration becomes tractable. You can change the delivery without touching the script, or reframe the shot without rewriting the subject description. If everything lives in one flowing paragraph, every edit is a global edit and you can never attribute a change in output to a specific change in input.

This is also why two prompts that read very differently on the surface can produce similar results: they encode the same four blocks. And two prompts that look almost identical can diverge badly because one of them silently dropped a block—usually delivery, which is the one people forget to write down.

The recipes in this guide are all built from the same four blocks. They are meant to be copied, adapted, and then broken deliberately so you can see what each block is doing.

One caveat before you start

OmniHuman-1.5 prompt handling is not fully documented in public, and undocumented knobs change. Every recipe below avoids invented parameters, weight syntax, and vendor-specific flags. Instead it relies on plain, explicit natural-language descriptions of subject, script, framing, and delivery. That keeps the recipes portable and keeps you from building a pipeline on syntax that may not exist.

When a recipe needs to constrain something the model may not honor reliably—exact timing, precise lip-sync on unusual phonemes, very long scripts—the guide says so and suggests handling it outside the prompt rather than wishing it into the text.

If you want to run these recipes through a single unified API rather than stitching together per-model integrations, the HiAPI.ai video endpoint is the intended path for everything described here.

The anatomy of a copy-paste ready prompt

Before the recipes, here is the template they all follow. Read it once and you can reconstruct any of them from memory.

[SUBJECT]
A [age range] [gender presentation] with [hair], [distinguishing feature],
wearing [clothing]. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "<your script here>"

[FRAMING]
[Shot size] shot, [camera angle], [subject position in frame].
Background: [background description]. Lighting: [lighting description].

[DELIVERY]
Speaks at [pace]. Tone: [tone]. [Optional physical behavior cue].
Camera is static.

A few notes on why each field is written the way it is.

Subject

Keep the description stable and concrete: age range, gender presentation, hair, one or two distinguishing features, clothing. Avoid stacking adjectives—each extra descriptor is another thing the model can drift on between runs. If you need the same person across multiple clips, freeze this block verbatim and never edit it.

Script

The phrase Say exactly is doing real work. It signals that the following text is speech content, not scene description. Put the script in quotes so the boundary is unambiguous, and keep it as plain prose—no stage directions, no parentheticals, no markup.

Framing

Shot size (close-up, medium, medium-wide), camera angle (eye level, slightly below), and subject position (centered, slightly left of frame) are all describable in ordinary words and all materially change the output. Background and lighting belong here too, because they are part of the shot, not part of the delivery.

Delivery

This block is the one most people skip. Pace, tone, and one physical behavior cue (a small nod, a hand gesture, a shift in posture) do more for perceived naturalness than any amount of rewriting the subject description. Keep it to one or two cues—more than that and the model has to choose.

The closing constraint

Ending with Camera is static is a cheap way to suppress unrequested camera movement, which is a common and distracting failure in talking-head generations. It is not a parameter; it is a plain instruction, and it belongs in the recipe.

What you should not put in the template

Skip frame rates, resolutions, seeds, and model-version strings inside the prompt text. Those are request-level concerns, not prompt-level ones, and mixing them in makes the prompt harder to diff and harder to reuse. Keep the prompt about content and the API call about infrastructure.

Recipe: single-speaker explainer clip

The workhorse recipe. Use it for documentation narration, course content, announcement videos, and anything where a presenter delivers a paragraph of prepared copy.

[SUBJECT]
A person in their early 30s, gender-neutral presentation, short dark hair,
wearing a plain crew-neck sweater. Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "In this walkthrough we'll cover three things. First, how to set up
the project. Second, the configuration options that matter most. And third, how
to verify everything is working before you ship."

[FRAMING]
Medium shot, eye level, subject centered with a small amount of headroom.
Background: softly out-of-focus home office with a bookshelf.
Lighting: soft key light from the left, no harsh shadows.

[DELIVERY]
Speaks at a measured, conversational pace. Tone: friendly and instructional.
Occasional small nod on sentence boundaries. Camera is static.

Why this works

The script is short enough to stay coherent—roughly three sentences with clear clause boundaries. The framing is deliberately boring: centered, eye level, soft background. Boring framing is a feature here, because it makes output variation between runs easy to spot. If the background starts changing, you know it is the model, not your shot description.

The delivery block gives one physical cue (a nod on sentence boundaries) that maps naturally onto the script's structure. That correspondence between delivery cue and script shape is worth reproducing: cues that match the rhythm of the line read as natural, and cues that fight it read as random.

Adapting it

• Longer script: keep the same framing and delivery, and split the script into multiple clips at paragraph boundaries rather than pushing one long generation. Consistency across clips is easier to hold when each clip is structurally similar.
• Different audience: change the tone word only ("authoritative," "warm," "brisk") and re-run. This is the single highest-leverage edit in the recipe.
• Brand persona: freeze the subject block, change only clothing. That isolates wardrobe from face and hair, which are the fields most likely to drift.

Known limits

Very long scripts—several paragraphs in one generation—tend to lose pace consistency toward the end. Plan for clips of a few sentences each and assemble them in your editor. Do not try to solve length by adding pacing instructions to the prompt; the prompt is not a timing controller.

Recipe: short social hook

Short-form video lives or dies in the first two seconds. This recipe trades the explainer's neutrality for energy, and it is deliberately shorter than the others.

[SUBJECT]
A person in their late 20s, wearing a casual button-up shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Stop scrolling. If you've ever shipped a feature that broke in
production, this is the one setting you probably missed."

[FRAMING]
Close-up shot, slightly below eye level, subject centered and filling most of
the frame. Background: simple solid-color wall. Lighting: bright, even, frontal.

[DELIVERY]
Speaks quickly with confident energy. Tone: direct and conspiratorial.
Leans in slightly on the first sentence. Camera is static.

Design choices worth stealing

Close-up plus slightly below eye level creates intimacy and a hint of urgency. It is the visual grammar of short-form video, and it is fully expressible in plain framing language—no special syntax required.

A solid-color background removes visual noise that competes with a fast cut. In short form, the background should never be the interesting part of the frame.

Two sentences maximum. The hook is a unit of attention, not a paragraph. If your idea needs three sentences, it is a different recipe.

One physical cue that matches the first sentence. "Leans in slightly on the first sentence" only works because the first sentence is the hook. Pair the cue with the beat it belongs to.

Adapting it

Run the same subject and framing with three different hook scripts and pick from the outputs. Because everything except the script block is frozen, differences between the clips are attributable to the writing, which is exactly what you want when you are A/B testing hooks.

Known limits

Very fast delivery can degrade articulation on dense technical terms. If your hook contains product names, acronyms, or numbers spoken aloud, slow the pace word from "quickly" to "briskly" and compare. This is the one place where the delivery block may need a second pass even after the script is locked.

Recipe: product walkthrough voice-over

This recipe is for narration over a product interface or a sequence of steps, where clarity matters more than personality and pacing needs to leave room for the viewer's eyes to catch up.

[SUBJECT]
A person in their mid 30s, wearing a neutral blazer over a plain shirt.
Natural, realistic appearance, no stylization.

[SCRIPT]
Say exactly: "Open the settings panel from the left navigation. Choose the
integration you want to connect. Paste your key into the credential field.
Then save, and run a test call from the same screen to confirm the connection."

[FRAMING]
Medium close-up, eye level, subject positioned slightly left of center to leave
room on the right of frame. Background: clean, uncluttered neutral wall.
Lighting: soft, even, no rim light.

[DELIVERY]
Speaks slowly and evenly, with a brief pause at each step boundary.
Tone: calm and precise. Minimal movement. Camera is static.

The composition cue that matters

"Positioned slightly left of center to leave room on the right of frame" is the most important line in this recipe. Walkthroughs are usually composited with screen capture or UI overlays, and off-center framing gives your editor a place to put them. It costs nothing in the prompt and saves a re-render later.

Pacing as a structural instruction

"A brief pause at each step boundary" is an instruction about structure, not a timing parameter. It tells the model that the script has a rhythm of four units. You are not specifying milliseconds—you are telling it where the beats are. Keep the number of steps in the script small and the correspondence clear; if the script has six steps and the delivery mentions pauses at boundaries, that is still one instruction, and it remains readable.

Adapting it

• Multiple segments: render each step as its own clip with identical subject and framing blocks, then concatenate. This gives you clean edit points and consistent appearance across the sequence.
• Overlay-driven cuts: if a step needs a longer visual beat than its spoken line, add a trailing silent clip rather than stretching the delivery instruction. Silence is a post-production concern.

Known limits

Pauses are a request, not a guarantee. If exact pause placement is critical for sync with on-screen actions, plan to adjust in your editor and treat the generated clip as the audio-visual source of truth for everything except cut timing.

Testing and iterating on a recipe

A recipe is a hypothesis. Validate it before you scale it.

Step 1: Write a test script

Prepare a short script—two to three sentences—that exercises the hard parts of your real content: the longest word, the most unusual proper noun, the numbers you will actually say. Test scripts should be adversarial, not flattering. A test line that the model handles easily tells you nothing.

Step 2: Generate a baseline

Run the recipe once with the test script and no modifications. Save the output and the exact prompt text that produced it. This baseline is your reference point for every subsequent comparison.

Step 3: Change one variable per run

This is the entire discipline. Pick one thing and change only that:

• Script length — same prompt, one sentence longer.
• Framing — medium to medium close-up, nothing else touched.
• Delivery tone — one word swapped ("friendly" to "brisk").

If you change framing and tone in the same run and the output improves, you have learned that something worked and nothing about which. That is a wasted run.

Step 4: Keep a diff log

For each run, record the prompt variant, the single change, and a one-line verdict. Rejected variants are as valuable as accepted ones, because they tell you where the boundaries are. A simple text file with a timestamp and a diff is sufficient; you do not need a special tool.

Step 5: Promote or discard

When a variant clearly beats the baseline, promote it to a new baseline and re-test it against the full test script before committing it as your production recipe. A change that helps on one sentence may hurt on another.

What not to iterate on

Do not iterate on things the prompt does not control. If your problem is resolution, aspect ratio, or seed determinism, you are in the wrong layer—look at your request parameters, not your prompt. Spending runs rewording a prompt to fix an infrastructure concern is the most common way teams waste generation budget.

A note on sample size

Talking-head generation has inherent run-to-run variation. A single sample per variant can mislead you. Generate two or three per variant on the test script before drawing conclusions, and compare across samples rather than cherry-picking the best one.

Common failure modes and how to prompt around them

These are the problems that show up most often, with prompt-side adjustments that address them. None of these require inventing parameters.

The subject drifts between clips

Symptom: hair, clothing, or age looks different across segments. Fix: freeze the subject block verbatim across all prompts and change nothing in it—not a synonym, not a word order. Variation usually comes from well-meaning rewrites between clips.

The delivery reads as recited, not spoken

Symptom: flat affect, no micro-movement, uncanny stillness. Fix: add one physical behavior cue to the delivery block and make sure it corresponds to a beat in the script. Also check whether the script is written in spoken register—contractions, short clauses, sentence fragments. Formal prose reads as formal delivery no matter what tone word you add.

Unrequested camera movement

Symptom: slow zoom, drift, or pan that you did not ask for. Fix: end the delivery block with an explicit static-camera instruction. If movement persists, remove any words elsewhere in the prompt that imply motion ("dynamic," "energetic framing," "moving shot").

The background competes with the subject

Symptom: the model focuses attention on background detail instead of the face. Fix: simplify the background description toward a single phrase and add lighting that separates the subject from the wall (soft key from one side). Fewer background words, not more.

Pace collapses on long scripts

Symptom: delivery starts well and rushes or flattens toward the end. Fix: shorten the script. This is the reliable fix and no prompt wording compensates for it. Split into multiple clips at natural boundaries instead.

Articulation degrades on dense terms

Symptom: product names, acronyms, or numbers are unclear. Fix: change the pace word from fast to measured, and if a specific term is still wrong, consider respelling it phonetically in the script—acknowledging that this makes the script harder to read and should be a last resort.

The output ignores part of the prompt

Symptom: a whole block seems to have no effect. Fix: check for block collisions. If the subject block says "wearing a formal suit" and the framing block says "casual coffee shop," the model has to reconcile a contradiction and may drop something. Make the four blocks agree with each other before assuming the model is at fault.

The result is inconsistent across identical runs

Symptom: same prompt, different output. Fix: this is expected variance, not a prompt bug. Establish your acceptance criteria on two or three samples per variant and stop tuning when you are inside them. Chasing perfect determinism through prompt wording is not productive.

Treat your prompts as versioned assets

A prompt that lives in a chat window is not a reproducible asset. The moment you have two recipes and a few variants of each, you have source code—and it should be managed like source code.

Store prompts next to the code that uses them

Keep a prompts/ directory in the same repository as your generation scripts. One file per recipe, plain text or markdown, with the four blocks intact and readable. The prompt text should be loadable as a string, not pasted into a function body.

Name them so the name predicts the output

A naming scheme that encodes intent is worth more than cleverness:

prompts/
  explainer-single-speaker-v3.txt
  social-hook-closeup-v2.txt
  walkthrough-voiceover-v1.txt

The version suffix is not decoration. Bump it when a block changes in a way that affects output; do not bump it for typo fixes in comments.

Diff the prompt, not just the binary

When output quality changes, you need to answer "what changed in the input?" A git diff on a plain-text prompt answers that in one command. A prompt embedded in a JSON blob with request parameters mixed in does not. Keep the prompt text separate from request configuration so the diff stays legible.

Pin the prompt alongside the generated asset

When you save a generated clip, record which prompt version produced it—in the filename, a sidecar metadata file, or your asset database. Six weeks later, when someone asks why one clip in a series looks different, the answer should be one lookup away rather than a guess.

Review prompt changes like code changes

A prompt edit that changes framing or subject is a visual change. Treat it like a UI change: open a pull request, attach a sample output before and after, and have someone else look at it. This is the cheapest way to catch accidental drift in a block that was supposed to be frozen.

Keep a recipes index

A short README in the prompts directory listing each recipe, what it is for, and its current version saves every new contributor from reverse-engineering your intent. It is also where you record known limits, like the script-length ceiling from the explainer recipe, so the constraint is documented rather than rediscovered.

Start with the platform, then specialize

If you are wiring these recipes into a pipeline, the HiAPI.ai OmniHuman-1.5 video endpoint gives you one interface to call, so your repository layout and versioning scheme stay stable as you add recipes. Copy a recipe, run it against a short test script, change one variable at a time, and commit the version that beats your baseline—that loop is the whole method.