Resume Step (gte)

This is the smallest node in the pack and, one turn of the graph later, probably the one that saves you the most debugging.

Resume Step answers a single question: where in the schedule is this latent actually sitting? It doesn't guess. It reads the stamp that Stamp Step wrote onto the latent (the gte_step dict key) and outputs that number as an INT, ready for Sigma Segment's start_step.

That's it. No latent passthrough, no sigma, one integer out. The entire point is that the answer comes from the tensor rather than from the wiring.

Why you'd reach for it

Staged sampling has a failure mode that produces no error and no red node: the position of the latent and the step number the graph thinks it's at drift apart. Bypass a middle stage, or re-point a checkpoint widget, and the sampler is told the latent holds 34% noise when it holds 69%. It under-denoises and hands you a soft image that looks like a model problem.

The obvious fix is a switch that picks the right checkpoint depending on which stages are enabled. That works until the enabled-stage set and the switch wiring disagree - at which point you've built the same bug twice. A stamp has one copy of the fact, so bypassing a stage takes its Stamp Step with it and the latent arrives carrying whichever stage last actually ran. Resume Step is the reader for that.

If you're hand-typing start_step in a multi-stage graph, use this node instead. That's the whole recommendation.

Inputs and outputs

• latent (required) - the latent this stage is resuming from. Its stamp says where it sits.
• fallback (optional, INT, default 0) - used only when the latent carries no stamp at all.
• Output: start_step (INT) - wire it to Sigma Segment's start_step.

The fallback default of 0 is right for a fresh Empty Latent, which genuinely hasn't been sampled and therefore is at the start of the schedule. Set it higher if you're resuming a latent loaded from disk, because that latent lost its stamp on the way through the save/load round trip - the stamp lives in a dict key that isn't serialised.

When there's no stamp, the node prints [gte] Resume Step: latent carries no stamp, using fallback 0 and carries on. It's not an error - an empty latent reaching a fallback of 0 is the designed path - but it's said out loud, because the other way to get there is a latent that quietly lost its position, and you'd rather know before the render looks wrong.

Install

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

Restart ComfyUI. The console prints [gte] loaded 8 node(s) if it loaded. Or grab it through ComfyUI Manager by searching the pack title, ComfyUI-GTE (shown as "Generative Trajectory Explorer").

Zero Python dependencies - the pack's requirements.txt is deliberately empty and everything runs on the torch/numpy/Pillow ComfyUI already ships. Zero model files. It's model-agnostic; the pack's example workflow does want rgthree-comfy, KJNodes and Easy-Use, but those are for the shipped graph's helper nodes, not for this one.

Where it goes in the graph

incoming latent ──> Resume Step ──> Sigma Segment.start_step
                                   └─ (end_step from the stage's own control)

sampler.output ──> Stamp Step ──> next stage

Every stage has that same shape: read the position on the way in, write the new one on the way out. Nothing else carries the number.

Common issues

The console disagrees with your checkpoint widget. Trust the console. It's reporting the latent, and the latent is the thing being sampled - [gte] Resume Step: latent resumes at step 5 versus a widget claiming 10 means the wiring assumes something the tensor doesn't agree with.

Everything resumes at 0. Nothing upstream ever stamped the latent. Either you're genuinely at the start, or the Stamp Step on the previous stage is bypassed, or the step number never made it onto the wire because the previous stage's Stamp Step is fed from the wrong output. Follow the chain back one stage at a time.

A clamped-looking image after a reload. That's the save/load case - the stamp is gone, so fallback is doing the driving now. Set it to the step the latent was actually saved at, and you're back in sync.

Graphs saved against an older build of this pack. Node IDs are GTE_-prefixed; if yours were saved under a different prefix, this node won't resolve. Re-add it.