Build Scheduled WAN Model Bank

The IAMCCS pack started life as a fix for a real problem: in native WANAnimate workflows (no WanVideoWrapper), LoRAs were being loaded in a way that ignored most of their weights. The fix the author built was a stack-and-apply LoRA system with WAN-style key remapping. IAMCCS_BuildScheduledWanModelBank is the scheduling extension of that system: instead of patching LoRAs into the model inside a generation loop (slow, and it fights the sampler cache), it pre-builds one patched model per scheduled generation, up front, and hands the loop a ready-made bank to pick from.

How it works: you give it a base model, a generation_count, and up to 64 LoRA slots (slot_01_lora_name through slot_64_lora_name). Each slot has a strength, a preset (all generations, gen 0 only, gen 1 onwards, even/odd gens, every 2nd/3rd gen, or a custom range), and start/end bounds - end = -1 meaning "from this generation onward." At build time it runs the schedule for every generation index, applies the matching LoRAs to the base model with the pack's WAN key remapping (model_type: wan2x, flow, or standard), fingerprints each result, and stores them in a model_bank.

The outputs are where the value lands:

• model_bank (type IAMCCS_WAN_MODEL_BANK) - the collection of prebuilt, per-generation models.
• linx - the pack's connector, carrying schedule metadata so the loop can look up which model belongs to which generation.
• report - per-generation summary of which LoRAs landed where. Read it once; it's the fastest way to catch a slot that's silently set to no.

This is a memory-vs-latency tradeoff, and it's worth being honest about: pre-building every variant means holding generation_count patched models in VRAM/RAM at once. For a 4-generation run with a couple of LoRAs that's fine; for 20 generations of stacked LoRAs it's a lot of weights. The default generation_count is 4, and the README's WAN/LTX tooling explicitly targets modest GPUs, so the design expects you to keep this tight.

Why you'd reach for it: if you're running a long WAN loop where different generations need different LoRAs (phase A gets one character, phase B another), the alternative is scheduling inside the loop - recomputing patches per step, thrashing the cache, and making the graph nearly impossible to debug. This node pushes all that outside the loop so generation runs are simple lookups.

Installing: part of IAMCCS/IAMCCS-nodes. ComfyUI Manager → search "IAMCCS", or cd ComfyUI/custom_nodes && git clone https://github.com/IAMCCS/IAMCCS-nodes.git, restart. No model downloads - it uses the base MODEL you already have loaded and your existing LoRAs (the pack's LoRA stack nodes feed it). Requires the pack's general bar: modern ComfyUI, Python 3.12+, Torch 2.8+.

The trap: this node's real audience is people already using the pack's LoRA stack system. Dropped into a plain WAN workflow with stock ComfyUI-LoraLoader nodes, it won't know what to do - the slot lora_name values resolve against the pack's stack wiring. And mind the VRAM note above: a huge generation_count with heavy LoRAs will OOM before the loop even starts. Build small, verify the report, then scale.