Dynamic Prompt Scheduler (CRT)

A normal KSampler encodes one prompt and renders one image. That's fine until you're running a variation pass - fifty prompts, one seed each - and you realize you're paying the text encoder cost fifty times and babysitting fifty runs. Dynamic Prompt Scheduler (CRT) is the node that collapses the prompt side of that loop: give it a CLIP and a dynamic set of prompts, and it hands back a single conditioning output that encodes the whole batch in one go.

This is the conditioning twin of the pack's batch-sampler story. The author's whole pitch for CRT-Nodes is batch rendering - encode all your conditioning before inference, then sample everything in one pass, which avoids the ping-pong of loading and unloading the text encoder and gets you more than 2x throughput. This node is the "encode all your conditioning" half.

How it works

The node takes a clip plus dynamic inputs named prompt_1, prompt_2, … prompt_N, and optional image_1, image_2, … paired with each. A small JavaScript widget on the node sets the count (and whether the image inputs exist), so the input list grows and shrinks as you change it. On run it:

• tokenizes and encodes each prompt through the CLIP,
• pads every encoding to the longest sequence length in the batch and concatenates them into one conditioning tensor,
• guarantees a pooled_output for every entry (creating zeros if the CLIP didn't supply one - important for models that need pooled conditioning),
• bundles the per-prompt images into a matching image_batch.

Three outputs come out: conditioning, batch_count, and image_batch. Wire conditioning into a batch sampler, feed batch_count to the sampler's batch-size side, and if you're doing image-to-image or reference-latent work per prompt, the image_batch lines up index-for-index with the conditioning.

The inputs that matter

• clip - your model's text encoder. This is the one required input, and it's the only static one.
• prompt_1…N / image_1…N - the dynamic slots. Each prompt is encoded independently; images are optional and matched by index.
• The widget batch_count controls how many slots exist. Note the widget isn't an input in the traditional sense - it reshapes the node's inputs on the canvas.

Where it fits

The pattern to copy: a String Batcher (or a text crawl loader) produces newline-joined prompts → Dynamic Prompt Scheduler encodes them into one conditioning batch → CRT's KSampler Batch samples every entry in a single pass. You get N variations with one model load, one conditioning pass, and seeds you can sweep. If you only ever generate one image at a time, this node is pointless - it only pays off once you're running batches.

Install and troubleshooting

Standard pack install - ComfyUI Manager search "CRT-Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/PGCRT/CRT-Nodes.git
pip install -r requirements.txt

The one failure mode worth knowing is baked into the code: if your CLIP has missing or meta-tensor weights (the classic "clip missing" log line), encoding dies with a specific error telling you to reconnect a valid CLIP/text encoder. The node actively loads the CLIP onto the GPU before encoding to avoid meta-tensor copy errors, so if you see that error, it's your checkpoint setup, not this node. Beyond that, it's a deterministic encoder - if the output conditioning looks wrong, check the prompt count matches what your sampler expects, because the conditioning batch length is your batch size.