PromptToSchedule

If you came from Automatic1111 and missed writing [cat:dog:0.5] to swap a concept mid-generation, this is the node that makes that syntax mean something in ComfyUI. PromptToSchedule takes a plain multiline string - your prompt, written with Prompt Control's scheduling syntax - and parses it into a PROMPT_SCHEDULE: an internal object the rest of the pack's nodes (FilterSchedule, PCApplySettings, PCScheduleAddMasks, PCPromptFromSchedule, ScheduleToModel, and friends) can actually operate on. ComfyUI has no native concept of "this prompt changes at step 12" - Prompt Control invents one, and this is the node that creates it.

Why this exists separately

Most people never touch this node directly. The pack's headline node, PCLazyTextEncode (shown in the UI as "PC: Schedule Prompt"), parses your text and immediately builds a graph of PCTextEncode + SetConditioningTimestepRange nodes from it in one step. That's the convenient all-in-one path, and it's what the README points you to first.

PromptToSchedule exists for when you want the parse step exposed on its own, so you can hand the resulting PROMPT_SCHEDULE to more than one downstream node - filter it for a multi-pass workflow, attach masks for regional prompting, apply schedule settings, or feed it into ScheduleToModel for LoRA scheduling. It's the primitive; the lazy nodes are the convenience wrapper built on top of it.

The mechanism, briefly

Prompt Control's v3 parser was rewritten on top of the parsy parsing library specifically to be fast - the README calls the old parser out and promises the new one has the same behavior, just quicker. That matters here because PromptToSchedule is the node that actually runs the parser. Everything from [a:b:0.3] swaps to BREAK to LoRA tags in your text gets read once here, rather than re-parsed every time something downstream needs it.

The input and output that matter

There's exactly one input and it's required: text, a multiline string - your prompt, written with whatever Prompt Control syntax you're using. The single output is PROMPT_SCHEDULE, which you wire into any of the pack's other schedule-consuming nodes.

How to install it

Two ways, same as the rest of the pack:

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

Prompt Control's v3 line requires ComfyUI v0.8.0 or newer. If you're on an old ComfyUI checkout, update it first - the README says so explicitly, and the newer parser is part of why.

Common issues & troubleshooting

Your workflow was saved before the v3 rewrite and something feels off. The README states v3.0.0 is backward compatible with existing workflows, but the parser underneath changed completely. If a schedule that used to resolve one way now resolves differently, that's worth a bug report upstream - the author explicitly asks for exactly that.

Downstream nodes recompute more than you'd expect. This isn't a PromptToSchedule bug specifically - it's a documented ComfyUI limitation the whole pack inherits. ComfyUI's caching sometimes invalidates a downstream node even when the part of your schedule feeding it genuinely hasn't changed, especially once you start filtering schedules for multi-pass work. You still get some benefit from the lazy graph generation; you just won't get perfect caching.

You're not sure why you'd use this over the lazy nodes. If you're just writing one scheduled prompt for one pass, skip this - use PCLazyTextEncode directly and let it parse-and-consume in one step. Reach for PromptToSchedule specifically when you're assembling a custom pipeline out of the primitive nodes instead of the all-in-one ones.