LoRA Runtime Bridge (WAN, loop-safe)
The loop-safe way to swap LoRAs between generations
- default_lora
- linx
- lora
- active_slots
- report
- generation_index
LoRAs are the easiest way to steer WAN video - character, style, speed, you name it - but in a long looping workflow, "which LoRA is active" can't be a static wire. It has to change per generation. IAMCCS_WanLoRARuntimeBridge ("LoRA Runtime Bridge (WAN, loop-safe)") is the node that makes dynamic LoRA injection work inside a loop: it takes a generation_index, a scheduled linx object, and an always-on default_lora, and outputs a single resolved LORA for exactly that generation.
The "loop-safe" part is the whole point. In IAMCCS's WAN pipelines, LoRA stacking flows through custom IAMCCS_WAN_LORA_LINX objects that carry per-slot names, strengths, and schedule rules. Instead of rewiring LoRA nodes between loop iterations (which ComfyUI makes painful), you build the schedule once, feed it into this bridge, and let the generation index pick the active slots at runtime. It's a resolver: scheduled lora data in, concrete LORA out.
The inputs
generation_index- the loop counter. This is what the schedule keys off.default_lora- a LORA stack that's always active, every generation. Your base look.linx- theIAMCCS_WAN_LORA_LINXschedule (built byIAMCCS_WanLoRAScheduleor a stack node). The per-generation extras.inject_tag/log_prefix- logging cosmetics; useful when several bridges are in one graph and you need to tell the console output apart.model_type_override-inherit(default, take it from the linx),wan2x,flow, orstandard. WAN 2.2's Flow weights and WAN 2.1 use slightly different key remapping, and this tells the stack which one to apply.
Outputs: lora (the resolved LORA for this generation - feed it to your Apply LoRA / WAN model patch), active_slots (how many schedule slots fired), report (which LoRAs and strengths landed on this generation), and a generation_index pass-through.
How it fits the pack
This is the companion to IAMCCS_WanLoRASchedule. The schedule node is the authoring surface - 64 slots of ranges and presets. The bridge is the execution surface - turn that plan into a live LORA each pass. The pack's original reason to exist was fixing LoRA loading in native WANAnimate pipelines (without WanVideoWrapper), and this node family is that fix's current, loop-aware form.
Install
Standard IAMCCS-nodes:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
or ComfyUI Manager → search "IAMCCS" → restart. No model downloads; you supply the LoRAs. Compatibility floor: ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.
One thing to know
The bridge only outputs one LORA per call - if you're used to multi-LoRA stacks, the resolution happens inside (slots merge into the single output), not via multiple output wires. And keep an eye on active_slots: if it reads 0 when you expected a phase LoRA, your range or preset is off, and the report string will tell you exactly which rule matched (or didn't).
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| generation_index | INT | 00–1000000 | — |
| inject_tag | STRING | inject | — |
| log_prefix | STRING | WAN LoRA runtime bridge | — |
| model_type_override | COMBO | inherit | 4 options: inherit, wan2x, flow, standard |
| default_loraopt | LORA | — | |
| linxopt | IAMCCS_WAN_LORA_LINX | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| lora | LORA | — |
| active_slots | INT | — |
| report | STRING | — |
| generation_index | INT | — |