Log Sigmas

SIGMAS is one of those ComfyUI types you normally ignore - right up until a workflow misbehaves and you realize you have no idea what values are actually in the list. Log Sigmas prints the whole schedule to your console. That's its entire job, and it's more useful than it sounds once you're hand-constructing sigma ranges with this pack.

What it does

You feed it a SIGMAS list and an optional message prefix; it prints the sigmas to the text console so you can see exactly what a scheduler produced or what a Select Sigmas node filtered down to. It's a dead-end node - no outputs - so it lives at the end of a wire purely for observation. It's also why the pack classifies it as an output node: it does nothing except report.

Inputs:

• sigmas (SIGMAS) - any sigma list.
• message (STRING, default empty) - a label prefix so you can tell several logging nodes apart.

The key fact to remember

The README leads with the thing everyone trips on: a SIGMAS list contains the ending output sigma, even though the model is never evaluated at it. So a 30-step full-denoising schedule is actually 31 sigmas, indexed 0 to 30, and the last one is 0.0. Every time you count steps, index a range, or wonder why "step 30" seems off, this is why. Log Sigmas exists to make that visible instead of theoretical.

The caching gotcha

Here's the trap that has people convinced the node is broken: if the sigmas list and message don't change, ComfyUI won't re-evaluate the node, and nothing prints. That's ComfyUI's node caching doing its job - the inputs are identical, so the node's work is considered done and skipped. It's not a bug. If you want to force a print, change the message (add a space, bump a number). The README calls this out explicitly, which tells you how many people filed it as an issue.

Why you'd actually use it

This pack's whole gimmick is running different prediction strategies on hand-picked timesteps - and hand-picking timesteps means hand-constructing sigma ranges with Select Sigmas. When a Switch Predictions never fires or an Early/Middle/Late split looks wrong, the fastest diagnostic is to log the schedule and see what the values actually are. It's also great for reverse-engineering what BasicScheduler produced before you start filtering it. One logging node on the raw schedule and one on your selection, and you can see the whole pipeline.

Installing it

Ships in the ComfyUI-Prediction pack by @RedHotTensors (Project RedRocket). ComfyUI Manager → search "ComfyUI-Prediction", or:

cd ComfyUI/custom_nodes
git clone https://github.com/redhottensors/ComfyUI-Prediction

Restart ComfyUI. No extra dependencies or model files. It lives under Add Node > sampling > custom_sampling > sigmas - note the menu, the prediction nodes are elsewhere.

Common issues

• Nothing prints. Inputs didn't change, so the node was cached. Change the message.
• Console is somewhere you aren't looking. It prints to the terminal you launched ComfyUI from - or the server logs if you're running headless. Check the right place.
• Counting off-by-one. Remember the trailing 0.0 sigma when you interpret what you see.