Schedule Info (gte)

A step number is not a noise level, and the gap between the two is where staged diffusion goes wrong.

The scheduler decides how the denoising is distributed across your steps, which means two schedulers with the same step count put wildly different amounts of noise at the same index. On an 8-step rectified-flow schedule:

step        karras   kl_optimal   simple      exponential
   1         54.1%        79.8%    87.5%            41.2%
   5          2.2%        23.0%    37.5%             1.2%
   7          0.2%         0.2%    12.5%             0.2%

Branching at "step 5" therefore means something completely different depending on a dropdown three groups away. Under karras there's 2% of the image left to vary and the branch cannot work; under simple there's 37%. Nothing on the canvas says so, and the failure is silent - your descendants come back looking like damaged copies of the parent rather than alternatives.

So this node reads the schedule and says it out loud.

How it works

Feed it the full SIGMAS and it builds a text table: the step index, the sigma, how much noise is left (as a percentage of the schedule's first value), and how much noise that particular step removes.

That last column is the one I'd actually look at. Flat numbers all the way down mean the work is spread evenly and every step is a usable place to stop. A column that runs 22%, 14%, 6%, 1%, 0%, 0% is telling you the back half of the schedule is doing nothing - move your checkpoints forward, or pick a scheduler that spreads better. It's a two-line answer to "is step 10 a sensible place to stop", which is otherwise a question you answer by burning a run and guessing.

Nothing in this pack assumes a particular schedule shape - segments slice whatever they're handed, continuation is exact because euler is memoryless, and Noise Rotate uses the real sigma, never the step index. So a front-loaded scheduler isn't broken here. It just squeezes your choices into fewer steps and wastes the rest of the compute you paid for.

Inputs and outputs

• sigmas (required, SIGMAS) - the full schedule, the scheduler's output, before any Sigma Segment slicing. Percentages are relative to its first value, so a slice would give you percentages of the wrong thing.
• marks (optional, STRING, default empty) - checkpoint steps to highlight, comma separated: 1,5,7. Semicolons work too, and anything unreadable is ignored with a console line rather than failing the run. Pure decoration; it changes nothing about the generation, it just flags those rows <-- checkpoint so you can read one line and stop scrolling.
• Output: table (STRING). Wire it into Show Text · Lines from the same pack to keep it pinned on the canvas, or any core string-display node.

Tip from the pack's own workflow guide: set marks to the same numbers you typed into the stage checkpoint controls. Then "is my checkpoint in a good place" is a glance instead of a spreadsheet.

Where it goes

Tap the same SIGMAS that the stages consume - the scheduler output, before the first Sigma Segment. The node is an output node, so it recomputes and re-displays on every run even when nothing downstream needs it; a readout that only appeared when something else happened to want it would be no use. It also prints the table to the console, so you can read it in the log after the fact.

scheduler ──┬──> Schedule Info ──> Show Text · Lines
            └──> Sigma Segment ──> sampler

Install

cd ComfyUI/custom_nodes
git clone https://github.com/mgkgng/ComfyUI-GTE

Restart. [gte] loaded 8 node(s) in the console means it loaded. ComfyUI Manager: search the pack title ComfyUI-GTE (displayed as "Generative Trajectory Explorer"). No Python dependencies - the pack's requirements file is deliberately empty, everything runs on the torch/numpy/Pillow ComfyUI already ships. No model files. The nodes are model-agnostic; if you load the shipped example workflow instead, that wants rgthree-comfy, KJNodes and Easy-Use for its helper nodes.

Common issues

"Need at least two sigmas to describe a schedule." You wired a segment or a single sigma instead of the full schedule. This node wants the wide view; slicing is Sigma Segment's job.

The table is right but your branch does nothing. Read the noise left column at your checkpoint, then read it again for a different scheduler. This is exactly the failure the node exists to expose: 2% of the image left is not a place you can branch from, however good the step number looks.

Percentages don't match your intuition from another model family. They're relative to the first sigma of this schedule, and eps-prediction models (SD1.5/SDXL) add noise with an unbounded sigma while rectified-flow models mix it in - so shares do not transfer across families (see kg/entities/flow-matching.json). Compare a schedule against other schedules of the same model.

Node names shifted. These are GTE_-prefixed IDs; graphs saved against an earlier build of the pack won't resolve them.