⏳ Execution Delay

"⏳ Execution Delay" is a sleep() you can drag into a graph. Whatever data you feed it - a string, a latent, an image, a model, anything - it holds for seconds_to_wait, then passes the exact same data out the other side. It exists for the one genuinely common case: rate-limiting. If one of your nodes calls an external API with a per-minute cap (an LLM endpoint, an image host, a cloud sampler), you stick this before it, set it to the gap you need, and stop hitting the cap.

How it works

The mechanism is brutally simple: time.sleep(seconds). Nothing async, nothing clever - the node freezes the execution thread for that many seconds, prints a "Sleeping for N seconds..." line to the terminal if you've left print_to_console enabled, then returns your data untouched. The input and output are both typed * - ComfyUI's any-type - which is exactly what lets it sit between a KSampler and a VAE decode, or in the middle of a prompt chain, without caring what it's carrying.

And because it's a hard thread sleep, it blocks everything - the whole ComfyUI worker pauses. A 30-second delay in a chain of ten images adds five minutes to the run, and during that time nothing else in your queue is executing. This is a throttle, not a polite pause.

The inputs that matter

• any_input - accepts any type, passes it through unchanged.
• seconds_to_wait - the delay, 0 to 3600, default 5. Keep it small; remember it's a full worker block.
• print_to_console - enable/disable, default enable, logs the sleep start and resume to the terminal.

Output: output_data (*) - the same thing you put in, after the wait.

Installing it

Identical to the rest of the pack - no requirements.txt, no models, pure Python stdlib. The README is a "TODO." stub; the code is 40 lines.

ComfyUI Manager → Custom Nodes Manager → search "TextRandomizer" → Install → Restart

or cd ComfyUI/custom_nodes && git clone https://github.com/fls-eugene/ComfyUI_TextRandomizer, then restart.

The honest take

This is a blunt instrument and it knows it. For API rate limiting it's the right tool - you know the cap, you compute the gap, you sleep. Where people trip up is expecting it to be something it isn't: it won't wait for a file to appear on disk (that's polling, not sleeping), it won't pause just one branch (it freezes the whole worker), and it won't help you with a flaky service that needs retries. For those you want a real waiting node. But if your problem is literally "slow down the requests," this is the simplest way to do exactly that, and the any-type pass-through means you can wire it into almost any pipeline without reshaping anything.