PCApplySettings

This is glue, and it's supposed to be boring. PCApplySettings takes a PROMPT_SCHEDULE and a SCHEDULE_SETTINGS object - the bundle PCScheduleSettings builds - and returns a schedule with those settings baked in. Two required inputs, one output, no options to fuss over.

Why it's a separate node at all

Prompt Control splits "build the settings" and "apply the settings" into two nodes on purpose. It means you can build one SCHEDULE_SETTINGS object - your real step count, your SDXL micro-conditioning numbers, your mask resolution - once, and reuse it across several different prompt schedules in the same workflow without re-entering the same numbers into multiple settings nodes. Change the settings node once, and every schedule downstream of a PCApplySettings that references it picks up the change.

It also means settings live outside your prompt-parsing step. PromptToSchedule only cares about your text; PCApplySettings is where the numeric context that text gets interpreted against gets attached, as its own graph step.

The inputs and output

Both required, nothing optional:

• prompt_schedule - a PROMPT_SCHEDULE, typically straight from PromptToSchedule.
• settings - a SCHEDULE_SETTINGS, from PCScheduleSettings.

Output is a PROMPT_SCHEDULE - the same schedule, now carrying the settings, ready for the rest of the pipeline (FilterSchedule, PCScheduleAddMasks, ScheduleToModel, or a lazy text-encode step).

How to install 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+.

Common issues & troubleshooting

Order matters - put this early. Wire PCApplySettings in right after PromptToSchedule and before anything that reads step-count-derived numbers (like at fractions resolving against your real step count elsewhere in the pack). If something downstream reads the schedule before settings are applied, it's working off Prompt Control's defaults instead of yours, and the mismatch is easy to miss because nothing errors - it just quietly uses the wrong step count or SDXL numbers.

You skipped this node and things still work. That's expected, not a sign you're missing a step. If you never needed to override steps, mask resolution, or SDXL conditioning, Prompt Control's defaults carry you through fine without either node. Reach for the PCScheduleSettings → PCApplySettings pair only when a default genuinely doesn't match your setup.

Nothing changed after you edited the settings node. Make sure the schedule you're actually looking at downstream really is the one that passed through this PCApplySettings - it's easy, in a busy graph, to have a second unrelated schedule branch that never got the settings applied at all.