Nodes/ComfyUI-MiniMax-H3-LongMedia/MiniMax H3 • Runtime Continuation Guider
ComfyUI Node

MiniMax H3 • Runtime Continuation Guider

The guider that finally knows what the previous clip looked like

By vizart-vj·Created 14 days ago·Updated 2 days ago· 71
MiniMax H3 • Runtime Continuation Guider
  • guider
  • long_media_plan
  • previous_av
  • guider
  • report
segment_index1

Here's the design problem behind every long-video tool: at the moment you build the conditioning for segment two, segment one has already been generated. So the conditioning can know the actual previous frames - it just has to be built at runtime, after the previous segment exists, instead of up front. That's what this internal node does. It's the "Runtime" continuation guider: it takes your guider, the long-media plan, and the actual previous AV latent, and rebuilds the guider's conditioning with the real previous-segment motion context baked in.

What it does

Four inputs:

  • guider - the base guider to extend.
  • long_media_plan - the plan object, which carries the overlap geometry and per-segment audio setup.
  • previous_av - the completed previous segment's latent. This is the key input, and the node validates it's a real latent with samples - it raises a V320 handoff error if you feed it an uninitialized placeholder.
  • segment_index - which segment you're preparing (affects audio shifting and overlap math).

Outputs: the rebuilt guider and a report string with the handoff facts: segment_index, previous_frames, overlap_frames, the motion-guide span in frames, and confirmation that a runtime previous latent is in use.

The mechanism

Two things happen. First, the guider is cloned with segment-appropriate audio conditioning - the plan tells it which audio slice belongs to this segment, and the previous latent is referenced for timing. Second, the motion context: it derives a guide span from the overlap (picking the largest H3-aligned value among 56, 39, 22, 5, 1 that fits inside the overlap) so the conditioning carries motion cues from the real prior frames. The console logs this as a "V320 RUNTIME MOTION HANDOFF," which is your tell that the runtime path engaged.

Why this matters

The whole point is that the alternative is stale - conditioning built from a plan's prediction of what the previous segment will be, not what it was. That's the difference between a handoff where the lighting and pose continue correctly and one where the model guesses. The internal mark in the name and the hidden-from-menu placement mean you won't normally construct this by hand; the Long Media Sampler wires the runtime handoff itself. You'd only reach for it if you're building the segmented sampling graph manually and want the same real-context continuity the built-in path gets.

Install

Ships in ComfyUI-MiniMax-H3-LongMedia. Manager search "MiniMax-H3-LongMedia", or:

cd ComfyUI/custom_nodes
git clone https://github.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia

restart, with the H3 checkpoint + VAEs available (MiniMaxAI/MiniMax-H3, ~42.5 GB, community license excludes US/EU/UK/Korea).

Troubleshooting

The one failure mode the code calls out: pass a previous_av that isn't a real sampled latent and you get the V320 runtime handoff error - the node refuses to build conditioning from an empty placeholder, which is a good error to hit early. If the console never logs the V320 handoff, your graph isn't on the runtime path (you may be wiring a static continuation instead), so continuity will be weaker. And if motion doesn't carry across even with the runtime path, check that overlap_frames in the plan is actually set - with zero overlap there's nothing for the guide span to hang onto.

CategoryMiniMax H3/LongMedia/LongMedia

Inputs (4)

NameTypeDefaultDescription
guiderGUIDER
long_media_planLONG_MEDIA_PLAN
previous_avLATENT
segment_indexINT11–100

Outputs (2)

NameTypeDescription
guiderGUIDER
reportSTRING