MiniMax H3 · Multi-Shot Upstream Motion Context

Long-form video in one generation pass is a VRAM fantasy when your base model is a 33B omni-modal beast. The realistic route is chunked generation: render segment N, keep its tail, feed that tail into segment N+1 so the motion, audio and look carry across the cut. That is exactly what this node does, and it is the "conditioning" step of the IAMCCS R37 motion-context variant.

The key idea: the previous segment's native AV latent - video plus its audio - was saved to disk by the matching commit node (IAMCCS_MiniMaxH3MotionContextStateCommitR37). This node loads that latent back and hands it to the upstream motion-context core, which builds conditioning so the new chunk continues the old one's motion instead of starting fresh.

How it works

• Reads the shot plan and chunk table from cine_linx, and confirms the motion-context branch is actually active in the plan. If not - say the plan only runs ComfyKitchen attention - it returns your conditioning untouched with a "bypass" report. It degrades cleanly, which is nice.
• Applies "positioned guides" to the conditioning (timeline reference guides materialized at the right frames).
• For segment 0 (or when there's no prior trim), it's a pass-through: there's no previous latent yet.
• For later segments it loads the prior latent through the companion MiniMaxH3AutoChainLoadLatent provider node and runs the upstream motion-context apply with a video context tail (~22 frames default) and an audio context tail. The audio tail is what keeps dialogue and room tone consistent across the seam - a detail most chaining schemes skip.

The "trim" number that comes out of the provider must match the trim the planner promised. If it doesn't, the node refuses to continue with a shifted join rather than silently splicing a misaligned seam. That's strictness you'll be glad for later, and it's a genuinely unusual design choice for this ecosystem.

Inputs

• conditioning, latent, video_vae, audio_vae - the current chunk's conditioning and latent plus the two VAEs (video and audio) needed to handle the AV latent.
• cine_linx - the shot plan bus.
• segment_index - which chunk this is (0-based).
• render_id - names the chain run; the latent is stored under h3_context/<render_id>_clip<index>.

Outputs

• conditioning - the motion-context-conditioned version, wire it into the generator.
• trim_frames - how many frames of context tail the next stage must trim off the decoded output to get back to visible footage.
• report - what got applied and from where.

Install and dependencies

The pack install is standard:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

The real dependency ladder: you need MiniMax H3 itself in ComfyUI (open weights, ~42.5GB, released Aug 2026 - and check the H3 community license's territory exclusions before you assume you can run it), plus IAMCCS's companion addon ComfyUI-H3-Motion-Context-Auto-Chain (V0.1.2+) which provides the MiniMaxH3AutoChain* provider nodes. If that addon isn't installed or updated, this node raises a clear "provider node unavailable" error naming exactly what's missing.

Where people get burned

• Don't purge h3_context while a chain is running. The commit/load cycle is disk-based; deleting the latent store mid-run makes the load return nothing and the node errors out ("could not load the previous native AV latent"). Let the render finish, then clean up.
• This node needs the motion-context plan switched on (IAMCCS_H3_MOTION_CONTEXT active in settings). In the standard branch it's a pass-through - which is correct, but confusing if you expected it to always do something.
• It's chain plumbing, not a generator. Frames still come out of the generation nodes; this one only fixes what they continue from.