delay module

Exactly what it sounds like: pause execution for sleep_time seconds, then pass whatever came in on any straight back out, unchanged. No transformation, just a deliberate delay wired into the middle of a graph.

The reason a node like this earns a place in an LLM/agent pack specifically: rate limits and resource contention. If your workflow is hammering an API in a loop - or, more subtly, sharing a GPU between ComfyUI and a locally-hosted model server like Ollama - firing requests back-to-back without a beat between them is a real way to trip a rate limit or step on a resource another process hasn't released yet. People running local LLMs alongside ComfyUI report exactly this kind of contention: one process holding VRAM the other needs, with no coordination between them. time_sleep gives you a cheap way to put a breath between calls without restructuring the whole workflow.

Inputs and outputs that matter

• sleep_time - how long to pause, in seconds, default 0.5.
• any - the wildcard value to hold and then pass through untouched.
• is_enable - the pack-wide skip switch; turn it off to bypass the delay entirely without unplugging the node.

The single output, any, is the same value and type you passed in.

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or clone directly:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

pip install -r requirements.txt inside your ComfyUI Python environment, then restart. time_sleep itself needs nothing beyond Python's standard library, but it comes bundled with the rest of this large pack - LLM API clients, local model loading, RAG, TTS, and a long tail of tool nodes all install alongside it. The README's only_api branch is the lighter option if you only want API-based calling.

Common issues

There's not much that goes wrong with a node this simple, but a couple of things are worth knowing. It's marked as an output node in the schema, which in ComfyUI's execution model generally means it's guaranteed to run even if nothing downstream reads its output - useful, since a "pause here" step doesn't always have an obvious consumer to force its execution otherwise.

The more practical trap is picking the wrong value for sleep_time. Too short and it doesn't actually solve whatever contention or rate-limit issue you added it for; too long, and every loop iteration now costs real wall-clock time for no benefit, which adds up fast across a long agent run or a multi-step generation pipeline. Start with the default and only lengthen it if you're actually seeing rate-limit errors or resource contention - don't add delay speculatively, it's pure dead time otherwise.