BlehModelPatchFastTerminate

You know the feeling: you hit Cancel on a video generation and then just... wait. ComfyUI only checks for an interruption between whole sampling steps, and on a video model a single step can take 40+ seconds - so "cancel" can mean sitting there watching a step finish anyway before anything actually stops. This node fixes that specific annoyance. It patches the model to check for interruption at the start of every block inside a step, not just between steps, which makes cancelling dramatically more responsive on the models where it matters most.

That's genuinely the whole node. There's no quality tradeoff, no setting to tune, no downstream effect on your output - it changes nothing about how the model generates, only how quickly it notices you've asked it to stop.

Why it matters more for video

Image models step through fast enough that a laggy cancel is a minor irritation. Video models are a different story - Wan, Hunyuan, LTX and friends routinely spend tens of seconds per step at higher resolutions or frame counts, and that's exactly the situation this node targets. If you're iterating on prompts or settings for a Wan workflow and burning time waiting out steps you already know are wrong, this is a small quality-of-life node that pays for itself the first time you actually need to bail out of a bad generation.

Inputs and outputs

There's exactly one input and one output, and no widgets:

• model - the MODEL you want patched.
• Output: MODEL, patched, ready to feed into your sampler like normal.

That's it. Drop it between your model loader (or any earlier patch node) and your sampler, and forget about it.

Installing it

• ComfyUI Manager - search "ComfyUI-bleh", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/blepping/ComfyUI-bleh, restart ComfyUI.

No model downloads, no extra Python dependencies - this is pure Python patching logic, nothing to fetch.

Common issues

You applied it and cancel still feels slow. The pack describes this as supporting "most existing models," which leaves room for exceptions - if you're running something unusual or very new, the interruption points this node hooks into may not line up with that model's block structure. It's a best-effort patch, not a universal guarantee.

You don't notice any difference at all. That can genuinely mean it's working as intended - if your steps were already fast (small image model, modest resolution), the gap between "step boundary" and "block boundary" responsiveness is small enough you won't feel it. This node earns its keep specifically on slow, chunky steps.

Wondering if this changes your output. It doesn't, and shouldn't. If a generation with this node applied looks different from one without it, that's not this node - go looking elsewhere in the workflow.