MiniMax H3 Temporal LoRA Blend

MiniMax H3 Temporal LoRA Blend lets a LoRA's influence change inside the clip: one set of LoRA weights before a moment, a different set after, blended over a feathered boundary. Want a character whose style shifts halfway through the shot, or a LoRA that only affects the opening? That's this node. The README is admirably honest that it's the least-exercised node in the pack - the maths is sound and it runs, but how it behaves across real LoRAs is barely mapped. Consider it an experiment with a clearly defined cost.

How it works

Each sampling step runs both models' predictions and blends them along the video timeline with a linear ramp centred on boundary_seconds, feather_seconds wide. One coherent motion trajectory, with the LoRA's influence handing over at your chosen second. Because H3 generates audio jointly with the picture, audio_from decides whether the soundtrack follows the same ramp or pins entirely to one side.

The inputs that matter

• model_base - the shared checkpoint, without the time-windowed LoRAs. The sampler loads this state.
• model_a - used before boundary_seconds. Usually model_base → your LoRA loader(s).
• model_b - used after the boundary. Leave it empty to just drop the LoRA at the boundary, back to the clean base.
• boundary_seconds - clip time where influence hands over. feather_seconds - width of the cross-blend; 0 is a hard switch between adjacent latent frames.
• audio_from - ramp (default) blends the audio stream on the same time curve; or pin the whole soundtrack's prediction to model_a / model_b.

One output, MODEL - feed the wrapped model to your sampler.

The wiring rules - read these before you wire

All three inputs must come from the same loaded checkpoint. The node enforces it: model_a/model_b must be patch-clones of model_base. Practically that means load the checkpoint once, then branch your LoRA loaders off that single loader's output - separate loader nodes create separate weight copies and the node errors.

Two costs to plan for: roughly 2× sampling time (both models run every step) and one extra VRAM copy of the LoRA-touched weights. It also needs the model fully resident - no lowvram streaming.

The one hard rule: do not put the turbo/distill LoRA on only one side. Both sides must expect the same sigma schedule. A distilled LoRA on side A and the stock base on side B means side B is trying to sample a schedule it was never trained for.

Where people get burned

The clone-check error is the classic - see the wiring note above; branch your loaders from one checkpoint. If you wire model_a and model_b as totally separate checkpoints you'll get an immediate error rather than a wrong render, which is the good kind of failure. And since this one doubles your sample time, don't leave it in the graph while you're iterating on the prompt - build the clip, then add the blend.

Install

Same pack recipe: Manager (search "H3 Studio") or cd ComfyUI/custom_nodes && git clone https://github.com/shootthesound/ComfyUI-H3Studio, restart, hard-refresh (Ctrl+Shift+R) for the frontend extension. Needs ComfyUI with MiniMax H3 support (v0.30.0+); no extra Python dependencies. If you try it, the author explicitly asks for feedback in the repo issues - good or bad - because that's the only way this one stops being experimental.