🌊 Flow Match Scheduler (Dynamic)

Flux doesn't use one fixed shift value the way SD3 does. It scales shift with your output resolution - small images get a gentler shift, large ones get pushed higher - because the ideal split between "steps spent on composition" and "steps spent on detail" isn't a constant, it moves with how much detail there actually is to resolve. FlowMatchSchedulerDynamic is that resolution-aware calculation, exposed as a standalone node instead of buried inside a model loader.

What it's actually for (and what it's explicitly not for)

This is the Flux-shaped sibling to this pack's plain FlowMatchScheduler, which makes you pick a fixed shift number yourself. Here, instead of a shift widget, you give it your target width and height plus two shift bounds, and it interpolates between them based on resolution - smaller images lean toward base_shift, larger ones lean toward max_shift. The node's own description calls it out directly: "Resolution-aware scheduler (Flux style). Automatically computes shift based on image size." And just as directly, it tells you when not to use it: "Not needed for Z-Image-Turbo (use ZImageTurboScheduler instead)." Z-Image-Turbo's schedule is a fixed linear curve regardless of resolution - this node's whole reason for existing is a problem Z-Image-Turbo doesn't have.

The inputs and outputs that matter

• steps (INT, default 20, range 1–1000) - how many sigma values to generate. Flux Dev commonly runs in the 20-ish range; adjust for whatever variant you're actually on.
• width / height (INT, default 1024, range 64–8192, step 8) - your target output resolution. These directly drive the shift calculation, so set them to match what you're actually generating, not a placeholder.
• base_shift (FLOAT, default 0.5, range 0–5, step 0.05) - per the tooltip, "mu for small images (256x256)." The shift value used at the low end of the resolution range.
• max_shift (FLOAT, default 1.15, range 0–5, step 0.05) - per the tooltip, "mu for large images (512x512+)." The shift value used at the high end. Notably, these two defaults (0.5 and 1.15) match Flux's own published defaults for this exact interpolation - this node isn't approximating Flux's behavior, it's reproducing it.

Two outputs:

• sigmas (SIGMAS) - wire into SamplerCustom / SamplerCustomAdvanced like every other scheduler here.
• computed_shift (FLOAT) - the actual shift value the node landed on for your given resolution. Handy if you want to sanity-check what number came out, or log it, rather than trusting the interpolation blind.

How to install it

ComfyUI Manager: search "ComfyUI-ZImageTurbo-FlowSampler," install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/capitan01R/ComfyUI-ZImageTurbo-FlowSampler

Restart ComfyUI. No extra dependencies, no downloads - this is the same lightweight scheduler code as the rest of the pack.

Common issues & troubleshooting

Using this on Z-Image-Turbo. The node's own description tells you not to - reach for ZImageTurboScheduler instead, which hardcodes the linear curve that model was actually distilled on. Resolution-dependent shift is a Flux concept, not a Z-Image one.

Leaving width/height at the 1024 default while generating at a very different size. The entire point of this node is that shift should track your actual output resolution. If those fields don't match what you're really rendering, you're back to a fixed, slightly-wrong shift value - no better than just picking a number manually with the plain FlowMatchScheduler.

Not knowing what computed_shift came out as, then guessing why results look off. That output exists specifically so you don't have to guess - check it (route it to a text/number preview) before assuming the node did the wrong thing. If the number looks reasonable but results still seem off, the problem is more likely elsewhere in your sampler chain.