PC: Schedule prompt
Schedule Prompt — A1111-style prompt scheduling in ComfyUI, without the noodle soup
- clip
- conditioning
If you've ever asked "how do I do prompt editing in ComfyUI, like [cat:dog:0.5] in A1111" - this node is the answer people give. Search the corpus and it's the same link over and over: "ComfyUI does not have prompt editing by default, you need a custom node to enable it." That custom node is Prompt Control, and PCLazyTextEncode - display name "PC: Schedule Prompt" - is the one you actually wire up.
What it does
You type a prompt with scheduling syntax baked into the text - the classic [cat:dog:0.5] style, switching from one concept to another partway through the generation - and this single node turns it into a whole subgraph behind the scenes: a chain of PCTextEncode calls plus SetConditioningTimestepRange nodes, one per segment of your schedule. That's the "noodle soup" the README talks about - the graph you'd have to hand-build node by node to get the same effect natively in ComfyUI. This node builds it for you, on the fly, from a text box.
The clever part is caching. ComfyUI's lazy graph execution means unchanged parts of the schedule don't get re-encoded. Change [cat:dog:0.1] to [cat:dog:0.5] and only the timing changes - the actual text encodes for "cat" and "dog" are untouched, so ComfyUI's cache reuses them instead of re-running CLIP. On a slow CLIP or a long multi-segment schedule that adds up.
There's one more trick worth knowing: drop NODE(NodeClassName, textinputname) into your prompt and PC will generate the graph using any other compatible node instead of its own PCTextEncode - as long as that node takes a single clip input and a text field and returns CONDITIONING first. Don't want PCTextEncode's extra syntax? NODE(CLIPTextEncode) gets you scheduling with vanilla ComfyUI text encoding underneath.
Inputs and outputs
Just two required inputs: clip (your loaded CLIP model) and text - a multiline string where you write your schedule. One output, conditioning, which wires straight into your sampler's positive or negative slot like any CLIPTextEncode output would.
Installing it
ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control
No models to download, no heavy Python deps - it's pure graph generation on top of nodes ComfyUI already ships. One version note that matters: v3.0.0 rewrote the prompt parser (moved to parsy, much faster) and requires ComfyUI v0.8.0 or newer. If you're on an older ComfyUI and things behave oddly or error on load, update ComfyUI first - that's the pack author's own advice.
Where people get tripped up
The pack's own known-issues list flags a real one: ComfyUI's caching mechanism sometimes invalidates cache for inputs that shouldn't affect anything downstream - especially once you're using the tag-filtering features on the Advanced variant of this node. You still get some benefit from the lazy graph, just not the full benefit; that's ComfyUI's cache logic being overly conservative, not a bug in this pack specifically.
Don't confuse this with plain PCTextEncode. That node does not do scheduling and, worse for a beginner, it does not strip out <lora:name:weight> tags - it just treats them as literal text. If your prompt mixes scheduling and LoRA tags, PCLazyTextEncode is the one to reach for, paired with PCLazyLoraLoader for the LoRA side.
One more grounding point, useful for calibrating expectations: the weighting and combinator syntax this whole pack builds on ((word:1.3), BREAK, AND) is CLIP-era technology. It does real work on SD1.5, SDXL, and Flux's CLIP-L slot. On a fully LLM-encoded model - Z-Image, Anima, Flux 2 Klein - that weight syntax gets silently discarded by the encoder wrapper, so scheduling breakpoints still work but (word:1.3)-style weighting inside your prompt segments won't do anything. This pack's sweet spot is CLIP-conditioned models.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| clip | CLIP | — | |
| text | STRING | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| conditioning | CONDITIONING | — |