LoRA Conflict Editor

LoRA Optimizer's default behavior is automatic on purpose - it analyzes conflicts and picks a strategy per layer without asking you anything. Most of the time that's exactly what you want. But automatic means the optimizer is guessing at intent from the numbers alone, and sometimes you know something it doesn't: you know two specific LoRAs in your stack are going to clash and you want one to win outright, or you know two of your LoRAs are near-duplicates (say, two checkpoints from the same training run) and want them treated as agreeing rather than conflicting. LoRA Conflict Editor is where you override the automatic read with what you actually know.

How it works

It sits between a LoRA Stack and LoRA Optimizer. Feed it a stack, and it loads every LoRA, computes full-rank diffs, measures pairwise sign disagreement, and auto-suggests both a per-LoRA conflict_mode and an overall merge_strategy. You can take its suggestions as-is or override any of them by hand - it's a diagnosis-plus-editable-prescription tool, not a black box.

The merge_strategy options are worth understanding individually, since this is the one node in the pack where you pick one directly rather than letting the optimizer choose per-layer: ties forces TIES-Merging everywhere (good for genuinely high-conflict stacks), slerp forces spherical interpolation (magnitude-preserving, suited to low-conflict pairs), weighted_average is straightforward blending for compatible LoRAs, and weighted_sum is direct addition that preserves every weight exactly. The one that doesn't get explained in the README's main sections is consensus - the pack's author described it directly in a community thread as a three-part method (Fisher-proxy weighting, magnitude calibration, and spectral cleanup) built specifically for merging extremely similar LoRAs, like two checkpoints from the same training run at different steps. If you've ever trained the same concept twice and wondered whether averaging the results would beat either one alone, consensus is the mode built for that case - the author flagged it as still relatively fresh and less battle-tested than the others, so treat it as a tool worth trying rather than a guaranteed win.

The inputs and outputs that matter

• lora_stack (required) - the stack to analyze. Connect it before the Optimizer, not after.
• merge_strategy (default auto) - auto lets the optimizer decide per-layer as normal; anything else forces that one strategy across the whole stack.
• conflict_mode_1 through conflict_mode_10 (default auto each) - per-LoRA override, one slot per LoRA position in the stack. auto takes the node's own suggestion; all/low_conflict/high_conflict work the same as everywhere else in the pack - force this LoRA to apply everywhere, only where it agrees with the majority, or only where it disagrees.

Outputs: lora_stack - the same stack, enriched with your conflict decisions, ready to feed into LoRA Optimizer. analysis_report - wire to Show Text to actually see the conflict data the suggestions were based on. merge_strategy - the resolved strategy as a STRING, which is also what the Optimizer Settings node's merge_strategy_override input expects if you want to pass it along explicitly.

How to install it

ComfyUI Manager: search "LoRA Optimizer", install, restart. Manually:

cd ComfyUI/custom_nodes/
git clone https://github.com/ethanfel/ComfyUI-LoRA-Optimizer.git

Restart - it's under loaders. No downloads; it works on the LoRA files in your stack.

Common issues & troubleshooting

You forced a strategy and results got worse, not better. That's a real possibility, not just user error - the automatic per-layer decision exists because a single global strategy is often a worse fit than letting different weight groups get different treatment. If forcing ties or slerp everywhere hurts a stack, that's a sign this particular stack benefited from the automatic mixed approach; go back to auto on the Optimizer instead of the Conflict Editor.

Trying to merge two very similar LoRAs and it still looks off. This is specifically what consensus targets. Set merge_strategy to consensus rather than leaving it on auto or forcing ties - a high-similarity pair is exactly the case regular conflict resolution isn't optimized for.

Suggestions don't match what you'd expect from listening to the LoRAs' descriptions alone. The suggestions come from measuring actual weight-level sign disagreement, not from anything semantic about what the LoRAs are "about." Two LoRAs that sound unrelated (a hairstyle LoRA and a lighting LoRA) can still show real numeric conflict if they happen to touch overlapping layers - trust the report over intuition here.