LoRA Experimental Options

Here's the first thing to know: this node doesn't merge a single tensor. It's a settings widget - one box that outputs a single experimental_options value telling the LoRA Optimizer pack's AutoTuner to also try two bleeding-edge, weight-only merge methods (NP-LoRA and CT-Merging) as extra ranked candidates. Think of it as a checkbox that says "yeah, run the research algorithms too" and a few dials that tune how those algorithms behave. Disconnect it and everything runs exactly as it always did.

When would you bother? The pitch for NP-LoRA is specific and genuinely appealing: you have a character/subject LoRA and a style LoRA that keeps stomping on the subject's likeness, and you want the tuner to test a subject/style separation merge instead of you hand-wrangling strengths forever. The stable methods in the pack (TIES, weighted blends, the per-prefix conflict stuff) are already the right default for most stacks. This is for when "pretty good" isn't cutting it and you're curious whether the papers can do better. The author's own docs are refreshingly honest about it: opt-in, no sampling, no training, and H3 video/audio quality from these methods is unvalidated.

How it works

The node produces an options object (LORA_EXPERIMENTAL_OPTIONS) that you feed into either the LoRA AutoTuner's experimental_options socket or into LoRA AutoTuner Settings, which then feeds the main optimizer. When connected, the tuner adds these methods as separate competing candidates - both enabled means independent merges, not some Frankenstein combo - on top of the stable top_n grid. With defaults you get three extra merges: a plain additive baseline, one NP-LoRA trial, and one CT-Merging trial. The winners are ranked alongside the stable ones and shown in the report; you can flip through them with a Merge Selector.

The mechanics, briefly: NP-LoRA is an asymmetric soft-projection that removes the subject/content contribution that overlaps the style's singular directions - it needs exactly two active, non-preserved adapters in your stack and cares which is subject and which is style. CT-Merging splits each adapter's update into a shared common subspace plus per-task residuals, then merges the common parts. Both are implemented from the papers (NP-LoRA arXiv 2511.11051, CT-Merging arXiv 2607.20561), not copied from other packs.

The inputs that actually matter

• enabled / np_lora / ct_merge - the on/off trio. The master switch only does anything while the node is connected.
• np_subject_slot and np_style_slot - which of your two adapters plays which role, counted among active, non-preserved entries in stack order. Slot 1 subject, slot 2 style by default. Only meaningful when NP-LoRA is on.
• np_strength (0.5) - the soft-projection strength μ. Zero is plain additive; higher pushes the style harder out of the subject's way. This is the knob to reach for first.
• ct_common_rank (4) and ct_residual_rank (16) - how much shared vs per-adapter detail CT-Merging keeps per layer.
• trials_per_method (1) - extra trials at half and double strength/scale. More trials, more runtime.

Installing it

Same as the whole pack: ComfyUI Manager → search "LoRA Optimizer" → install, or:

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

Restart ComfyUI. The only dependency beyond stock ComfyUI is scikit-learn (ComfyUI Manager handles it). No model files, no API keys, nothing to download - it's all math on your local LoRA weights. The node sits under "LoRA Optimizer/Experimental" in the node menu.

Where people get burned

NP-LoRA requires exactly two active adapters - if you've got a stack of four, or one entry is preserved (as turbo/distillation LoRAs should be - never cast those as subject or style), the NP candidate gets skipped with a reason in the report rather than half-applied. Also expect it to be slow: experimental candidates score every target group, deliberately bypassing AutoTuner's fast scoring subset, so the whole sweep runs hot on big models. And remember the pack's standing caveat - the weight-space scores these candidates get measure math, not whether the image actually looks good. Worth noting too that the wider community's main gripe with the optimizer family is that LoRAs aren't all trained to behave at strength 1.0; this node is downstream of that debate, not a cure for it. Try the defaults first, eyeball the ranked report, and treat anything experimental as a candidate, not gospel.