WanVideo Setup

WAN is the workhorse of local video generation - Alibaba's open-weights family that took over r/comfyui video workflows in 2025. The annoying part of building a WAN pipeline is that its sampling parameters are scattered across half a dozen nodes. WanVideo Setup gathers the whole config into one settings box and hands it to the rest of the graph as a single pipe, so you tune one node instead of five.

What it does

The node is a bundle of WAN-specific sampling parameters that gets packed into a PIPE output:

• steps (default 4) - the sampling step count. The default is telling: WAN 2.x is a distilled flow-matching model, and like most modern video models it works with a handful of steps, not the 20–30 an SD-era sampler wants.
• cfg (default 1.0) - classifier-free guidance. Again, the default 1.0 is the modern flow-matching norm; CFG above 1 is an exotic choice for these models, not the baseline.
• model_shift (default 5) - a WAN-specific shift parameter applied to the video batch. Leave it at 5 unless you know why you're changing it; it's the kind of value people copy from working workflows and then never touch.
• steps_start / steps_stop (defaults 2 and 2) - the split-step boundaries. Some WAN workflows split the sampling run into segments (for example, a first pass and a refinement), and these index where that split happens. If you're not deliberately splitting, the defaults are what you want.

The output is a pipe - a dictionary carrying all five values. That's the Eclipse ecosystem's way of passing a bundle of settings down one wire instead of running five separate connections, and it's exactly what Pipe Out WanVideo Setup (the node that extracts the values back out) and the WanVideo context pipes expect. If you're following an Eclipse WAN template, you'll usually see WanVideo Setup feeding a context or pipe-out node.

Why the defaults matter

Here's the trap with this node: it looks like a sampler settings box, so newcomers crank cfg to 7 "because that's what I always do" and steps to 30 "for quality," then wonder why their WAN output looks overcooked or takes forever. These models were distilled around low step counts and CFG 1. The defaults in this node are not laziness - they're the correct starting point for the architecture. Change steps for speed/quality tradeoffs, leave cfg at 1, and treat model_shift like a sacred relic.

Install it

Ships in ComfyUI_Eclipse. ComfyUI Manager → search "Eclipse" → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse

Standard pack deps (opencv-python, pilgram, PyYAML, aiohttp; portable installs may need pip install -r custom_nodes/ComfyUI_Eclipse/requirements.txt). It's under Eclipse → Settings. No WAN model files are bundled - you still load the actual WAN model through your usual loader (Eclipse's diffusion loaders live in the companion ComfyUI_SmartModelLoader pack).

Gotchas

Remember this node only stores settings - it doesn't run anything, so it's meaningless without a consumer wired to its pipe output. And if you're mixing Eclipse settings nodes from different sources, keep the steps/cfg here consistent with what your sampler actually executes; a config that says 4 steps while the sampler runs 30 is a bug waiting to happen. Most Eclipse WAN workflows already wire this up correctly - follow the template the first few times instead of rewriting it.