H3 RefCap Replay Pack
Two characters and a location, one conditioning, one prompt
- clip
- pack
- conditioning
- label_guide
What it does
H3 RefCap Replay Pack is the payoff node for the whole pack-chaining idea. You hand it a chain of H3 RefCap Select nodes and it encodes your prompt with every selected view, exactly as MiniMax H3 Reference to Video would if you'd dragged all those photos in by hand. Bit-identical, per the author's parity check on three RefCaps at once - rows, tags and all eight reference latents.
Two things come back. conditioning, which goes to your sampler. And label_guide, a plain string that tells you what each label means: <Picture 3> = elf_ranger.safetensors view 12, yaw -45, <Video 1> = ..., <Audio 2> = ..., plus the total reference token count. That second output is not decoration. In a pack of three RefCaps with twenty views between them, guessing which picture is which is how you end up with the dwarf in the elf's cloak.
The mechanism, briefly
The native node numbers references <Picture 1..n>, <Video k> and <Audio j> in the order they're attached. A pack is data until Replay Pack renumbers it, and it renumbers in native order, not chain order: every image across every RefCap first, then each clip (with its soundtrack's <Audio j> immediately before its <Video k>), then standalone audio references.
That ordering detail is why the guide exists. Chain your Selects in the order elf → dwarf → cavern and the images come out elf first, dwarf next, cavern last - which is intuitive. But add a clip to the first Select and it doesn't slot in next to that Select's pictures; it moves to the whole pack's clip section. If you wrote <Video 1> expecting it to be "second thing in the chain", the guide corrects you in one line.
Once the images are attached, the prompt is encoded with the real pixels through the text encoder and the stored latents ride along in minimax_refs - the same dictionary the native node builds. All 50 DiT blocks attend to the reference block on every step. Nothing is compressed, averaged or resampled.
Inputs and outputs
clip- your H3 text encoder.prompt- multiline, dynamic prompts supported. Use the labels from the guide, and name your subjects in words too. The model will happily follow "the dwarf in <Picture 5> turns to face <Picture 1>", and if you've picked one view per character the labels are what binds the sentence to the pictures.pack- the output of the last Select in your chain.
Outputs: conditioning and label_guide. Latent from Empty MiniMax H3 AV Latent, as always with H3 references - the conditioning carries no latent.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/AEmotionStudio/ComfyUI-RefCap.git
Or ComfyUI Manager, search ComfyUI-RefCap, install, restart. No pip step; the repo has no requirements file. You do need the H3 model set - the int8 ref2va DiT, the Qwen3-VL-32B nvfp4 text encoder, video and audio VAEs, optionally the 4-step Lightning LoRA - and the licence on those weights excludes the US, EU, UK and South Korea, which is worth knowing before you plan around this.
The pack ships H3 RefCap 7 - Two characters as a template: three Selects, one Replay Pack, a label guide, and a muted Bake Pack node. It's the fastest way to see the chain shape, and the one to copy when you build your own.
The cap, and how to stay under it
The native node takes 9 images, 3 clips and 3 audio references per render, and Replay Pack enforces that across the whole pack rather than per file. Go over and you get "N images selected; MiniMaxH3ReferenceToVideo takes at most 9" - the one error message in this pack that's genuinely useful, because it names the limit.
Nine sounds like a lot until you have three subjects, and the token budget is tighter than the image cap: roughly 5,000 reference tokens buys 5 views at 1024 px or 9 at 736 px. Packing two characters plus a place, you want 2–4 views each.
What actually goes wrong in practice:
Bleeding. Two characters in one shot with five views each start sharing features - the model has a lot of faces in context and no explicit binding between them and your words. Fewer, more distinct views, plus explicit <Picture i> labels in the prompt, is the only lever the pack gives you. There's no per-reference weight here, by design.
A RefCap with no pixels. If any Select in the chain points at a file captured without its photos, Replay Pack refuses: "has no stored pixels". That's an Apply-only file; it can't ride in a pack. An empty chain throws "the pack is empty" - usually a views string that got reset to none.
Pack or bake?
If the cast is a one-off for this shot, chain Selects every time - you keep the freedom to swap views per render. If you keep rendering the same elf, the same dwarf and the same cavern, you're rebuilding the same chain forever, and every re-pick is a chance to pick differently. That's what H3 RefCap Bake Pack is for: freeze the selection into one view set file, and Replay Pack's job collapses into H3 RefCap Replay View Set with select = all.
My advice: chain while you're deciding, bake when you've decided. And re-bake whenever you re-capture a source, because the baked file holds copies, not links.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| prompt | STRING | — | |
| pack | REFCAP_PACK | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |
| label_guide | STRING | — |