Halt Toggle
A stop button for your workflow that can reset itself
- any_input
- passthrough
- effective_stop
- reset_applied
Halt Toggle is a stop button you can drop into the middle of a workflow. Flip it on and execution halts at that node; flip it off and the run proceeds normally. It sounds trivial, but done right it's surprisingly useful for debugging and for building "pause here and look" checkpoints into long pipelines.
The clever bit is auto-reset. Halting is a state change you usually only want once - you pause, inspect, and you don't want to have to remember to unflip the toggle before the next run. With reset_after_stop on (it is by default), the node tells the frontend to reset stop_now to False after a halt, so the next run sails straight through. It's the difference between a manual pause button and a one-shot tripwire.
How it works
When stop_now is True, the node halts the workflow at its position in the graph. With zero delay it raises ComfyUI's execution interrupt (via InterruptProcessingException) and sends a UI event to reset the toggle if reset_after_stop is set. With a delay, it returns UI values telling the frontend to halt after the given milliseconds, then reset. Either way, it reports back what happened so downstream nodes can react.
Inputs and outputs
- stop_now (
BOOLEAN, defaultTrue) - whenTrue, halt here. - reset_after_stop (
BOOLEAN, defaultTrue) - auto-setstop_nowback toFalseafter a stop, so the next run isn't blocked. - delay (
INT, default0, max60000) - milliseconds to wait before halting. Zero means halt immediately. - any_input (
*, optional) - passthrough input so you can wire the node inline without breaking your data flow. - Outputs: passthrough (
*), effective_stop (BOOLEAN- whether a stop was actually applied), reset_applied (BOOLEAN- whether auto-reset fired).
It's an output node, so it appears in the execution queue - which is exactly what you want for a deliberate checkpoint.
When you'd actually use it
- Debugging checkpoints. Let a long pipeline run up to a stage, halt, inspect the intermediate, then let the next run continue past it.
- Conditional halting. Drive
stop_nowfrom an upstream boolean - halt only when some condition is met. - Guard rails. Pause before an expensive final step so you can eyeball the inputs.
Installing it
It's in sfinktah/comfy-ovum:
cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum
or search comfy-ovum in ComfyUI Manager, then restart. No models.
Gotchas
The main gotcha is the classic halting paradox: a stop_now = True node at the top of your graph halts every run until you reset it. That's why reset_after_stop defaults on - keep it on unless you genuinely want a permanent stop. Also remember a halted run is a stopped run: whatever you wanted after the halt never executes that time, by definition. And the delay cap is 60 seconds; if you need to pause longer, that's what two halts are for. Small node, very specific job, and it does it well.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| stop_now | BOOLEAN | true | When True, halt the workflow at this node. |
| reset_after_stop | BOOLEAN | true | If True and a stop occurs, automatically set stop_now to False on the next run. |
| delay | INT | 00–60000 | Delay in milliseconds before halting workflow. |
| any_inputopt | * | Optional passthrough input to keep graph wiring simple. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| passthrough | * | Passthrough of any_input |
| effective_stop | BOOLEAN | Whether stopping was actually applied |
| reset_applied | BOOLEAN | Whether auto-reset was applied |