LoRA Inline Chain Options

This node exists for one purpose: giving you per-LoRA control over what LoRA Optimizer (Inline Chain) does with a chain of regular Load LoRA nodes it's capturing. On its own it does nothing - it's a side node that plugs into the Inline optimizer's chain_options input.

What it is and why you'd use it

The Inline Chain optimizer is a drop-in filter: it reads the LoRA patches sitting on a MODEL after a chain of stock Load LoRA nodes, merges them, and reapplies the result. Left alone, it merges every LoRA it finds with default options. That's fine until you need to say "leave LoRA #2 out entirely," or "LoRA #3 should dominate any weights it conflicts with," or "boost LoRA #1's strength by 20% relative to what the loader already set." That's what this node is for - it sits beside the Inline optimizer and exposes exactly the same per-LoRA controls LoRA Stack (Dynamic) has, but scoped to a loader chain instead of a Stack.

Slot order matters and it isn't arbitrary: slot #1 is the first Load LoRA in the chain, closest to the checkpoint - not the first one you happen to configure here. The Inline optimizer's report opens with a fingerprint showing which slot mapped to which actual file, which is the way to confirm you've got the ordering right before trusting your settings.

How it works

Set lora_count to match (or exceed) how many LoRAs are actually in your Load LoRA chain, pick settings_visibility, and configure each slot. simple mode is one strength multiplier per LoRA; advanced splits it into model/clip multipliers plus the same conflict controls as everywhere else in this pack.

The inputs and outputs that matter

Per slot: enabled_N (off removes that LoRA from the model entirely - not merged, not applied at all), strength_N - and this one's worth reading carefully: it's a multiplier on whatever strength the loader already set, not an absolute override. 1.0 keeps the loader's value as-is; 0.5 halves it. In advanced mode, model_strength_N/clip_strength_N split that multiplier between the visual and text-encoder branches. conflict_mode_N, key_filter_N, and preserve_N work exactly as they do on LoRA Stack (Dynamic) - see that article for what each option does.

Output: chain_options (LORA_CHAIN_OPTIONS) - connect it to the chain_options input on LoRA Optimizer (Inline Chain).

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 appears under loaders. No downloads; it's configuration only.

Common issues & troubleshooting

You built this node but nothing changed. It has no effect unless it's actually wired into the Inline optimizer's chain_options input - leaving it unconnected is a valid choice (the Inline node merges everything with defaults), but if you configured settings here expecting them to apply, check the connection first.

Strength isn't doing what you expect. Because strength_N multiplies the loader's own strength rather than replacing it, a slot set to 1.0 here on top of a Load LoRA node already set to 0.5 gives you 0.5 overall, not 1.0. If a LoRA seems too weak or too strong after adding this node, check the loader's own strength first - this node's multiplier is relative to that, not a fresh value.

Slot numbers don't match the LoRAs you expect. Since slot order follows chain order (closest to the checkpoint first), reordering your Load LoRA nodes on the canvas changes which slot controls which file. Check the Inline optimizer's report for the slot-to-filename fingerprint before assuming slot #1 is whichever LoRA you placed first visually.

Non-LoRA patches on the model. If your chain includes something other than plain LoRA patches (an OFT/BOFT rotation, a hook, a third-party patch shape), those pass through the Inline optimizer untouched and aren't something this options node has any control over - it only governs the LoRA patches that get captured and merged.