Add Delay

ComfyUI executes a queue the moment you hit that run button, and normally that's the whole point. But every so often you want it to not do the next thing for a few seconds - and that's the entire existence of Add Delay from a-und-b/ComfyUI_Delay. It's one node, two inputs, no dependencies, no model downloads. You drop it in a wire, it sits there and waits, then passes its input through completely untouched. That's not a bug, it's the product description.

It sounds useless until you hit the situation where it's exactly right. The clearest real-world case, straight from an r/comfyui thread about a RTX 4090 crashing on long Wan batches: someone wanted 30–60 seconds of cooldown between queue jobs so the card could shed heat, and the answer that worked for another user was literally this node placed before "Save Image". Other people use it when ComfyUI runs as a backend and the thing it calls downstream has a rate limit - a delay node is the poor man's throttle. And honestly, if you're debugging a workflow that runs so fast you can't watch it, sticking one in front of the step you care about makes the whole thing readable. It's a utility node in the purest sense: it adds no capability, it buys you control.

How it works

The whole implementation is one short file. When execution reaches the node, it prints [Delay Node] Starting delay of 1.0 second to the console, then loops: it updates ComfyUI's progress bar, sleeps for a second, repeats until the elapsed time is up, and prints the completion line. The key detail is that it sleeps in one-second slices rather than one giant block - that's what keeps the UI's progress bar moving and, per the README, what lets ComfyUI's Stop button cancel a delay in progress (progress bar and cancellation support came in via a contributor's pull request, not the original code).

Two things follow from that mechanism. First, the node does not unload models or touch VRAM - it just pauses execution where it sits. Second, while it's delaying, the whole queue is parked. That's usually fine, but it means this is a "make the pipeline itself slower" tool, not a "clean up memory between runs" tool.

The inputs that matter

• input (*, any type) - the pass-through. Wire anything into it: an image, a latent, a conditioning, a string. Whatever goes in comes back out unchanged.
• delay_seconds (FLOAT, default 1.0, min 0.0, step 0.1) - how long to wait. This is the one you'll actually touch; set it to 0 and the node is a no-op passthrough. The 0.1 step means sub-second delays are fine.

There's one output, output (*), which carries whatever you fed in and plugs into whatever you had wired downstream - you can insert Add Delay into an existing wire without rethinking the graph. It lives under utils in the node menu.

Installing it

No Python dependencies, no models, one .py file. If you have ComfyUI Manager, search for ComfyUI_Delay and hit Install, then restart. Otherwise:

cd ComfyUI/custom_nodes
git clone https://github.com/a-und-b/ComfyUI_Delay.git

Then restart ComfyUI. That's the entire install.

Where people get burned

The one honest gotcha is the thermal idea in reverse: several people in that 4090 thread argued that hot-cold-hot-cold cycling is worse for a card than sustained load, and that random restarts under long load are usually a cooling or power problem a delay won't fix. If your GPU is actually crashing, debug the temps first - don't just paper over it with a sleep. And remember the node holds the queue hostage while it waits and leaves models resident, so if your actual problem is VRAM, you want model unloading between jobs, not a pause.

One more take: if you're driving ComfyUI purely from a script, time.sleep() in your client code is usually cleaner than a delay node in the graph - the node shines when the pacing has to live inside a workflow you're sharing or running from the UI. It's a dumb little thing, but it's the right dumb little thing for that one niche.