Stage Barrier

ComfyUI executes nodes in dependency order, and that's usually right. But "usually" is doing a lot of work when your workflow is model-heavy. Say you're running MiniMax H3: you want all the reference/VAE preparation to finish, then all the semantic conditioning, then all the sampling - grouped into phases so the big model loads once and stays resident instead of being shuffled on and off the GPU between every branch. The stock scheduler doesn't think in phases. That's what Stage Barrier is for: a rendezvous point that forces every barrier at the same stage to complete before downstream work is released.

It's really two tools in one node. It's a pass-through: connect up to 100 arbitrary ComfyUI values (autogrow inputs value_0 through value_99) and each is forwarded to the matching output, untouched. And it's an execution-order gate: the stage widget (an integer, 0 by default) is the global ordering key, and every reachable barrier with a smaller stage must finish before any barrier at a larger stage releases its downstream work. It never bypasses a data dependency - this is scheduling, not graph-rewriting.

How it actually works

The node's execute is almost boringly simple: it forwards values and logs which stage it hit. The magic lives in the pack's runtime, which wraps ComfyUI's ready-node picker (ExecutionList.ux_friendly_pick_node) so the scheduler chooses which ready node runs next, barrier-first. Two details are worth knowing because they're the difference between "cool" and "it deadlocked":

• Same-stage rendezvous. Barriers at the same stage synchronize with each other before anything downstream is released, so you can fan a phase across several branches and guarantee they all arrive.
• Priority inheritance. If a high-stage barrier feeds a low-stage one, it temporarily inherits the lower priority. Stage order opposing data flow can't deadlock your graph - a stage-4 barrier that a stage-1 barrier depends on quietly counts as stage 1.

There's one more virtue: because stage ordering only reorders ready nodes, it never blocks the executor thread and never hides a real cycle. If you build an actual dependency loop, the pack falls back and lets ComfyUI emit its normal cycle diagnostic instead of hanging forever.

Using it

cd ComfyUI/custom_nodes
git clone https://github.com/wjie98/comfyui-svdint4

or ComfyUI Manager → search "Turing Utils", restart. Pure logic - no kernel, no models, no compile. The README's suggested H3 rhythm: stage 0 barriers after reference/VAE preparation, stage 1 after semantic conditioning, stage 2 after sampling. That maps to keeping model-heavy branches grouped by residency phase.

Two practical rules. First, keep stage as a widget, not a converted input - the tooltip is explicit that the scheduler needs to read it before executing upstream nodes. Second, if your ComfyUI build doesn't expose a compatible ExecutionList picker, the pack logs a warning and disables ordering: barriers still pass values through, you just lose the stage guarantee. Check the log if barriers ever stop mattering.

Where it fits in your head: most ComfyUI users never need this. If your workflows are small or your GPU loads models fast, it's an extra moving part for a problem you don't have. But once you're doing multi-branch H3 or Wan work where offload order decides whether a run fits in VRAM at all, a stage barrier is the difference between watching the model thrash and watching it just work. It's the least glamorous node in this pack and, for that crowd, one of the most useful.