SigmaSync LoRA

A normal LoRA loader gives you one strength number for the whole generation. SigmaSync LoRA gives you a curve - the strength can start at 1.0, sag to 0.1, spike back to 1.3 in the middle, whatever you like - and it's keyed to the exact noise schedule your sampler is running. You decide what the LoRA does at each stage of denoising, not a single average of what it did across all of them.

Why bother? Denoising isn't one task. Early steps (high sigma) decide composition, pose, structure; late steps (low sigma) decide texture and detail. A character or style LoRA that's perfect for locking in composition may start bleeding or over-saturating when it stays cranked through the detail phase - that "strength 0.8 looks great, 0.9 looks overcooked" wall is exactly this problem (lora-training.md flags the same "style bleeds even at low strength" failure from the training side). Ramping strength down as noise clears is the manual workaround people have done by hand for years. This node automates it and, unlike the old hand-rolled tricks, does it in sigma space rather than guessing at step numbers.

How it works

The trick is in the name: it's "sigma-aware." You feed it the same SIGMAS tensor your sampler is using (from Basic Scheduler, Custom Sigmas, or any scheduler node). The node takes every sigma except the last one - the terminal 0.0 endpoint is never a model call - and treats each as an anchor point for the LoRA's strength.

At runtime it wraps the model's apply function and, at every model call, looks up the current sigma and sets the LoRA's multiplier to match. Between anchors it linearly interpolates in sigma space, so your curve is smooth even if the sampler evaluates somewhere between two scheduled points. Two details worth knowing:

• The LoRA is not merged into the base weights. Strength is applied live through bypass-compatible injection hooks and reset to zero after each call. Change the schedule and there's nothing to re-merge.
• Multiple SigmaSync loaders stack, but they must be adjacent. Any other MODEL patch node between two of them throws "SigmaSync LoRA nodes must be adjacent" - put other patchers before the first or after the last one.

The inputs that matter

Seven inputs, but you'll set maybe four of them most days.

• model and sigmas - wire your model in, and the same sigmas wire that goes to your sampler. This node reads the schedule; it doesn't change it.
• lora_name - pick from your ComfyUI/models/loras folder. Note the "model-only" constraint: the loader accepts UNet/weight adapters only, so a LoRA that also patches the text encoder will error out.
• curve - linear, cosine, smoothstep, power, or explicit. Default linear is a fine starting point; power (with curve_power above 1) holds the starting strength longer before tapering.
• explicit_strengths - only used in explicit mode, and it's the fiddly one: exactly one value per model-call sigma. A nine-value schedule means eight strengths, because the terminal endpoint isn't a call. Get the count wrong and the node refuses to run.

The output is a single MODEL, which then feeds your guider/sampler in place of the raw model.

Installing it

Either search "SigmaSync LoRA" in ComfyUI Manager, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/capitan01R/ComfyUI-SigmaSync-LoRA.git

Restart ComfyUI after. No extra Python packages - it's pure ComfyUI dependencies, which is refreshingly rare.

Where people get burned

This pack is brand new (August 2026), so there's no battle-tested community lore yet - treat it as promising rather than settled. The sharp edges are all in the source:

• explicit mode miscounts. Count the sigmas in your schedule tensor, subtract one, and that's how many strengths you need. The error message tells you exactly how many it wants, so it's recoverable - just annoying.
• Weird schedule tensors get rejected. The node validates that your sigmas are strictly descending, non-negative, and finite. A sampler that emits repeated sigma values can't be scheduled this way, and it'll tell you.
• It's model-only by design. If your LoRA carries CLIP/text patches, the loader throws rather than silently dropping them.

And the honest caveat: 0.1-to-1.0 default curves are a reasonable starting guess, not a formula. Ramp up and see whether your LoRA actually behaves differently across the trajectory - plenty of LoRAs don't care much, and for those this node is just overhead.