LoRAScheduler

The category tells you what you need to know before anything else: promptcontrol/old. LoRAScheduler is a leftover from before Prompt Control's v3 rewrite moved LoRA scheduling onto ComfyUI's native hook system. It's kept around, not documented, and not the node the README points you to - that's PCLazyLoraLoader ("PC: Schedule LoRas"), or ScheduleToModel if you're already working with a PROMPT_SCHEDULE.

What it does

Compared to the current approach, it's strikingly plain: a MODEL and a text field with your LoRA scheduling syntax in, a patched MODEL out. No separate schedule object, no settings step, no hooks exposed for reuse elsewhere. It parses your text and patches the model in one opaque step, which is exactly the kind of all-in-one design the pack moved away from when it split parsing (PromptToSchedule), settings, filtering, and model-patching into composable pieces.

Why it's still here

The README states v3.0.0 is backward compatible with existing workflows. That's almost certainly the whole reason this node hasn't been deleted - old saved workflows that reference LoRAScheduler by class name need it to still exist, or they'd break on load. That's a courtesy to people with existing graphs, not a recommendation to build new ones with it.

The inputs and output

• model (required) - the MODEL to patch.
• text (required, multiline) - your prompt text containing LoRA scheduling syntax.

Output: a patched MODEL.

How to install it

You get this node automatically with the pack; there's no separate install path for it.

• ComfyUI Manager - search "ComfyUI Prompt Control", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/asagi4/comfyui-prompt-control, restart ComfyUI.

Requires ComfyUI v0.8.0+, same as everything else in the v3 line - including this legacy node.

Common issues & troubleshooting

You're starting a new workflow and found this node in search. Don't use it. Use PCLazyLoraLoader instead - same job, current mechanism, and it composes with the rest of the pack (filtering, settings, masks) in ways this node simply doesn't expose. This node exists for the sake of workflows that already reference it, not as an option to pick fresh.

You inherited a workflow that has this node in it, and it still works. That's fine - leave it. The README's backward-compatibility promise means you don't need to rip it out urgently. Just don't build your next workflow around it, and don't mix it with the newer hook-based scheduling (ScheduleToModel, PCLoraHooksFromText) on the same model - pick one LoRA-scheduling mechanism per model and stick to it, since they don't necessarily know about each other's patches.

It behaves differently from the new LoRA scheduling. That's expected, not a bug to chase - it predates the hook-based rewrite entirely, so don't assume its syntax quirks or edge-case behavior carry over to PCLazyLoraLoader. Treat any behavioral question about the current system as a question about the new node, not this one.