Nodes/comfy-ovum/Halt Toggle
ComfyUI Node

Halt Toggle

A stop button for your workflow that can reset itself

By sfinktah·Created about a year ago·Updated 10 months ago· 7
Halt Toggle
  • any_input
  • passthrough
  • effective_stop
  • reset_applied
stop_nowtrue
reset_after_stoptrue
delay0

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, default True) - when True, halt here.
  • reset_after_stop (BOOLEAN, default True) - auto-set stop_now back to False after a stop, so the next run isn't blocked.
  • delay (INT, default 0, max 60000) - 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_now from 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.

Categoryovum/control

Inputs (4)

NameTypeDefaultDescription
stop_nowBOOLEANtrueWhen True, halt the workflow at this node.
reset_after_stopBOOLEANtrueIf True and a stop occurs, automatically set stop_now to False on the next run.
delayINT00–60000Delay in milliseconds before halting workflow.
any_inputopt*Optional passthrough input to keep graph wiring simple.

Outputs (3)

NameTypeDescription
passthrough*Passthrough of any_input
effective_stopBOOLEANWhether stopping was actually applied
reset_appliedBOOLEANWhether auto-reset was applied