MiniMax H3 Motion Context Disk Join

Straight answer first: don't build new workflows with this node. The pack's own README calls MiniMax H3 Motion Context Disk Join deprecated and no longer actively maintained, and points new workflows at the all-in-one MiniMax H3 Extender, which absorbed cache management, trimming, validation, preview, seam correction and final assembly. This node is here because old .json workflows still reference it - and if you loaded one, you want to know whether to keep it or rip it out.

What it did

It was the low-level "persist a sampled clip to a disk cache" step in the pack's original multi-clip pipeline. You'd run a clip through an H3 sampler, hand the resulting LATENT to this node, and it appended that clip to an on-disk cache, writing a manifest and segment files so the sequence could survive across ComfyUI restarts and resume later. A chain of these, one per clip, was how you built a long video before the Extender existed.

The inputs reflect that role:

• samples: the generated LATENT of the current clip.
• validated: locks the clip into the cache so it isn't regenerated. Same chaining rule as the Extender - you can't validate clip N+1 before everything before it is validated.
• run_mode: full_batch or clip_by_clip. In clip_by_clip mode, once the first unvalidated candidate exists, later joins become metadata-only pass-throughs.
• fps: the frame rate recorded in the manifest (default 24).
• previous_cache: the H3_MOTION_DISK_CACHE output of the previous Disk Join in the chain.
• trim_frames: how many frames of the previous clip to carry forward, wired in from the RAM motion-context node.

It's a lazy node in the ComfyUI sense - it only asks its upstream sampler for samples when there's actually a new clip to generate, so a validated chain reuses the disk state instead of re-sampling. Outputs are the updated cache handle, cached_samples, clip_count, frame_count, status, cache_size_mb, cache_path and build.

Should you migrate?

If an old workflow loads and works, there's no emergency. But this node isn't being fixed, and the Extender does everything it did plus validation, references, preview, color correction and export in a single node - one that's actively developed. When you next open that project, consider rebuilding the sampling side around the Extender and pointing its cache at the pack's Final Decode / Preview node. Same install, same cache format, far fewer moving parts.

Installing the pack (to run the old node)

cd ComfyUI/custom_nodes
git clone https://github.com/tritant/ComfyUI_MiniMax_H3_Extender.git

Restart ComfyUI, or use Manager and search MiniMax H3 Extender. The only dependency is imageio-ffmpeg, and you still need the MiniMax H3 weights (~42.5 GB) plus a VAE and audio VAE.

One caveat that predates the deprecation: because the cache lives on disk keyed by clip index, changing a parameter upstream and re-running can truncate the chain past the changed clip. That's by design - it invalidates everything downstream rather than letting a stale segment into the sequence. The Extender's validation system is just that same rule with a friendlier face.