FastH3 V2 · Current Editable Recipe Fingerprint (T8 EXP)

What it is

Every other node in this pack's FastH3 V2 chain wants to know what you ran. This one answers a different question: what does the graph look like right now, before you run it?

MiniMaxH3FastH3V2CurrentRecipeEXPT8 hashes your current setup - both MODEL/LoRA branches, the CLIP and both VAEs, the first frame, the global Relay plans, the external EAV configs, and the learned-upscaler bytes - into one stable identity. That identity is what downstream nodes compare against to decide whether the segment you just rendered is actually the segment the rest of the pipeline thinks it is.

Here's the part people get wrong: this is not the previous accepted job's SHA. It's the fingerprint of your editable recipe. It doesn't attest that anything executed, doesn't save a candidate, and doesn't authorize acceptance. It's the "here's what I'm about to do" half of a handshake; the "here's what I actually did" half lives in the attestation nodes.

How it works

Every input is folded into a canonical identity, and the result is published as a hash plus a model_id. Change one LoRA, nudge a width, swap a Relay plan - the hash changes, and anything downstream that was bound to the old hash will refuse. That refusal is the design, not a bug: it's how you avoid splicing a second segment onto a parent that was rendered with a different model, a different first frame, or a different prompt plan.

In plumbing terms (see comfyui-node-plumbing.md), this is an identity node: it exists to make an invisible thing - "the same recipe" - into a value the graph can carry on a wire. The pack leans on this pattern everywhere, because H3 long-video work is full of handoffs between runs where "same settings, right?" is exactly the assumption that breaks things.

Inputs worth setting deliberately

Plenty of these are wiring (model_pass1, model_pass2, clip, video_vae, audio_vae, first_frame, low_global_plan, high_global_plan, low_eav_config, high_eav_config, upscale_report_json), but the widgets are where you can quietly contradict yourself:

• chain_id - your name for this multi-segment job. Make a new one when you start a new clip rather than reusing an old string, or you'll be comparing against a parent that isn't the one in front of you.
• low_width / low_height (256×384) and width / height (512×768) - the two-stage geometry. These must match what the stages are actually sampled at.
• total_accepted_frames - pinned at 192, min and max. This node is hard-wired to the 8-second two-segment contract; there is no slider to move.
• first_seed (default 2609152201) and optional continuation_render_frames (90, floor 90, ceiling 124).

Outputs: current_recipe (the typed identity all the verification nodes consume), current_recipe_sha256, model_id, and report_json.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Restart ComfyUI completely and refresh the page - the pack's nodes are registered at import, so a hot reload won't show them. No extra pip packages: the shipped requirements.txt is intentionally empty so nothing can replace ComfyUI's Torch/CUDA stack. You'll need a recent ComfyUI with native H3 support plus the H3 weights (models/diffusion_models), Qwen encoder (models/text_encoders), and both VAEs (models/vae).

Where people get burned

The classic failure is the optimistic edit. You generate segment one, accept it, then go back and change a LoRA strength or a dimension "just slightly" for the continuation. The recipe hash moves, the binding check fails, and the node tells you the current job doesn't match the accepted parent. That's correct behaviour - the fix is a new chain, not fighting the check.

The second one is subtler: putting this node after the samplers. It doesn't read what ran; it reads what's wired into it. Feed it the same objects from the same loaders, or your hash is measuring a different graph than the one that produced your frames.