Dynamic Delay Text (Creepybits)

The pack's plain Delay Text node asks a dumb question: "wait exactly N seconds, then pass the text." Dynamic Delay Text asks the smarter one: "wait until the text has stopped changing for N seconds, then emit the last version." That's a debouncer - the same trick your keyboard uses so you don't fire ten searches while you're still typing. It resets its timer every time new text arrives, and only when things have been quiet does the final, settled value come out.

The inputs

• seconds (float, default 1.0, min 0.1) - the quiet period that must elapse with no new input before release
• text - the incoming string, checked on every run

Output is text. The author's framing is the clearest way to hold the two delay nodes apart: use Delay Text when you want "wait 5 seconds, then do the next thing," and use Dynamic Delay Text when you want "wait until things have been quiet for 5 seconds, then use the last thing I gave you."

Why you'd reach for it

The intended use case is exactly the "you're still typing" scenario. If a text box feeds a downstream node - an LLM call, a prompt encoder, an API request - every keystroke would normally trigger work. Run that stream through this node first and only the final, settled string triggers anything. It's also useful when a previous step produces a rapid series of intermediate values (an incremental captioner, a per-frame labeler) and you only care about the last one.

The honest, code-level caveat

I read the source, and there's a quirk you should know about before you trust this node in an automated pipeline. The debounce state lives on the node instance, and the release happens on a background thread (threading.Timer). ComfyUI's executor captures the return value of the node's main function - and that function returns an empty string every time. The actual settled text is produced inside the timer callback, whose return value ComfyUI never sees. What that means in practice: downstream nodes tend to receive "" on each pass, and the "settled" text may never travel down the wire the way the docs suggest.

If you're building on this, the reliable pattern is repeated runs where the node's widget value is the source of truth and you read the result from the next execution, or you simply don't rely on the debounced value being delivered mid-run - trigger it, check it, then consume it. The pack's Collect and Distribute Text node has the same threading architecture but offers a manual trigger path that returns synchronously, which makes it the more dependable choice when you control the trigger. For a fire-and-forget "settle after typing," this node is fine as long as you don't expect the first run to carry the answer.

Installing it

It ships with the whole Creepybits pack:

cd ComfyUI/custom_nodes
git clone https://github.com/Creepybits/ComfyUI-Creepy_nodes.git

Restart ComfyUI, or find "Creepy" in ComfyUI Manager. No model downloads, nothing extra to configure. The idea is genuinely useful - just keep the threading caveat in mind, and test how the value actually lands in your graph before you build a queue around it.