Why Does My Character Change Between Clips?

TL;DR: Character drift between AI video clips sorts into three buckets: wording problems a better prompt fixes, reference or parameter problems that need a vendor feature, and hard capability limits no prompt reaches. Below: which is which, with the vendor sources, so you stop rewriting a sentence against a wall built into the model.

Why does the same character change between clips at all?

Because nothing carries over. Two calls to a video model are two independent generations, and the only state passed between them is whatever you explicitly attach: text, an image, an asset ID, a previous video. Text alone does very little of that work. "A woman in her thirties, short dark hair, olive coat" describes millions of faces, and the model samples a fresh one from that population on every call, regardless of whether the wording repeats.

That single fact explains almost everything below it. A more detailed description narrows the sampling distribution. It does not pin an identity, because a text prompt was never the mechanism vendors built for that job — which is exactly why every major video model now ships a separate reference-image or character-asset feature instead of asking you to write your way to a fixed face. Google's own framing of Veo's version of that feature is direct about what it is for: "Provide images of a person, character, or product to preserve the subject's appearance in the output video" (Google, Gemini API Veo docs, accessed 3 September 2026). If text alone reliably held identity, that feature would not need to exist.

For the mechanism behind the visual symptom itself, distortion and morphing within and across frames, see why AI video morphs and warps. This piece is about a narrower question: once you know identity drifts, which fixes are actually available to you, and which ones only feel like they should work.

Is this a prompt problem, a parameter problem, or a capability limit?

Three different buckets, and the fix only works if you are in the right one.

The rest of this page expands each row. If you already know your bucket and just want the ranked list of techniques, keeping a character consistent across clips is the prescriptive companion to this diagnostic one.

Which causes does a better prompt actually fix?

Fewer than most advice implies, but the ones that are real are free.

Re-describing the character differently between shots. Calling the coat "olive" in shot one and "green" in shot three, or "short dark hair" in one prompt and "short brown hair" in the next, does not just fail to help. It actively works against a model that is already reconstructing from an underdetermined description, because now the anchors conflict across the sequence instead of merely being loose within one generation. The fix is mechanical: write the character block once and paste it identically into every shot's prompt, the same way you would reuse any other saved prompt template rather than retyping it with small variations.

Character block, pasted verbatim into every shot prompt in the sequence.

MAYA: woman, early thirties, short dark brown hair tucked
behind the left ear, thin scar above the left eyebrow, olive
canvas coat buttoned to the second button, dark jeans, scuffed
brown boots. Do not vary these details between shots.

Spending the whole prompt on blocking and never restating identity. A prompt that describes camera, light, and action in detail but never repeats the two or three features that make this character recognisable gives the model nothing stable to reconstruct toward on that particular call. This is a real gap and a rewrite genuinely closes it, but it is not the same fix as the continuity clause covered in the companion piece; that piece has the exact clause text, and repeating it here would just be restating someone else's copy-paste block.

Padding the description past what the vendor will read. Google's own Gemini API model reference lists a text input limit of 1,024 tokens on the Veo 3.1 family (Google, Gemini API models, accessed 3 September 2026). A two-hundred-word character bible plus a full shot description can exceed that budget on some requests, and when it does, the vendor truncates or ignores the excess rather than warning you. If your character block is doing the work, keep the rest of the prompt lean enough to fit alongside it.

Which causes need a parameter or a reference image, not a better sentence?

This is the bucket most people stay stuck in longest, because it looks like a wording problem from the outside.

No reference was ever attached. If you are relying purely on text, you have skipped the feature vendors actually built for this job. Veo 3.1 accepts up to three reference images of a single person, character, or product specifically to preserve appearance across a generation (Google, Gemini API Veo docs, accessed 3 September 2026). Kling's answer is a saved, reusable character asset called an Element, addressed by name in the prompt with @. No rewrite substitutes for turning this feature on.

The reference was supplied in the wrong count or shape. Kling's own Element specification requires "at least one frontal reference image (frontal_image), and 1 to 3 additional reference images (image_url) that differ from the front" (Kling, Element Management API, accessed 3 September 2026) — two to four images total, not one, and not five. Supplying a single photo, or supplying five, does not degrade gracefully; it is simply the wrong shape of request. Different vendors implement the underlying idea as a named pair of fields, a tagged item inside one array, or a plain positional array with no field names at all, and the three shapes are not interchangeable syntax. The full breakdown of which vendor uses which shape belongs to a dedicated page on frame and reference field mechanics rather than this one.

The reference did not travel with the specific call that needed it. If you are working inside a chat-style tool across several turns, the conversation remembering that you uploaded a photo earlier is not the same thing as the underlying video generation request receiving that image again. Several APIs require the reference image, asset ID, or Element name to be attached to each generation call rather than inherited from context. When a character that held for three shots suddenly reverts on the fourth, check whether the fourth request actually carried the reference before you touch the wording.

Veo 3.1, reference images reattached on every call in the sequence,
not just the first one.

Reference images: [same three images, attached again]
Prompt: The woman from the reference images continues down the
harbour wall at dusk, same coat, same hair, same pace as the
previous shot.

A vendor blocks the specific input you are trying to use. BytePlus states plainly that "Seedance 2.5 and Seedance 2.0 series models do not support directly uploading reference images/videos that contain real human faces" (BytePlus, Create portrait videos with Dreamina Seedance models, accessed 3 September 2026). That is a platform rule, not a prompting gap, and the documented alternate routes, a preset character library, a verified real-person asset, or reusing the model's own prior face-containing output within 30 days, are covered where the full technique ranking already lives.

Does setting a seed keep the character the same across clips?

No, and this is the single most common misapplication in this whole area.

A seed reproduces a sampling path, not a stored identity. Google says it outright for Veo: "Note that the seed parameter is also available for Veo 3 models. It doesn't guarantee determinism, but slightly improves it" (Google, Gemini API Veo docs, accessed 3 September 2026). Runway's own API specification is just as direct: "Using the same seed integer for an identical request will produce similar results." (Runway, Dev API reference, accessed 3 September 2026). Similar, not identical, and note the word identical itself: the moment your next shot changes the action, the camera, or even a few words of the prompt, the request is no longer identical to begin with, and the seed carries none of your character's identity forward regardless.

Kling goes further in the other direction. Its 3.0 Omni text-to-video, image-to-video, and Omni video generation specifications document no seed parameter at all. There is nothing to reuse on that model, documented or otherwise.

Which causes are hard capability limits, and what do you do instead?

Some of this genuinely is not solved yet, on any vendor, and no prompt closes the gap.

Reference conditioning reconstructs the face; it does not copy it. Even with a correct reference image attached, most vendors describe their asset system in terms of what each input contributes rather than a literal patch inserted into the frame. ByteDance's own guidance for Seedance's reference assets, for example, tells you to specify what each asset provides, such as appearance or action, framing the reference as an instruction the model interprets rather than pixels it transplants. No vendor checked here explains why identity still drifts on a demanding shot even with a correct reference attached; this is our own inference from how the feature is documented, not a vendor's stated limitation, and it is worth labelling as such. What is documented is the outcome: identity error tends to arrive gradually rather than all at once, and it worsens during fast motion, occlusion, and long, unbroken shots.

Certain shots put maximum pressure on the least stable part of the model. A clean frontal close-up of a human face, held for several seconds, is the hardest case in the field, because it asks the model to hold exactly the features it reconstructs least reliably, in full resolution, with nowhere to hide an error. This is a capability limit rather than a wording gap, and rewriting the sentence does not change what the model is being asked to render. The complete set of shot-craft responses to this, wider framing, broken eyelines, backlight, cutaways, is catalogued in the companion technique post rather than repeated here, because it is a list of what to do, not a diagnosis of why the problem exists.

A platform-level block is not a capability gap you can prompt around, but the underlying goal may still be reachable. Seedance's real-face restriction above is the clearest example: no rewording opens it, because it is not a documented capability limit on identity fidelity, it is a deliberate policy on what kind of input the model will accept at all. The distinction matters because the fix is different in each case. A capability limit means change your expectations or your shot list. A blocked input with a documented alternate route means use the route, not a cleverer sentence aimed at the same closed door.

Sort your bucket before you touch the prompt again

None of the three buckets responds to the other two's fix. Rewriting a character block does nothing if the request never attached a reference image. Attaching a reference image does nothing for a face that changes between two differently-worded shots because you never restated its identity. And no amount of either fixes a frontal close-up that no vendor has solved yet. The fastest thing you can do the next time a character changes between clips is not to rewrite the prompt immediately, it is to work out which of the three problems you actually have.

Prompt Architects does not generate video. It stores, versions, and enhances the prompts you feed to the models that do, which is exactly the layer where a character block belongs once you have written it, so you paste it identically instead of retyping a slightly different version on shot four. For the ranked playbook of what to actually do once you know your bucket, see keeping a character consistent across clips. For why the visual symptom looks the way it does frame to frame, see why AI video morphs and warps. And if your AI video has the opposite problem, barely moving at all rather than drifting, that is a separate, equally sortable diagnostic in why does my AI video barely move.