MiniMax H3 • Runtime Continuation Guider
The guider that finally knows what the previous clip looked like
- guider
- long_media_plan
- previous_av
- guider
- report
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 withsamples- 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.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| guider | GUIDER | — | |
| long_media_plan | LONG_MEDIA_PLAN | — | |
| previous_av | LATENT | — | |
| segment_index | INT | 11–100 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| guider | GUIDER | — |
| report | STRING | — |