Minimal Change Flow

Everything else in this pack is about shaping the sigma schedule. Minimal Change Flow is the odd one out: it's a sampler, and it doesn't care what schedule you feed it. Its job is to stop the sampling trajectory from jumping too far in a single step. If you've ever watched a low-step flow-matching run get most of the way and then fall apart into artifacts, this is a real band-aid - and it's applied every single step, not just once.

How it works

It runs a standard Euler-style interpolation - x_new = ratio·x + (1 − ratio)·denoised - then measures how big the move was: relative change = mean|delta| / mean|x|. If that exceeds your max_change_per_step, it scales the delta down proportionally so the step stays inside the limit. The author calls it antilock brakes, and that's genuinely the right mental model: the model predicts a jump, the sampler says "okay, but only this far."

One detail worth knowing before you blame the scheduler: the clamp keys off latent magnitude, not sigma ratios. The author confirmed this directly in the release thread - "the clamp is based on latent delta magnitude vs |x|, not sigma ratios." A gentle linear or cosine schedule reduces how often it fires, but doesn't prevent it. Early steps are when it actually engages, because the model will happily try a massive one-shot change to layout or composition on a detailed prompt.

Inputs and outputs

The node is gloriously simple: one input, one output.

• max_change_per_step - default 0.70, range 0.05 to 1.0. Maximum relative change allowed per step
• Output: SAMPLER - wire it into the sampler input of SamplerCustomAdvanced or SamplerCustom, next to any SIGMAS you like

The README offers three recipes: maximum stability is Smooth Cosine scheduler plus 0.5–0.6 (also the setting for ultra-high resolutions); the balanced daily driver is the CapitanZiT linear scheduler at the default 0.70; pure speed is CapitanZiT linear plus euler in a plain KSampler with no sampler node at all. Expect about 5–10% overhead - it's an extra magnitude check per step.

Install

Same pack as the rest:

cd ComfyUI/custom_nodes
git clone https://github.com/capitan01R/ComfyUI-CapitanZiT-Scheduler

then restart ComfyUI, or use ComfyUI Manager (search "ComfyUI-CapitanZiT-Scheduler"). No dependencies, no downloads - the sampler is a few dozen lines of Python wrapping a comfy.samplers.KSAMPLER.

Where people get burned

• The step counter looks wrong, and that's fine. People immediately reported the sampler "stopping two steps early." It's intentional: when sigma_next hits 0, the sampler applies the final denoise and exits - there's nothing left to integrate, and ComfyUI's counter reflects the scheduler length, not the effective integration steps. Not a bug.
• "It's too sharp" was the most common complaint in the release thread. The author's fix is to raise max_change_per_step, and their recommended pairing is this sampler with the Smooth Cosine scheduler - that combo is the default answer to the sharpness complaint.
• Lower isn't always better. 0.5–0.6 buys stability at high resolutions but converges slower; 0.8–0.9 is faster with looser reins. Start at the 0.70 default and only touch it when you have a symptom.

The honest verdict: the README's error-bounding math is the kind of back-of-the-envelope claim you learn to read sideways. But the mechanism is real, cheap, and a small community of low-step Z-Image Turbo users report it genuinely steadies output - especially at high resolution where step-to-step jumps turn into anatomy and texture artifacts.