LoRA Stack (Model In?Out) WAN
Four LoRAs, one node hop, no stack-then-apply tango
- model
- lora
- MODEL
IAMCCS_WanLoRAStackModelIO is the pack's flagship convenience: take an already-loaded MODEL, apply up to four LoRAs to it in a single node, and get the patched MODEL out the other side. No separate "build stack" node, no stack-output hand-off - the stack and the apply are fused. If your WAN 2.2 / flow workflow has a base model, four character or style LoRAs, and a sampler, this is the cleanest way to wire them.
This node also sits at the heart of why the whole pack exists. The README's origin story: in native WANAnimate pipelines (no WanVideoWrapper), LoRA loading is broken - most weights get silently ignored and visual consistency falls apart. IAMCCS-nodes' fix is a WAN-style key remap that makes LoRAs load correctly at the torch level without the wrapper. This node inherits that machinery, which matters because the bug is real and people hit it all the time on WAN 2.2 Animate graphs.
How it works
You pick up to four LoRAs from the lora1–lora4 dropdowns (populated from your ComfyUI/models/loras folder) with per-slot strength1–strength4. Slots set to "no" or strength 0.0 are skipped, so leaving three empty is fine. The model_type dropdown chooses the key-remap logic: wan2x (WAN 2.1/2.2), flow (the default, for Flow-based checkpoints like WAN 2.2 LightX2V), or standard (no remap, plain apply). The remap is what makes WAN 2.1, 2.2, LightX2V, and Flow LoRAs talk to each other without you hand-editing keys.
There's also an optional lora input that accepts a LORA stack from another node (like the classic IAMCCS_WanLoRAStack), letting you exceed four LoRAs by chaining a prebuilt stack in - the README's recommended move for animation graphs that want more than four.
Inputs and outputs
Inputs: model, lora1–lora4, strength1–strength4, model_type, optional lora. Output: a single patched MODEL, ready for KSampler, WanAnimate, or your video pipeline.
The two that matter most: model_type (get this right or the remap won't) and the strength sliders (WAN LoRAs are usually happiest around 0.7–1.0, and you can go negative to push against a LoRA). If no LoRA is selected it warns and returns the input model unchanged - a safe fail, not a crash.
Installing it
Part of the IAMCCS-nodes pack. ComfyUI Manager → search IAMCCS, or:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Restart ComfyUI; it's under IAMCCS/LoRA. No pip requirements, no model downloads - you bring the base WAN/Flow checkpoint and your .safetensors LoRAs, which it loads straight from the standard loras folder. README floor: ComfyUI ≥ 0.3.0, Python ≥ 3.12, Torch ≥ 2.8.
Where people get burned
- Wrong
model_type. AstandardLoRA treated asflowgets key-remapped into nonsense (or "missing optional weights" warnings). Match it to the checkpoint family. - Dropping it in front of a sampler that isn't actually the one using the model. The patched MODEL is a new object - wire its output onward.
- Expecting this to fix a LoRA that's simply trained wrong. The remap fixes key-naming and native-injection issues; it can't rescue a LoRA whose tensors don't match the architecture at all. If you see "missing optional weights" everywhere, check the LoRA is actually a WAN/Flow model LoRA first.
Inputs (11)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| lora1 | COMBO | no | 1 options: no |
| strength1 | FLOAT | 1.00-5–5 | — |
| lora2 | COMBO | no | 1 options: no |
| strength2 | FLOAT | 0.00-5–5 | — |
| lora3 | COMBO | no | 1 options: no |
| strength3 | FLOAT | 0.00-5–5 | — |
| lora4 | COMBO | no | 1 options: no |
| strength4 | FLOAT | 0.00-5–5 | — |
| model_type | COMBO | flow | 3 options: wan2x, flow, standard |
| loraopt | LORA | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |