Character Consistency: Character Sheets, Reference Images, and Style Locking — Keeping the Same Person the Same Person in Every Shot

Three locking techniques and what each holds

Engineering offers three, differing widely in price and effect. The conclusion first, then each in turn.

A prompt template is the cheapest, essentially extracting what must be identical in every image into a constant. Style, lighting, depth of field, vertical composition, no watermark — those descriptions are verbatim identical across every image in this course. What it holds is the frame's overall feel; skip it and you get a finished cut half photoreal and half animated. What it cannot hold is a face, because facial detail cannot be exhausted in a hundred words.

A random seed is the most misunderstood. Many believe fixing the seed locks the character, when what it locks is reproducibility: the same model, the same prompt, and the same seed rerun gives the same image. That is extremely useful while debugging — change one word and see how the frame moves with everything else fixed. But every shot in a short drama naturally has a different prompt (different action, different scene), and once the prompt changes the same seed samples an entirely different person. A seed is a reproducibility switch, not a consistency switch. That is followed up on in nearly every interview touching consistency.

A reference image is the genuine solution for a face. MiniMax's image endpoint calls the field subject_reference, shaped in the request body as an array whose elements carry type and image_file; type currently supports only character, and image_file takes a public URL or a Base64 data URL of a JPG or PNG under 10MB. Two limits must be remembered: type has only the character kind, so you cannot lock a prop with it; and one request carries one reference image. Note those are the image endpoint's limits and not every endpoint's — the video endpoint differs, covered separately below.

Below is all three stacked: the template as a constant, the seed fixed, and the reference image taken from the character card.

// The course-wide style template: spliced verbatim onto every image, the cheapest consistency technique
const STYLE = 'urban short-drama texture, soft studio lighting, shallow depth of field, photoreal portrait, vertical composition, no text watermark'
 
async function generate({ prompt, referenceImage, seed }) {
  const res = await fetch(`${process.env.MINIMAX_BASE_URL}/v1/image_generation`, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.MINIMAX_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'image-01',
      prompt: `${prompt}. ${STYLE}`,
      aspect_ratio: '9:16',
      n: 1,
      seed,
      prompt_optimizer: false, // false by default; enabling it rewrites your prompt and reproducibility is gone
      response_format: 'url',
      // type supports only character, and one request carries one reference image
      ...(referenceImage ? { subject_reference: [{ type: 'character', image_file: referenceImage }] } : {}),
    }),
  })
  const json = await res.json()
  // HTTP 200 does not mean success; the business error code is in base_resp.status_code
  if (json.base_resp?.status_code) throw new Error(`image endpoint failed ${json.base_resp.status_code}`)
  return json.data.image_urls[0]
}

import os
import httpx
 
# The course-wide style template: spliced verbatim onto every image, the cheapest consistency technique
STYLE = (
    "urban short-drama texture, soft studio lighting, shallow depth of field, "
    "photoreal portrait, vertical composition, no text watermark"
)
 
 
def generate(prompt: str, reference_image: str | None = None, seed: int | None = None) -> str:
    body: dict = {
        "model": "image-01",
        "prompt": f"{prompt}. {STYLE}",
        "aspect_ratio": "9:16",
        "n": 1,
        "prompt_optimizer": False,  # False by default; enabling it rewrites your prompt
        "response_format": "url",
    }
    if seed is not None:
        body["seed"] = seed
    if reference_image:
        # type supports only character, and one request carries one reference image
        body["subject_reference"] = [{"type": "character", "image_file": reference_image}]
 
    res = httpx.post(
        f"{os.environ['MINIMAX_BASE_URL']}/v1/image_generation",
        headers={"Authorization": f"Bearer {os.environ['MINIMAX_API_KEY']}"},
        json=body,
        timeout=120,
    )
    data = res.json()
    # HTTP 200 does not mean success; the business error code is in base_resp.status_code
    if data.get("base_resp", {}).get("status_code"):
        raise RuntimeError(f"image endpoint failed {data['base_resp']['status_code']}")
    return data["data"]["image_urls"][0]

The look test flow: settle one master image and derive from it

With the reference image as a tool, the flow follows naturally: spend the effort rolling one master image you are happiest with, then have every later image reference it.

That is exactly how a crew does look tests. The art department does not decide on the lead's appearance on the day; they shoot a set of look tests in advance and pin them to the wall as the standard for everyone. The base image is that photograph on the wall.

Three steps concretely:

Step one, generate a base image per character. This step carries no reference image (there is none yet) and does carry a fixed seed, and is worth rolling a few times for a human to pick. This is the one place in the pipeline where human involvement is recommended — picking one image determines the look of dozens of shots, and that time is well spent. Once picked, write the path back to the character card's referenceImage field.

Step two, derive multiple angles, expressions, and costumes with the base image as reference. Front, three-quarter, angry, smiling, with each prompt changing only the body description while the reference image stays the base. Note that all derive from the base image rather than from the previous one — the latter accumulates deviation image by image, and by the fifth it is not the same person, a phenomenon called drift.

Step three, register the derivatives too, so every later shot needing a first frame takes one rather than regenerating.

An easily missed detail: fix the same seed across derivatives too. The reference image governs the face and the seed governs the sampling origin of every other degree of freedom, and the two together make the set look shot on the same day on the same stage.

Scenes and props cross over too

With the character locked, the second failure point is the scene.

The same rainy-night apartment block is six stories in shot eight and twelve in shot twelve, with the street lamp going from warm to cool — the audience will not say the scene is inconsistent, they will find the drama baffling. Props are more obvious: the phone driving the whole plot is a black slab in shot three and a folding phone in shot seven, and the plot collapses on the spot.

The remedy follows the same thinking as characters with the order reversed: scenes and props need not be generated per shot and should be made once before shooting and then referenced.

Because scene reuse is extremely high. Forty shots usually happen across three to five scenes, meaning thirty-odd shots share one batch of plates. Generating and registering those plates in advance takes an episode from forty scene generations to five — the easiest one-time saving on this line.

One easily missed thing to record while registering: which shot this image is for and what the prompt was. When something goes wrong you must be able to answer how shot twelve's building was generated, and being unable to means rerolling.

The asset library's minimal design

Now those images can have a proper home. It needs no database, only four things: an identifier, some metadata, a file, and one deduplication.

The identifier is the deduplication key, which decides what counts as the same asset. The key judgment: the key must be computed from content that changes the image, not from a filename or a path. Using a path as the key has two opposite harms: change the directory structure once and every cache entry invalidates, paying again; and change the prompt under the same path and the cache wrongly hits, so the reader sees an old image despite an edited description — which is the crossing-over.

So what participates in the hash is: the asset kind, its owner, the variant name, the full prompt, the reference image path, and the seed. Change any one and it must be regenerated; leave all six unchanged and it can be safely reused.

import { createHash } from 'node:crypto'
 
// The deduplication key = a content identifier. Any of the six that changes the image must be hashed
export function assetKey({ kind, ownerId, variant, prompt, referenceImage, seed }) {
  const material = [kind, ownerId, variant, prompt, referenceImage ?? '', seed ?? ''].join(' ')
  return `${kind}-${createHash('sha1').update(material).digest('hex').slice(0, 12)}`
}
 
// This is the only place in the pipeline that calls the image endpoint, and the only place deduplication happens
export async function ensureAsset(lib, input) {
  const id = assetKey(input)
  const cached = lib.find(id)
  if (cached) {
    console.log(`reused ${id}`)
    return cached // not one call to the endpoint, and therefore not one cent
  }
  const url = await generate(input)
  const record = { id, ...input, path: await download(url, input.outPath), at: new Date().toISOString() }
  lib.register(record)
  return record
}

import hashlib
from datetime import datetime, timezone
 
 
# The deduplication key = a content identifier. Any of the six that changes the image must be hashed
def asset_key(kind, owner_id, variant, prompt, reference_image=None, seed=None) -> str:
    material = " ".join([kind, owner_id, variant, prompt, reference_image or "", str(seed or "")])
    digest = hashlib.sha1(material.encode("utf-8")).hexdigest()[:12]
    return f"{kind}-{digest}"
 
 
# The only place in the pipeline that calls the image endpoint, and the only place deduplication happens
async def ensure_asset(lib, **input) -> dict:
    asset_id = asset_key(**{k: v for k, v in input.items() if k != "out_path"})
    cached = lib.find(asset_id)
    if cached:
        print(f"reused {asset_id}")
        return cached  # not one call to the endpoint, and therefore not one cent
 
    url = await generate(**input)
    record = {
        "id": asset_id,
        **input,
        "path": await download(url, input["out_path"]),
        "at": datetime.now(timezone.utc).isoformat(),
    }
    lib.register(record)
    return record

Beyond those six, the metadata records the file path, what this cost, and the generation time. Files land under assets/ layered by kind, with the index written as an assets/index.json recognized again after a restart.

This design is deliberately crude, because it solves only not regenerating within one run. A genuinely complete cache key design handles more: whether a new model version counts as the same asset, whether a changed prompt template invalidates everything, whether the cache should expire. Those are settled together in D8's workflow engine, and today saves the most direct money.

Generation failures and content review rejections

The last section is about failure, because batch generation will encounter it and mishandling is expensive.

The image endpoint's error comes from base_resp.status_code, and the first rule: HTTP 200 does not mean success. Judge only the HTTP status and you take a business error for a normal response and then get an incomprehensible empty-value error parsing data.image_urls, with the investigation heading entirely the wrong way.

With the status code in hand, sort by whether doing something different would help:

• Waiting helps: 1002 rate limiting and various server errors. A retry after backoff usually succeeds, and the program can carry this class itself.
• Only changing the input helps: 2013 invalid parameters (usually an invalid reference image address or a prompt past the 1,500-character limit), and 1026 and 1027 tripping the content safety review. Those two give the same error ten thousand retries later, wasting money and exhausting the rate limit allowance.
• A human is required: 1004 authentication failure and 1008 insufficient balance. A program cannot solve them and retrying only delays the alert.

// The criterion is not the status code's first digit but whether doing something different would help
const RULES = {
  1002: { kind: 'rate-limited', action: 'retry' }, // waiting helps; the program carries it
  2013: { kind: 'bad-request', action: 'fix-input' }, // invalid reference address, over-long prompt
  1026: { kind: 'content-blocked', action: 'fix-input' },
  1027: { kind: 'content-blocked', action: 'fix-input' },
  1004: { kind: 'auth', action: 'alert' }, // a program cannot solve it; retrying only delays the alert
  1008: { kind: 'insufficient-balance', action: 'alert' },
}
 
export function classify(statusCode) {
  // An unseen code is treated as a server fault: retryable, with a log line so somebody sees it
  return RULES[statusCode] ?? { kind: 'server', action: 'retry' }
}

# The criterion is not the status code's first digit but whether doing something different would help
RULES = {
    1002: {"kind": "rate-limited", "action": "retry"},  # waiting helps; the program carries it
    2013: {"kind": "bad-request", "action": "fix-input"},  # invalid reference address, over-long prompt
    1026: {"kind": "content-blocked", "action": "fix-input"},
    1027: {"kind": "content-blocked", "action": "fix-input"},
    1004: {"kind": "auth", "action": "alert"},  # a program cannot solve it; retrying only delays the alert
    1008: {"kind": "insufficient-balance", "action": "alert"},
}
 
 
def classify(status_code: int) -> dict:
    # An unseen code is treated as a server fault: retryable, with a log line so somebody sees it
    return RULES.get(status_code, {"kind": "server", "action": "retry"})

Batch settings add one more rule: one image's failure must not abort the batch. With shot seven of forty blocked by review, the right move is recording that one, continuing through the remaining thirty-three, and reporting the failure list at the end. Aborting wastes the money spent on the first six, and rerunning needs the deduplication key to avoid paying twice — the second value of the previous section's key.

Why content review blocks things, how prompts should be changed, and what labels exports need are a whole compliance subject covered on D11. Today reaches only three things: sorting correctly, not retrying blindly, and a readable failure list.

Source Reading

Hands-On Lab

starter/ has four exercise points cut out, two in the asset library and two in the main flow, all runnable offline under MOCK=1. Run it as-is once and note the three numbers in the report's last three lines: registrations far below generations, two more images generated on the repeat request, and the comparison group all identical — those three are your to-do list, each exercise fixing one. Offline, a placeholder image's color comes from the prompt and the reference image, so whether a reference was carried genuinely changes the output file and the fingerprints compare.

1. Generate one base look test per character, write the paths back to the character cards' reference image field, and confirm two base records appear in the index.
2. Derive three variants from the base image, and observe every log line ending with the "with reference image" marker.
3. Batch-generate the scene plates used by the shots and register them, confirming only the scenes actually referenced were generated.
4. Request the same batch of scenes again verbatim and see "reused" rather than "generated," with 0 regenerations in the report.
5. Run the same derivation with reference images off, compare the two groups' fingerprints as all different; with a real key attached, open both groups side by side and judge by eye which one is still the same person.

Interview Questions

Today's 3 questions are in the question bank below, weighted toward the consistency problem caused by a generation model having no memory, what a reference image and a seed each lock, and the cache key design for asset reuse. Expand each one and read the analysis before the key points — question 2 on seeds is this chapter's easiest to get wrong and nearly always follows a question about consistency. The high-frequency labels for the domestic and overseas markets are there so you can pick by target market.

Checklist and Tomorrow

• Wire up an image generation API, and batch-produce character sheets and scene images from the shot data
• Explain what character consistency relies on at the API level, and lock down a character's look with a reference image
• Build the generated assets into a searchable asset library, so later shots reuse them directly instead of regenerating
• Say what each of a prompt template, a random seed, and a reference image does and does not lock
• Explain why derivatives all reference the base image rather than the previous one
• All 5 acceptance criteria of the lab pass
• Answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D4) turns these static images into moving shots: taking today's chosen look test as a video's first frame and having the model act on for six seconds. Images before video is deliberate, because video generation is the slowest and most expensive step on this line — pin the look down with a one-cent image first, then spend several yuan animating it, and a mistake costs two orders of magnitude less. D4's focus is not picture quality but how an asynchronous task client is written: submit for an identifier, poll for status, collect for an address, download to disk, with all four steps able to go wrong.