PC: Schedule LoRAs

Regular LoraLoader is all-or-nothing: a LoRA is either applied at some weight for the entire run, or it isn't in the graph. PCLazyLoraLoader - "PC: Schedule LoRAs" - is what you reach for the moment you want a LoRA to only kick in for part of the generation: bring in a style LoRA at step 10, fade a character LoRA out before the final steps, that kind of thing. The README's framing is refreshingly direct: "Just use it in place of a LoRALoader and use the output normally."

What it does

You write your LoRA expressions straight into the text field - the same place your scheduling syntax lives elsewhere in this pack - and the node reads them out, then constructs a graph of LoraLoader and CreateHookLora nodes as needed to realize the schedule. That's ComfyUI's own built-in hook system doing the actual work: instead of baking one fixed LoRA weight into the model, hooks let a LoRA's influence be conditional on which timestep range is currently sampling, without needing a separate model copy per range. Prompt Control's job is generating that hook graph automatically from your text instead of you wiring CreateHookLora nodes by hand.

Inputs and outputs

Required: text - your prompt/LoRA expression text, multiline. Optional: model and clip - your checkpoint's model and CLIP, which the node patches with the scheduled LoRA hooks. Outputs: model and clip, both carrying the LoRA schedule, ready to feed straight into your text-encode nodes and sampler exactly like a normal LoraLoader's outputs would.

Installing it

ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control

No bundled models - you still need whatever LoRA files you're scheduling downloaded into your normal loras/ folder the same as always. This node just controls when they apply, not where they come from.

Where people get tripped up

Two things that catch people, both grounded in how LoRAs behave generally, not this pack specifically. First, stacking multiple scheduled LoRAs is exactly as unpredictable as stacking regular ones - if you get a black image or NaNs after adding a second one, try reordering with the bigger LoRA first before assuming the scheduling itself is broken. Second, weight matters more than people expect: the old "0.5–0.8 is safe" rule of thumb is SDXL-era advice and doesn't generalize - some LoRAs, especially on newer architectures, are published to run at 1.0 or higher, and dropping the weight to be "safe" can just cost you likeness. Check what the LoRA's own page recommends rather than defaulting low.

On the pack side specifically: remember text here is where LoRA expressions live, not your actual image prompt - if you want both LoRA scheduling and prompt scheduling from one combined block of text, pair this with PCLazyTextEncode rather than expecting one node to do both. And if a LoRA schedule doesn't seem to be taking effect at all, wire a PCSetLogLevel node ahead of the chain and check the console - it'll show you what hooks actually got built.