MiniMax H3 LoRA Schedule

Most LoRA advice treats strength as one number. It isn't - it's a number per denoising step, and on H3 the difference is visible. A turbo distillation adapter that should carry the structure for the first few steps and then get out of the way, or a style LoRA you want at 0.9 early and 0.2 by the end, is exactly what this node is for.

It's the third node in the MiniMax H3 Power LoRA Stack pack, and unlike the other three it does nothing on its own. It produces a schedule object that the stack consumes.

How it works

You pick rows, you pick a curve, you pick a start and end strength, and the stack varies those rows' strengths as the sampler runs. Two domains: steps follows model-call indices, sigma follows the scheduler's actual normalized noise values. The stack reads ComfyUI's sampler timeline itself, so there's no SIGMAS wire to connect and no timestep-math to hand-manage - plain KSampler is fine.

The curves are the usual suspects: linear, cosine, smoothstep, power (shaped by curve_power), step, or explicit for your own per-step list.

The one mechanical consequence worth understanding: scheduled rows always use the live runtime branch path, even on an unquantized bf16 base. A varying strength can't be folded into a static weight, so those rows stay as runtime adapters and you pay a little extra FLOPs and a little VRAM for them. If a row can't take that path, it gets merged at its static strength instead and the stack's report says so - silently, in the report, which is why you read the report.

The inputs

rows is the one you'll get wrong first. It's a string, and it takes all, a list like 1,3, or a range like 2-4. Row numbers are the stack's rows in UI order, so if you drag a row around on the stack node, your schedule follows different LoRAs. Number your rows deliberately.

Then start_strength and end_strength (defaults 1.0 → 0.1, both spanning −10 to 10 - negative works, which is the usual way people try to subtract a concept), curve, and the start_percent / end_percent window that limits where the transition happens. explicit_strengths is a plain text box, comma- or space-separated, one value per intended step, and it's only used when curve is set to explicit. domain switches between steps and sigma.

That's a lot of knobs for a node with no required wire, so here's the short version: rows, start_strength, end_strength, and leave the rest alone until you have a reason.

Outputs are schedule - into the stack's schedule input - and info, a one-line summary string that's worth wiring to a Show Text node if you're chaining.

Chaining is where it gets genuinely useful: there's an optional schedule input for the previous node in the chain, so you can hand rows 1–2 a cosine falloff and rows 3–4 a flat hold. Where selectors overlap, the later node wins.

Install

Comes with the pack; nothing separate. No pip dependencies.

cd ComfyUI/custom_nodes
git clone https://github.com/cicalooo/ComfyUI-H3-PowerLoraStack

Restart, and look for MiniMax H3 LoRA Schedule under the MiniMax-H3/lora category. Manager users: search MiniMax H3 Power LoRA Stack.

Common issues

Schedules need the stack to feed them row strengths - if the stack reports a row as merged rather than branched, your schedule didn't apply to it, and the reason will be in the report text.

rows is parsed, not validated against your stack. A selector that names a row you don't have is a silent no-op rather than an error, so a schedule that "does nothing" is usually a row-numbering mistake. Schedule node numbering and stack node numbering are separate things; keep them straight by watching the info output, which echoes exactly which rows you selected.

And if you're scheduling a distillation LoRA, remember what the KB already says about that whole category: distilled adapters want CFG 0–2 and a step count matching what they were trained for. A schedule won't rescue a turbo LoRA running at 20 steps with CFG 7 - it'll just vary the strength of something that was never going to look right.