Sigmas Truncate

Of all the exotic sigma tools in RES4LYF, this is one of the plainly useful ones. It keeps the first sigmas_until steps of a schedule and drops everything after - that's the whole node.

The reason it's worth knowing is the pattern it enables: chaining two samplers, one handling the high-noise portion of a generation and a second finishing the low-noise portion, is a real and popular technique - it's exactly what people already do by hand for dual-model setups like Wan 2.2's high-noise/low-noise pair, running one sampler over roughly the first half of the steps and a second over the rest. Truncate is how you build the first piece of that split cleanly: cut your full schedule down to just the steps the first-stage sampler should see, and route the rest of the graph accordingly. Sigmas Pad and Sigmas Unpad are the companions you'll usually reach for alongside it, to fix up the seam where the two pieces need to meet.

The inputs and outputs that matter

sigmas is the schedule to cut. sigmas_until (an INT, default 10) is how many steps to keep from the start - everything after that index is dropped. The single output is SIGMAS, containing just the kept portion.

Installing it

ComfyUI Manager: search RES4LYF, install, restart. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/ClownsharkBatwing/RES4LYF/
cd RES4LYF
pip install -r requirements.txt

Use the embedded pip.exe on a portable ComfyUI build. Restart and hard-refresh the page afterward.

Where people get tripped up

The mistake that actually matters here is the seam between stages. If you truncate a schedule down to its first N steps for stage one, the schedule you feed into stage two needs to pick up in the same noise range where stage one's truncated tail actually sits - not restart from the top of a fresh schedule. Get that wrong and you either re-add noise the model already removed, or skip straight past a chunk of the denoising process, and the failure looks like a bad generation rather than an obvious error pointing at this node.

Also remember sigmas_until counts from the start, not the end - if you're trying to keep the tail of a schedule instead of the head, this isn't the node for that; you want to be truncating from the other direction, which this node doesn't do.

Worth noting this node has nothing to do with the truncate_conditioning option mentioned in some of RES4LYF's older example workflows - that's a conditioning setting on the sampler itself, a different feature entirely that happens to share part of a name. If you're chasing down an old workflow screenshot that mentions truncation, check whether it means this node or that sampler option before assuming they're the same thing.