Workflow
Keeping a character consistent across a series
Nothing carries between runs on its own: every generation is built from scratch, so one written description lands on a slightly different face each time you press start. You hold a character steady by supplying it as a picture instead of re-describing it, which means drafting the subject once, keeping the frame that works, and feeding that frame back into every take that follows.
An anchor is a picture, not a paragraph
What holds an identity still is an attachment, not a better sentence. Ye et al., in the IP-Adapter paper, give the reason plainly: getting the image you want out of text alone is tricky because "it often involves complex prompt engineering". There is no adjective for a particular jaw, and no quantity of them adds up to one.
Not every picture makes a good anchor. A plain, evenly lit portrait usually beats a dramatic frame, because there is less in it to be copied by accident: a hard rim light or a strong colour cast is evidence too, and the model has no way of knowing you meant only the face. Keep the anchor boring and let the prompt do the staging.
A picture can also arrive as a frame rather than as evidence, which is a different job under different rules; from a still to a video covers that split and the cropping it forces on you.
Capability is declared, not inferred
Every model in the catalog publishes what it does: text to image, image to image, text to video, image to video, reference to video. The field is written down rather than worked out from whether the model happens to accept pictures, so the model page, the catalog endpoint and the server all agree on what a body should look like.
Models that read references declare their own minimum and maximum, and the refusals run both ways. One built around references turns down a request arriving without any. One that reads none turns down a request that carries them, rather than discarding the attachment and rendering regardless. The second refusal is the one that saves you money, because a discarded picture leaves you holding an output that never used it and nothing on screen to say so.
Valid sizes belong to the model as well, and are not inherited from a relative with a similar name. Attachments can carry a surcharge, which the generate button and choosing resolution and length both total for you.
Draft once, keep the keeper, feed it back
Begin on a model that works from description alone, where the character is still negotiable and you are paying to find out who they are rather than to protect anyone. Iterate the wording until one frame is right; getting there is its own craft, and designing an original character is that craft end to end.
Then keep it, literally, by downloading the file. Outputs sit in your Gallery for a limited window and are then removed from the server, so an anchor you mean to reuse for months has to live somewhere you control. This is the step that quietly ends series.
Handing it back is not a matter of copying the link. A finished generation is served behind your credentials and the provider doing the render cannot sign in as you, so the file has to be uploaded and attached by the address that comes back; from a still to a video has the endpoint and the rejections. In the panel, the reference box does it for you.
Each later shot is then one request with a different scene: same attachment, same character wording, only the staging rewritten. The API reference has the body, and writing prompts without a filter has the wording discipline that stops the rest of the frame moving along with it.
Where identity drifts, and what to change
Reproducibility here comes from the attachment and not from a number you can write down, because nothing in a request pins the sampling; choosing resolution and length has that mechanism. Two identical submissions are two independent draws, so a series held together by description alone is drifting by construction.
Rewriting the prompt between takes is the commonest cause. Every re-worded description reopens the negotiation over everything you did not mean to touch, the face included. Move one clause at a time and you can see what moved with it.
Promoting each new output to anchor is the second. A generation restates its inputs rather than copying them, so an anchor built on an anchor built on an anchor walks steadily away from where it began. Keep an anchor set: the original keeper stays in every request and good new frames join it rather than retire it. That this is difficult is not your imagination. Avrahami et al., in "The Chosen One: Consistent Characters in Text-to-Image Diffusion Models", open on the observation that "the users that use these models struggle with the generation of consistent characters".
The third cause is an anchor that does not show the part that drifts. A three-quarter portrait says nothing about a buckle visible only from behind, so the model reinvents it every time. Add a view that shows it rather than a sentence that describes it.
It helps to know what you are not doing. DreamBooth (Ruiz et al., CVPR 2023) takes "just a few images of a subject" and fine-tunes the model so it "learns to bind a unique identifier with that specific subject". There is no training step here, so identity is re-derived from your pictures on every request. That is why it can slip, and also why you can change characters between two shots without retraining anything.
Carrying the character into video
Video splits the same way. A model that reads references still composes the shot itself, so who appears is fixed and where the camera stands is not. A model that opens on a picture animates the frame you made, which puts composition beyond argument and makes the crop your decision rather than the model's.
The order holds either way: build the anchor on an image model, hand that same file to video, and keep the character wording identical so only the action changes. The video overview covers the routes, and storyboards and previz covers a run of shots that has to read as one production.
Frequently asked questions
Can I use a generated image as a reference by pasting its URL?
No. A finished generation is served behind your credentials, and the provider fetching the reference cannot sign in as you. Upload the file and attach the address that comes back; the reference box on a model page does this for you.
Why does the same prompt give me a different face every time?
Because nothing in a request pins the sampling. A body carries a model, a prompt and that model's own settings, and not one of them fixes the draw, so two identical submissions are two independent results.
Should I replace my anchor with the newest output each time?
No. Each generation restates its inputs rather than copying them, so anchors built on anchors drift. Keep the original keeper in every request and let good new frames join the set instead of retiring it.
Does attaching more references make the result better?
More references is a narrower question, not a quality setting. Each picture takes a decision away from the model, which helps only when the decision it was taking was the one going wrong.
