Progressive 50/50 Sigma Control

This node has no widgets. No inputs, no settings, one output, and it's still one of the cleverer pieces in the Sampling Planner pack - because it solves a specific, annoying problem in progressive transcode and upscale workflows.

The problem it's solving

Say you're doing the low-res → high-res thing: render a draft at low resolution, then re-sample the upscaled frames. You're running Wan 2.2 with Low-only acceleration - full-quality high-noise pass for motion, accelerated low-noise pass for detail - because that's the community's standard compromise (speed LoRA on the detail pass, base model on composition).

But here's the wrinkle: a progressive upscale wants the sigma curve to use the accelerated budget split 50/50, while the model and CFG routing should stay Low-only. Those are two different decisions, and until this node existed they were welded together - you either got the routing you wanted with the wrong curve, or the right curve with the wrong routing.

What it does

It emits a SAMPLING_SIGMA_BUDGET_OVERRIDE that you connect to Sampling Plan (Wan 2.2)'s optional sigma_override input. When the plan sees it, Low-only acceleration uses the accelerated step budget split 50/50 for the sigma curve - while model routing stays base high → accelerated low, and CFG routing stays base/accelerated as configured.

The concrete effect, from the README, with accelerated/full budgets A10/F30:

| Plan | High steps | Low steps | Model routing | |---|---|---|---| | Low only + 50/50 priority | 15 | 5 | base high → accelerated low | | + Progressive 50/50 Sigma Control | 5 | 5 | base high → accelerated low |

That extra row is the whole reason this node exists: same routing, but the curve now spends the accelerated budget on both halves, which is what the progressive pass actually wants.

The "side-channel" bit is the trick

The override is deliberately not part of the required plan chain - it's an optional side input. That means you can put this node inside the low-res → high-res group, mute the group, and the override silently disappears without severing your WAN22_SAMPLING_PLAN wire. The plan just falls back to normal Low-only accounting. If this were an in-chain node, muting the group would break the whole sampling path. That design choice is why the README shows it feeding the plan's sigma_override input, before any downstream Step Split or Shift overrides:

Progressive 50/50 Sigma Control ─┐
                                  ├→ Sampling Plan → Step Split Override → Sigma Breakout
normal planner controls ──────────┘

Two honest limitations. First, the plan intentionally rejects this override for any acceleration mode other than Low only - it's a Low-only feature. Second, it only manages the sigma curve; decode/upscale/re-encode routing and noise routing stay in your workflow where the progressive technique actually lives.

Install

Standard pack install - ComfyUI Manager (search Sampling Planner) or:

cd ComfyUI/custom_nodes
git clone https://github.com/boobkake22/ComfyUI-SamplingPlanner

then restart. It's under sampling / Sampling Planner / Wan 2.2. No dependencies, no models.

If you've ever fought a progressive Wan 2.2 workflow where the sigma curve and the routing refused to cooperate, this is the fix you didn't know you needed - and the fact that you can mute it with its group without breaking the graph is the part most node authors wouldn't have thought of.