H3 RefCap Replay

The short version

If you only learn one node in this pack, learn this one. H3 RefCap Replay takes a captured RefCap plus a prompt and hands the sampler conditioning that is bit-for-bit what MiniMax H3 Reference to Video would have produced from the original photos. The author tested it: clips came out pixel-identical to native references. Not "close enough" - identical.

That's a strange thing to get excited about, so here's why it matters. Reference-conditioned video is the one place where H3 currently has no open-weight peer: it takes photos of a person and puts them in a new shot with the face intact, and the whole consistency problem that still dogs image models (edit it, re-emit it, watch it drift) simply isn't the framing here. But the native path makes you re-pick files every time, and re-picking files means you'll eventually re-pick them in a different order and wonder why the character changed. A RefCap is that photo set, frozen and named.

What it does under the hood

H3 reaches the DiT through two channels, and Replay rebuilds both.

It decodes the RefCap's stored pixels - the resized version the text encoder originally saw - builds the <Picture 1>: [vision block] <Picture 2>: [vision block] … presentation with your prompt appended, and runs it through the CLIP/Qwen3-VL encoder. Then it attaches the stored VAE latents as minimax_refs blocks, which is the same dictionary the native node writes. It is literally the native node's code path with the file loading, resizing and VAE encode skipped, because those steps already happened at capture.

The consequence you care about: the prompt attends to the images the way it natively would. Qwen is causal, so prompt tokens sit after the vision blocks and can see them. That's the property H3 RefCap Apply (cached) gives up to save a pass through a 32B encoder, and it's why the author tells you Replay is the honest one.

Inputs and outputs

Three inputs, no more:

• clip - your MiniMax H3 CLIP/text-encoder load. Same one the reference node would use.
• prompt - multiline, dynamic prompts supported. Refer to the photos by their presentation labels: <Picture 1>, <Picture 2>, and so on, in capture order. Write the labels into the sentence; the model was trained reading them.
• refcap - the dropdown of everything in ComfyUI/models/refcaps/.

One output, CONDITIONING, which goes into your sampler's positive, next to whatever negative you're using. The latent does not come from here: take it from Empty MiniMax H3 AV Latent, exactly as with the native reference node. That trips people up because a lot of video workflows expect the reference node to hand back a latent too.

Install

Manager → search ComfyUI-RefCap → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/AEmotionStudio/ComfyUI-RefCap.git

No pip installs, no extra models - but you do need the H3 stack itself: the int8 ref2va DiT into diffusion_models/, the Qwen3-VL-32B nvfp4 encoder into text_encoders/, both VAEs into vae/, and optionally the 4-step Lightning LoRA into loras/. The pack ships H3 RefCap 2 - Replay (exact) as a template, which is worth opening once just to see which socket feeds which.

Where people get burned

You captured without the photos. If Capture was run with nothing wired to its image_1–image_9 slots, the file has latents and no pixels, and Replay refuses with "has no stored pixels". That RefCap is Apply-only. Re-capture with the photos connected - that's the only fix, and it's cheap.

You expected the prompt to be free-form text about anything. It is, but the reference labels are positional. If you captured five views in the order front, 3/4 left, 3/4 right, profile left, profile right and then write <Picture 3> meaning "the profile", you get a different face angle than you asked for. The capture order is the contract.

You're feeding it into a graph that also has references. Unlike Apply, Replay just builds its own conditioning from the tokenizer, so mixing is less explosive - but if you want two RefCaps in one shot you don't stack Replay nodes. You want H3 RefCap Select chained into H3 RefCap Replay Pack, because the reference node's caps (9 images, 3 clips, 3 audio) have to be counted across the whole pack.

Cost. Replay re-encodes the reference presentation every queue. At match the author measured around 37 s per clip; capturing from 1024 px photos at ref_image_size = max costs about 2.2× that and buys +0.06 face similarity. Worth it for a hero shot, not for exploration. Their measured ArcFace: 0.660 at match, 0.724 at 1024 px - both comfortably above the "recognisable" calibration line.

One non-obvious caveat if you're chasing exactness: the author found reference rows themselves aren't bit-stable between different encodes on the nvfp4 encoder - every row shifted by about 0.03% when the prompt length changed, including row 0. So "identical to native" means identical to what native would produce for that same presentation, not identical to some other queue's run.

Does it replace a LoRA?

For video identity, yes for most people. No training, no dataset, one file per character, and the face holds across shots. What it doesn't do is teach the model a style; a RefCap replays evidence, it doesn't add knowledge.