JLC LoRA Loader - Multi-Model / Shared Block Weight

Stacking LoRAs in ComfyUI is easy. Stacking five of them and keeping the graph readable is not. The stock way is a line of LoraLoader nodes, each with its own strength slider, taking up half your canvas and making every experiment a drag-to-reconnect session. The JLC LoRA Loader - Multi-Model / Shared Block Weight is the answer if you want that stack collapsed into one node with up to ten slots - and you want all of them to share the same block-weight profile.

It's the MODEL-only member of JLC's dynamic LoRA family. No CLIP patching, no text-encoder tricks; it patches the diffusion model and hands you a single MODEL out the other side. If your LoRAs are Flux-era character or style LoRAs - which is most of them now - that's usually all you wanted anyway.

How it works

The node predeclares ten slot rows (each with a LoRA picker and a strength_model slider), then a bit of frontend JavaScript hides every row above slot_count. The backend treats slot_count as the authority: slots above it are ignored entirely, but their hidden values stay serialized in the workflow JSON. Lower the count to tidy up, raise it later and your old selections come back. That's the whole trick, and it's why you can shrink and grow the stack without rebuilding it.

Two things matter about what happens during execution. First, active slots are applied sequentially in slot order - if two LoRAs fight, order still matters. Second, since this is MODEL-only, the loader filters text-encoder/CLIP keys out of each LoRA file before patching, so you don't get a wall of misleading "missing TE keys" warnings for LoRAs that were never meant to touch the text encoder.

The block vector, explained

block_vector is a comma-separated list of numbers. The first value is the base ratio applied to unmatched or "other" MODEL keys; the rest are consumed across the encountered MODEL block indices (input_blocks, middle_block, output_blocks, double_blocks, single_blocks and friends). If the vector runs out, the last value is reused. Zero suppresses the patch for that block; any other value scales the slot's strength there.

The default 1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1 is a Flux-flavored "skip the early blocks, keep the rest" profile. If you've ever seen a Flux block-weight recipe that zeros out the first handful of transformer blocks, this is that idea as a CSV.

Inputs that matter

• model - your base MODEL in, patched MODEL out.
• slot_count (1–10) - how many rows are active. The only widget that reshapes the node.
• block_vector - the shared profile applied to every active LoRA.
• lora_01…lora_10 + strength_model_01…10 - per-slot LoRA and its MODEL strength. A slot with None or strength 0.0 is skipped.

The output is a single model, ready to feed your sampler. If you need independent block profiles per LoRA, this isn't the node - JLC's per-slot block-weight variants do that, and honestly they're visually dense. Start with the shared one.

Installing it

The whole pack installs at once - this node ships in jlc-comfyui-nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/Damkohler/jlc-comfyui-nodes.git

Restart ComfyUI. Or just search "jlc-comfyui-nodes" in ComfyUI Manager. There are no Python dependencies to satisfy - the pack is pure ComfyUI nodes, no requirements.txt to fight.

Where people get burned

• CLIP side gets ignored on purpose. If a LoRA's text-encoder side was doing real work and you lose it, that's this node's design. Reach for the MODEL+CLIP variant if you need TE patching.
• Block weights only apply to MODEL patches. Don't expect the vector to shape CLIP behavior, because there isn't any here.
• Hidden slots still count as "set." A hidden row with a selected LoRA and nonzero strength is ignored only because slot_count says so - bump the count and it activates. That's a feature, but it surprises people mid-workflow.
• Negative strengths work. Block-weight patching with a negative value is an advanced move; use it deliberately or it'll bite.

This is a niche, well-behaved utility from a small solo pack. It won't speed up your sampling - it's about keeping a big LoRA stack sane on the canvas. If that's your problem, it does the job.