PC: Schedule LoRAs Plus

LoRA scheduling means varying a LoRA's strength across the sampling steps instead of applying one flat weight the whole way. It's the standard fix when two style LoRAs fight each other, and this node is a two-textbox wrapper around the Prompt Control node that does it.

Why you'd schedule at all

Anima is unusually friendly to stacking - it handles up to three LoRAs at once without collapsing the way some small bases do - but the community advice comes with the obvious condition: only if you don't max every weight. Two style LoRAs at 0.8 each means both are shouting for all 40 steps, and you get a muddle with the worst traits of each.

Scheduling is the way out of that. Run LoRA A for the first third, hand over to LoRA B, taper them. On Anima there's a practical bonus: it wants 30–50 steps, and the distilled or DMD2-style LoRAs on top of it want 8–12, so a schedule that fades a speed LoRA out and a style LoRA in has real room to work with. Prompt Control is the niche local pack that implements it - literally niche, in corpus terms, with a handful of threads mentioning it per month rather than hundreds. That's not a warning about quality; it's a warning that you'll be reading its README more than its Reddit threads.

What this node adds

Prompt Control's own PC: Schedule LoRAs node takes text through a single textbox and returns a scheduled model and clip. This wrapper gives you two multiline boxes instead, joins the non-empty ones with a newline, and passes the result through unchanged. Whitespace-only boxes are dropped, so an empty text_2 doesn't leave a blank line in the middle of your schedule.

It also hands back the text - which is where the "Plus" earns its keep. The outputs are model and clip (scheduled), loras_text (the contents of the upper text_1 box verbatim), and text (the combined string). Splitting the schedule lines from the prose is the whole reason there are two boxes: put your <lora:...> lines and their step ranges in text_1, your actual prompt prose in text_2, and then use loras_text for the schedule side and text wherever the same text needs to drive conditioning too.

Inputs and outputs

All four inputs are optional sockets: model, clip, text_1, text_2. Connect the loader's model and clip, write your schedule in the text boxes.

Outputs, in order:

• model - "Model with the LoRA schedule applied."
• clip - "CLIP with the LoRA schedule applied."
• loras_text - "Contents of the upper text_1 box."
• text - "Combined text_1 and text_2 passed to Prompt Control."

Wire the scheduled model and clip into the sampler - either into its optional model/clip override inputs (which is where the EasyKSampler wrapper's model write-back fix matters, since the override is what actually gets stored in the output pipe) or wherever your graph applies model patches. For the LoRA syntax itself, use Prompt Control's own documentation: the plain inline form is <lora:name:weight>, e.g. <lora:style_b:0.8>, and the time-sliced form is Prompt Control's business, not this node's - everything you type is forwarded untouched.

Install

You need both packs:

cd ComfyUI/custom_nodes
git clone https://github.com/nobinBB/comfyui-easy-use-anima
git clone https://github.com/asagi4/comfyui-prompt-control
pip install piexif

Or ComfyUI Manager → comfyui-easy-use-anima, then Prompt Control. Restart ComfyUI.

When it breaks

Prompt Control is a hard requirement for this node only. The wrapper resolves it lazily at execution time, so the rest of easy-use-anima loads and runs fine without it - you get a clear error when you queue the graph, naming what's missing, rather than a pack that fails to import. That's the right design, and it's also why you should expect the failure at Queue rather than at startup.

The lookup is by node name: the wrapper goes looking for Prompt Control's PCLazyLoraLoader class in ComfyUI's node mappings. If a Prompt Control update ever renames that class, this node breaks with the same "requires comfyui-prompt-control" message even though the pack is right there. The fix is to update Prompt Control and easy-use-anima together.

One more: Prompt Control's scheduling patches the model as it goes, so a schedule plus a second sampler pass needs the scheduled model in both passes - take the model output and feed it forward, don't let the second sampler fall back to the loader's unscheduled model via the pipe.