SA-ODE Stable Sampler

The "stable" in the name is the whole product. Where the pack's SAODELowStepSampler is plain Euler with a final-step trick, SAODEStableSampler is the safety-conscious sibling: a higher-order multistep sampler that keeps a rolling window of past velocities and layers on damping and smoothing so low-step output doesn't oscillate or blow up. It's the fiddly member of the family - five knobs instead of one toggle - and to be blunt, most people should start with the LowStep sampler and only come here when that one isn't enough. You reach for Stable when results at 3-6 steps are jittery or unstable, or when you're pushing really aggressive step counts and need a solver that stays calm.

How it works

Grounded in the source, it's a workhorse of small stabilizers stacked together. At each step it extrapolates from the buffered velocities using Adams-Bashforth-style coefficients - third order gives 23/12·v[-1] − 16/12·v[-2] + 5/12·v[-3] - and then applies up to three corrective layers:

• Adaptive order (on by default): drops to order 2 when sigma is high (above 0.7) or when there are 8 or fewer steps, and to solver_order − 1 near convergence. High-order extrapolation is exactly where low-step solvers overreach, so this keeps the early, aggressive part of the trajectory honest.
• Velocity smoothing: an exponential moving average applied only in the low-sigma band, meant to kill flicker. It only engages when you have more than 8 steps, which is why it's off by default.
• Damping + stabilization: below the convergence threshold, step sizes get damped toward 0.5×, and below sigma 0.05 the step blends toward the three-step average velocity. This is the "don't blow up at the end" machinery.

That's a lot of interacting heuristics, and it's the reason this node is harder to tune than the LowStep one. Start at the defaults and change one thing at a time on a fixed seed.

The inputs that matter

Five inputs, and the three that actually change your results:

• solver_order (INT, 1-5, default 3) - extrapolation order. 3 is the sweet spot; 4-5 get aggressive fast at low steps.
• use_adaptive_order (BOOLEAN, default true) - leave it on. It's what stops high-sigma steps from overreaching.
• use_velocity_smoothing (BOOLEAN, default false) - flip it on only if you see temporal flicker on video, and only with more than 8 steps; below that it does nothing by design.
• convergence_threshold (FLOAT, 0.01-0.5, default 0.15) - where damping and smoothing kick in. Lower = later and less intervention.
• smoothing_factor (FLOAT, 0-1, default 0.7) - strength of that smoothing. If output looks over-smoothed or watery, lower it or leave smoothing off entirely.

Output is SAMPLER, wired into CustomSampler/SamplerCustom's sampler input, with sigmas from this pack's LowStepSigmaScheduler or any schedule you like. The pack also registers sa_ode_stable in the stock KSampler dropdown.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/WangDianhui/ComfyUI-SA-ODE_Sampler

Restart after, or search "SA-ODE" in ComfyUI Manager. No extra dependencies, no model downloads - the whole pack is two small Python files. This is a genuinely lightweight install.

Where people get burned

The one real community thread about this pack (r/StableDiffusion, October 2025) is a Wan 2.2 user who felt that after running the stable sampler once and switching back to unipc, the motion of their old seeds had "permanently" changed. It went unanswered. Reading the code, there's a clean explanation: the sampler keeps no state between runs - the velocity buffer is local to each call, so a cached effect is impossible. What you're seeing is that the stable sampler produces genuinely different dynamics from unipc at the same seed, and once you've seen that version, the old one reads as "changed." Compare on a fixed seed and remember the sampler changing the look is the feature, not a leak.

Beyond that, the usual warnings apply: this pack has one star and hasn't been touched since October 2025, it monkey-patches ComfyUI internals to register its sampler names, and it's a flow-matching solver - don't expect its low-step behavior to transfer to DDPM-style checkpoints. And when output looks over-stabilized, your first move is use_velocity_smoothing off, not more knobs.