Stasis
Stasis puts the ComfyUI branches you never use on ice — until you actually want them
- lane_1
- lane_2
- lane_3
- lane_4
- lane_5
- lane_6
- lane_7
- lane_8
- lane_9
- lane_10
- lane_11
- lane_12
- lane_13
- lane_14
- lane_15
- lane_16
- lane_1
- lane_2
- lane_3
- lane_4
- lane_5
- lane_6
- lane_7
- lane_8
- lane_9
- lane_10
- lane_11
- lane_12
- lane_13
- lane_14
- lane_15
- lane_16
Here's the ComfyUI fact that gets people: if a node sits between an output node and its inputs, ComfyUI runs it. On a fresh queue, that means every wired branch executes - the second model you loaded "just in case," the img2img reference chain you aren't using this week, the refiner you switched away from. Each one loads into VRAM, and a downstream switch quietly throws the result away. Bypass stops it, but bypass is manual - you have to remember what's what and flip it every time.
Stasis is a flow-control node that makes "this branch stays dormant until I ask for it" a property of the workflow instead of your memory. Drop it in a branch you want kept cold, leave it enabled, and a normal Queue Prompt blocks that branch cold. Run that branch's own output with Execute Selected Output Nodes, and Stasis wakes up, passes everything through, and lets it run for exactly that prompt. When Stasis is enabled its title literally reads ❄ Stasis - it's on ice - so you can see at a glance which branches are frozen.
How the freeze actually works
Two mechanisms do the work, both from ComfyUI core rather than anything the pack invented.
First, when Stasis is enabled its inputs are lazy. During a normal queue it tells ComfyUI it doesn't need any of its connected lanes, so the upstream branch is never evaluated at all. That's the real saving: the dormant model loader doesn't load, the dormant preprocessors don't run. It's not "run then discard," it's "never run."
Second, it returns an ExecutionBlocker on every output. ComfyUI's core docs are blunt about that value - return it from a node and any downstream users are blocked. So whatever the frozen branch feeds (typically its own Save Image / Preview node) gets skipped silently on a normal queue, no error popup, no output.
The wake-up is the clever part. A small frontend extension adds a hidden partial_execute flag to the node, set by ComfyUI's beforeQueued hook every time you queue. When you run Execute Selected Output Nodes on the frozen branch's output, ComfyUI treats it as a partial execution - only the chain feeding that output runs - and Stasis sees partial_execute flip true for that prompt. Once open, it requests its lanes, the branch executes, and the flag resets to put it back to sleep. Flip the Disabled toggle instead and it becomes a plain pass-through that always runs - handy while you're actively iterating on that branch.
The inputs and outputs that matter
The schema is small - the two inputs a beginner ever touches or sees:
disabled- the visible toggle. Off (default) = Stasis active. On = pass-through; the title changes to "Stasis (Disabled)".partial_execute- hidden, set automatically by the frontend for partial runs. Don't touch it; knowing it exists prevents confusion if you ever peek at the node's API.
Then the lanes: lane_1 through lane_16, all wildcard * sockets. Lanes accept any type - model, latent, image, conditioning, mask, anything. A fresh node shows one lane; connecting it makes the extension add a spare, up to 16, labeled by what's plugged in (model, image, …) with stable backend keys. Wire the frozen branch into an input lane and its consumer out of the matching output lane, and you're done.
Installing it
Three ways, all equivalent:
# ComfyUI Manager: search "Stasis" and install
comfy node install stasis # or the Comfy CLI
cd ComfyUI/custom_nodes
git clone https://github.com/DHan315/ComfyUI-Stasis.git
Restart ComfyUI and hard-refresh the browser afterward. No model files, no Python dependencies, no accelerator-specific anything - one pure-Python node plus a small JS file, MIT-licensed. The only requirement is a current ComfyUI with lazy-input and ExecutionBlocker support, which any recent install has. It's a young pack (0.6.0 landed August 2026), so treat early quirks charitably.
Where people get burned
The big one is topology, and it follows directly from how blocking works. ExecutionBlocker is contagious: if any input to a node is blocked, that node is skipped too. So do not feed a frozen Stasis branch into the same switch or sampler that your live branch feeds - a normal queue will block that shared consumer and you'll get nothing at all. Stasis is for branches that end in their own output node, where "blocked" means "that output just doesn't fire." If you want to A/B between two branches feeding one output, use a real switch (and expect both to load on a fresh queue) or group bypass. Stasis is a different tool for a different problem.
Otherwise: if a branch keeps stale sockets after an update, remove the node and re-add it, then hard-refresh - the author's own documented fix for the extension holding onto old lane state. And if you swear Stasis "isn't blocking anything," check you didn't leave Disabled flipped on.
Stasis won't make your GPU faster; it stops your workflow from paying for branches you aren't using. If your shared templates quietly load three models a run, that's the whole pitch.
Inputs (18)
| Name | Type | Default | Description |
|---|---|---|---|
| disabled | BOOLEAN | false | — |
| partial_execute | BOOLEAN | false | — |
| lane_1opt | * | — | |
| lane_2opt | * | — | |
| lane_3opt | * | — | |
| lane_4opt | * | — | |
| lane_5opt | * | — | |
| lane_6opt | * | — | |
| lane_7opt | * | — | |
| lane_8opt | * | — | |
| lane_9opt | * | — | |
| lane_10opt | * | — | |
| lane_11opt | * | — | |
| lane_12opt | * | — | |
| lane_13opt | * | — | |
| lane_14opt | * | — | |
| lane_15opt | * | — | |
| lane_16opt | * | — |
Outputs (16)
| Name | Type | Description |
|---|---|---|
| lane_1 | * | — |
| lane_2 | * | — |
| lane_3 | * | — |
| lane_4 | * | — |
| lane_5 | * | — |
| lane_6 | * | — |
| lane_7 | * | — |
| lane_8 | * | — |
| lane_9 | * | — |
| lane_10 | * | — |
| lane_11 | * | — |
| lane_12 | * | — |
| lane_13 | * | — |
| lane_14 | * | — |
| lane_15 | * | — |
| lane_16 | * | — |