PCPromptFromSchedule

Once your prompt has a [cat:dog:0.3] or two in it, plus maybe a BREAK, plus maybe some LoRA tags, it stops being obvious what you're actually asking the model for at any given moment. PCPromptFromSchedule answers that directly: give it a PROMPT_SCHEDULE and a point in time, and it hands back the plain-text prompt as it would resolve at exactly that point.

What it's for

This is primarily a sanity-check node. You've built a schedule, you're not sure it's doing what you think, and rather than guessing from the syntax you wrote, you ask Prompt Control to just tell you. Wire the output into a text-preview node and read it.

It's also useful for anything downstream that genuinely wants a static, non-scheduled string pulled from one moment of an otherwise-scheduled prompt - say, reusing the "final" resolved prompt (at the end of the schedule) as plain text somewhere else in your graph.

The inputs and output

• prompt_schedule (required) - from PromptToSchedule or another schedule-producing node.
• at (required, 0–1, step 0.01) - the point in the schedule to resolve. 0 is the very start, 1 is the very end. There's no default shown, so set it deliberately rather than assume.
• tags (optional, default empty) - filter the resolved text down to a specific tagged segment, the same tag mechanism FilterSchedule uses.

Output is a single STRING: the resolved prompt text at that point.

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

Don't wire this into your actual generation path. It's a debugging tool. Your real prompt should go through PCLazyTextEncode (or the primitive nodes it's built from), which resolve scheduling live, per-step, during sampling. PCPromptFromSchedule gives you a frozen snapshot at one fixed point - perfectly fine for checking your work, wrong for driving conditioning across a whole denoise.

The output doesn't look like what you expected at at=0.5. Remember at is a fraction of the whole schedule, not a step number. If you've attached real step counts via PCScheduleSettings/PCApplySettings, 0.5 means "halfway through however many steps you configured" - check that those settings are actually attached before assuming the fraction-to-step mapping is off.

You want to see segments, substitutions, or macros expanded, not just the resolved text. That's a job for its sibling node, PCExtractScheduledPrompt ("PC: Show Prompt"), which adds explicit expand toggles for exactly that and works straight off raw text instead of a pre-built schedule.