H3 Continuation · External Relay Window (T8 EXP)

A single prompt describing a 20-second scene is a category error. What you actually want is "she's in the kitchen the whole time; at second 6 she turns to the window; at second 9 she says the line." That is what this pack calls a Prompt Relay plan - global description plus timestamped local events - and it is the only honest way to direct dialogue, entrances, or a punchline that has to land at a specific moment.

The problem is that a long video is a chain of generated windows. Each window has its own frame count and its own local time starting at zero-ish, while your plan is written against the film's absolute timeline. Something has to translate.

What it does

Relay Project takes one external global Relay plan and projects it onto one accepted window, using absolute motion time. Give it length - the segment's render frames, on the 17n+5 grid - and it works out which events fall inside this window, what the local phrasing should be, and what the compiled prompt text is.

It is pure bookkeeping. No encoding, no sampling. That is why you can safely run it twice with different lengths: LOW and HIGH are allowed their own projection nodes, because the two phases can have different windows and different frame counts.

accepted_end_frame is optional and defaults to -1, meaning "infer from the accepted source". Set it explicitly when you are deliberately placing this window on a hand-specified absolute end, which is how the external-take entry points place a new render relative to a source clip that has no native ancestor.

Inputs and outputs

• contexts - the typed accepted-window context. This is the object that knows the parent's absolute frame clock, so the projection must come from it; you cannot hand this node your own arithmetic.
• global_plan - the Relay plan (the H3_T8_PROMPT_RELAY_PLAN type from this pack's Prompt Relay nodes).
• length - this segment's render frame count, default 124.
• accepted_end_frame - -1 to infer, otherwise the chosen absolute end frame.

Two outputs feed two different places, and this is the part people get wrong:

• projected_relay goes into "External Relay ONE Phase" (the apply node) for this phase.
• compiled_prompt goes into the matching "ONE Phase Conditions" node - the text has to be encoded by that node before the apply node will accept it. The apply node compares the projected compiled prompt against the phase's encoded prompt and refuses if they differ.

report_json records the plan hashes and the projection, which is the artifact you want when you are arguing with yourself about whether an event landed where you thought.

The Relay rules that actually matter

Global text is for what persists: the person, their clothes, the room, the ambient sound. Local events are for anything that happens once. Putting a one-time line in the global block means it gets repeated across every window, which is the single most common way people wreck a long H3 generation.

Percent-based timing has to be selected as percent, not left on auto-equal, or your hand-entered numbers are silently ignored. And the plan has to cover the whole output: the pack's candidate workflows use a 193-frame plan to cover a 192-frame, 8-second output, which is the kind of off-by-a-few that a projector will not forgive.

Also worth knowing before you build a relay-heavy workflow: the pack documents that the joint_av_exp route - the one that generates dialogue - is not compatible with locked source audio. If you are locking the soundtrack, the apply node will refuse rather than quietly produce a wrong result.

Installing it

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

Quit and restart ComfyUI after; these EXP classes register at import. Manager search: "MiniMax H3 Audio T8". No pip step - the pack's requirements file is intentionally empty so an install cannot overwrite ComfyUI's Torch stack. Recent Core with native H3 support is required, plus the H3 weights, Qwen encoder and both VAEs.

Things that will bite you

Projection must match the phase it is applied to. Reusing one projector output for both LOW and HIGH when the two phases have different lengths will fail the apply node's frame-count and compiled-prompt checks - it is a hard refusal, not a warning, and the message names the mismatch. If LOW and HIGH genuinely share geometry, one projector is fine; if not, wire two.

Finally, if you changed the total duration, re-check the plan coverage length. Nothing here will stretch a plan for you.