LoRA Optimizer (Inline Chain)

If you're starting fresh, the LoRA Optimizer README steers you toward LoRA Stack → LoRA Optimizer. But most people don't start fresh - they have a workflow already built around a chain of regular Load LoRA nodes, and rebuilding it around a Stack node just to get conflict-aware merging feels like a lot of friction for something you already have wired up. This node exists for exactly that: drop it in after your existing loader chain, and it does the merge without you touching anything upstream.

What it is and why you'd use it

It's a filter, not a loader. It reads the LoRA patches your regular Load LoRA nodes already left on MODEL/CLIP, strips them off, merges them with the same conflict-resolution engine the Stack-based Optimizer uses, and reapplies the merged result. Outputs match the other optimizer nodes - model, clip, analysis_report, tuner_data, lora_data - so Save Merged LoRA and everything downstream still works.

The README is honest about the tradeoff: for new workflows, Stack → Optimizer is still preferred, because loading from files directly gives the optimizer real filenames, embedded metadata, and reliable architecture auto-detection. Inline capture is the retrofit path, not the recommended default - reach for it when the cost of rebuilding an existing graph outweighs those benefits.

How it works

Place it after your last Load LoRA node. It walks back through the patches attached to the incoming MODEL, works out which LoRA is which by chain order (slot #1 = the loader closest to the checkpoint), merges them, and re-patches the model with the merged result. One notable detail: if your chain is fed by stock Load LoRA / Load LoRA (Model Only) or the rgthree Power Lora Loader - the node rgthree-comfy is best known for, and the component most people actually reach for when stacking LoRAs in ComfyUI - the Inline optimizer recovers the real LoRA filenames and shows them in its report. Other loaders that don't tag their output the same way fall back to a generic chain lora #N label instead.

The inputs and outputs that matter

• model (required) - the output of your Load LoRA chain, patches and all.
• output_strength (default 1.0) - same as the Stack-based Optimizer: master volume, set to -1 for auto.
• clip (optional) - from the same loader chain, so text-encoder patches get merged too.
• clip_strength_multiplier - separate volume for the CLIP side.
• settings (optional) - a LoRA Optimizer Settings node for full manual control; both advanced settings and full AutoTuner mode (search/memory/community cache) work inline.
• chain_options (optional) - connect a LoRA Inline Chain Options node for per-LoRA enable/strength/conflict/preserve control. Leave it unconnected and every captured LoRA merges with default options.

Outputs: model/clip for your sampler, analysis_report for a Show Text node, tuner_data and lora_data for chaining to Merge Selector or Save Merged LoRA.

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 loader chain you already have.

Common issues & troubleshooting

It doesn't work on WanVideo wrapper models. The README states this plainly as a v1 limitation - if you're on kijai's WanVideoWrapper, this node isn't the right tool; there's a dedicated WanVideo LoRA Optimizer variant for that path instead.

Architecture detection reports unknown. Inline capture doesn't get the same reliable auto-detection a file-based Stack does, since it's working from patches on a model rather than files with metadata. If you're not getting arch-tuned thresholds, set architecture_preset explicitly via a Settings node instead of relying on auto.

Model/CLIP pairing looks off. The README calls this out directly: pairing is inferred by chain order, and a LoraLoaderModelOnly node or a text-encoder-only LoRA in the chain can shift that attribution. The report warns when the model and clip group counts don't match - if you see that warning, check for a model-only or CLIP-only loader breaking the expected 1:1 pairing.

Fully-disjoint LoRAs at identical strength. When two LoRAs in the chain touch completely different weights at the same strength, their chain fingerprints can end up ambiguous about ordering - this is a known v1 rough edge, and the report is where you'd catch it, not a sign something's broken.