MiniMax H3 Scene LoRA Scheduler

MiniMax H3 Scene LoRA Scheduler is the node that says "scene 1 gets the base model, scenes 2–3 get LoRA A, scene 4 gets LoRA B" - and it doesn't load or apply a single LoRA itself. That's the whole trick, and it's a good one. It routes pre-patched MODELs.

The insight: instead of re-implementing LoRA loading, the scheduler takes the ordinary ComfyUI model and LoRA loaders you already know and just switches between their outputs per scene. You build a Base model branch and up to four LoRA branches with normal loaders, then choose which one the active scene gets. The base_model input is required and is meant to be the exact unpatched MODEL that already feeds your workflow - so the scheduler slots in without changing how you load anything.

The inputs and the lazy bit

• state - from Current Shot. The active scene's lora_route (set per scene in the Plan) selects the MODEL branch.
• base_model - the unpatched/base route.
• lora_a through lora_d (optional) - each a MODEL from an existing ComfyUI LoRA loader, or a stack of LoRA loaders.

The genuinely clever part is the laziness. The tooltip spells it out: inputs are lazy, so an unused branch is not evaluated merely because it's connected. ComfyUI's lazy-evaluation machinery means a LoRA branch for a scene that never uses it doesn't get loaded into VRAM, doesn't get computed, doesn't exist for that pass. That's what makes per-scene model routing practical instead of a VRAM catastrophe.

The output is just model - only the active scene's selected pre-patched MODEL - plus a status STRING reporting the chosen Base/LoRA route and scene number. You wire the output to the sampler, or to Chain Context when Drift-Control owns the MODEL path.

Where you'd use it

Any production where scenes want different stylistic or character models. A two-minute piece with an establishing shot and a close-up interior could run the base model on the establishing wide and a stylistic LoRA on the close-ups. The main maintained use case, though, is combining this with between_scene_cleanup on Loop End: the fresh_scene memory policy exists exactly for model-switching chains - it unloads the previous scene's weights before the next scene's branch is loaded, which keeps a per-scene LoRA chain from accumulating VRAM.

Installing it

Part of ComfyUI-MiniMaxH3-Contex-Loop (ComfyUI Manager: "MiniMax H3 Contex Loop"), or:

cd ComfyUI/custom_nodes && git clone https://github.com/ethanfel/ComfyUI-MiniMaxH3-Contex-Loop.git

Restart ComfyUI. It adds no LoRA machinery of its own - you still need your LoRA files and the ordinary ComfyUI LoRA loader. Standing requirements: H3 weights, current ComfyUI with native Add Guide (PR #15439).

Common issues

The main trap is expecting the scheduler to load LoRAs for you - it won't, and if a branch is just a bare base_model dangling in, that's on the graph, not the node. Also, the selection is per-scene via the Plan's lora_route, so if every scene is coming out with the same model, check you actually set the route per scene rather than relying on a default. And when switching models leaves you OOM mid-run, add between_scene_cleanup (see Loop End) rather than shrinking your LoRA - the scheduler was built to be paired with it.