LoRA Schedule (WAN, hooks)

The LoRA switchboard for multi-generation Wan loops

Long Wan workflows - SVI-style continuations, multi-scene takes, batch loops - run the same graph many times. Sometimes you want that: the same character LoRA on every pass. Sometimes you want a phase change: a style LoRA on generations 0–3, a different character adapter from generation 4 on, a "cinematic" LoRA only on odd passes. Doing that with static LoRA nodes means duplicating the whole sampling chain per phase. This node replaces the duplication with a schedule.

How it works

Feed it a generation_index (the loop counter - wire forLoopStart.index or your loop's counter into it) and it evaluates up to 64 slots. Each slot has a lora_name, a strength, a preset, and start/end range. On every generation it works out which slots are active and bundles them into a LORA stack output that you feed into IAMCCS_ModelWithLoRA (or the LTX-2 variant) as the stack to apply.

The presets are where the ergonomics live:

• custom range / manual_range - use slot_start/slot_end; end = -1 means "active from this generation onward."
• all generations - always on. gen 0 only, gen 1 onwards, even gens, odd gens, every 2nd gen, every 3rd gen - self-explanatory phase patterns.

Slots stack: overlapping active slots combine, so you can have an always-on base LoRA in one slot and phase LoRAs layering on top. model_type (flow/wan2x/standard) controls the key-remapping logic for the stack, matching the rest of the pack's WAN LoRA system.

Outputs: lora (the resolved stack for this generation), active_slots (how many fired - a great sanity check), report (which slot, preset, LoRA, and strength ran on this pass), and a linx contract object.

The hook mechanics

Two implementation details actually matter if you're debugging:

• IS_CHANGED returns NaN, so the node re-executes every iteration instead of caching - required, because the schedule output changes per generation even though the graph didn't.
• The check_lazy_status method forces the executor to evaluate the upstream loop start before schedule() runs, so generation_index is always the real iteration index and never None. That's a workaround for a ComfyUI lazy-validation quirk; you don't need to do anything, but if you ever see a "generation_index is None" error, it's this protocol failing, and recreating the node usually fixes it.

In the real world

Install via the pack: ComfyUI Manager (search "IAMCCS") or clone IAMCCS/IAMCCS-nodes into custom_nodes, restart. Keep your always-on LoRAs in the pack's IAMCCS_WanLoRAStack and use this node only for the phase LoRAs - that keeps the schedule readable. And read the report output before you trust a run: "active_slots=2" with the wrong names in the report is usually a preset typo, and it's the fastest way to catch a schedule that silently applied nothing.