MiniMax H3 Motion Context RAM

Every long-video problem in MiniMax H3 comes down to one thing: the next clip needs to know what the last one did, or the character forgets how to move. MiniMax H3 Motion Context RAM is the node that makes that happen - the low-level conditioning engine that the pack's main Extender node calls internally, exposed as a standalone so you can build your own H3 chaining workflow outside the Extender.

What it does

You give it three things: the conditioning for your next clip, the next clip's latent, and the previous clip's latent (the context_latent). It extracts the tail of the previous clip, slices it into the number of video frames you asked for via context_length (5, 22, 39 or 56 - 22 is the default), and writes those frames back into the conditioning as H3 keyframes at their correct temporal positions. If you want audio continuity too, audio_context_length carries the matching audio tail from the same previous latent (0 means "use the full video context span").

The mechanism is the H3 keyframe system, which is how this model does video-to-video conditioning - reference blocks placed at specific frame offsets along the timeline. The node also patches older stock ComfyUI builds so the keyframes land at the right temporal coordinates even when the sampler's native API can't express interior anchors. That's why the outputs are what they are: a CONDITIONING (now carrying the minimax_keyframes), plus trim_frames (how many frames were consumed), video_context_tokens, audio_context_tokens and a build string.

The errors tell you how it works

This node is strict, and its errors are the fastest way to understand its limits:

• Batch size differs between previous and next clip → each run feeds exactly one clip's worth of context.
• Video latent channels differ → you mixed models or a non-H3 pipeline.
• Resolution mismatch - and here's the key line: "Latent motion context cannot resize." Unlike image references, motion context can't be resampled to fit. The next clip must be generated at the same resolution as the context clip, or the node refuses.
• Context window must be shorter than the next clip → you can't feed a 56-frame context into a 5-frame clip.

When would you actually use it?

Honestly: rarely, unless you're building a custom H3 pipeline and want explicit control over the conditioning. For a normal chain-clips-into-a-long-video workflow, the Extender node wraps this exact logic together with caching, validation, references and export - you get Motion Context RAM for free without wiring its conditioning output into a sampler yourself.

If you do go raw, the wiring is: sampler → latent and context_latent into this node → the conditioning output back into the sampler for the next clip → and the trim_frames output fed to a Disk Join node if you're persisting clips to disk. It's the classic plumbing pattern - one node that pulls values off a pipe, modifies them, and pushes them back on.

Installing

Same pack, same steps:

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

Restart ComfyUI (or Manager → search MiniMax H3 Extender). No extra dependencies beyond the pack's single imageio-ffmpeg, and the H3 weights themselves (~42.5 GB) - which, remember, carry a community license that excludes the US, EU, UK and South Korea.