Sigmas AdaptiveStep
Spend more steps where the schedule is changing fastest
- sigmas
- SIGMAS
Every scheduler you've used already does a version of this: the Karras schedule concentrates denoising effort in the middle steps rather than spreading it evenly, because that's where it pays off most on a curved (SD 1.5/SDXL-style) trajectory. Sigmas AdaptiveStep takes that same idea - don't space steps uniformly, put more of them where they matter - and turns it into a general tool you can apply to any input schedule, with a choice of what "matters" means.
How it works
Given an existing schedule, it picks apart where the curve is changing and redistributes step density accordingly, according to whichever adaptation_type you choose: gradient (steepest local change), curvature (where the curve bends most), importance, or density. sensitivity scales how aggressively it reacts to that signal, and min_step/max_step cap how small or large a single step's sigma jump is allowed to get, so the redistribution can't collapse two steps on top of each other or leave a gap so wide the sampler stumbles. target_steps lets you resample the result to a specific step count; leaving it at 0 presumably keeps whatever count the input already had.
None of this is documented in the pack's README - it's a reading of what the exposed parameters do, not a confirmed spec, and I found no community thread discussing this node specifically.
The inputs and outputs that matter
sigmas(SIGMAS, required) - the schedule to reshape.adaptation_type(enum:gradient,curvature,importance,density; defaultgradient) - what signal drives the redistribution.sensitivity(default1, range 0.1–10) - how strongly that signal reshapes the spacing.min_step/max_step(defaults0.01and1) - bounds on how big a single step's sigma delta can be.target_steps(default0, up to1000) - resample to this many steps;0keeps the input's count.
Output is a single SIGMAS list.
How to install it
- ComfyUI Manager - search "RES4LYF", install, restart.
- Manual - activate your venv,
cd ComfyUI/custom_nodes && git clone https://github.com/ClownsharkBatwing/RES4LYF,cd RES4LYF,pip install -r requirements.txt(portable builds: use the embeddedpip.exe). Restart.
Common issues & troubleshooting
Check what you actually got before trusting it. min_step, max_step, and target_steps can pull in conflicting directions - asking for a specific step count while also constraining how big each jump can be doesn't have an obviously correct resolution, and there's no documentation of how the node prioritizes between them. Wire the output into Sigmas Count to confirm the real step count before committing to a full-resolution render on an untested combination.
This is experimental even by this pack's standards. RES4LYF's own README describes its sigma-manipulation nodes generally as "experimental and subject to further changes," and this is one of the least-discussed ones in that category. There's no community-tested starting point for adaptation_type or sensitivity - you're the test case.
If it's not doing anything visible, try raising sensitivity well above 1, or lowering min_step - a schedule that's already fairly smooth going in may not have much gradient or curvature signal for the node to react to.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| sigmas | SIGMAS | — | |
| adaptation_type | COMBO | gradient | 4 options: gradient, curvature, importance, density |
| sensitivity | FLOAT | 1.00.1–10 | — |
| min_step | FLOAT | 0.010.0001–1 | — |
| max_step | FLOAT | 1.000.01–10 | — |
| target_steps | INT | 00–1000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SIGMAS | SIGMAS | — |