JLC LoRA Loader - Multi-Model / CLIP + Block Weight

Sometimes you don't want a LoRA applied everywhere with the same force. A character LoRA can carry a face you love and a hairstyle you hate; a style LoRA can nail the color grade while wrecking the composition. JLC LoRA Loader - Multi-Model / CLIP + Block Weight is the version of the pack's dynamic loader that lets you slice each LoRA's influence across the network's blocks - up to ten LoRAs, each with its own strength and its own block-weight vector.

It's the per-slot block-weight MODEL+CLIP variant, from the same jlc-comfyui-nodes pack (J. L. Córdova / Damkohler). Same dynamic-slot design as the plain Multi-Model / CLIP loader: ten predeclared slots, slot_count hides the ones you don't use, hidden values stay in the workflow JSON. The difference is one extra widget per slot.

What the block vector actually is

Each active slot gets a block_vector_XX - a plain CSV string, like this default:

1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1

The semantics, from the pack's own docs:

• vector[0] is the base ratio for unmatched/"other" MODEL keys
• vector[1:] is consumed across the model's block indices as patches are applied
• if the vector runs out, the last value gets reused
• a 0 suppresses the LoRA on that block, a nonzero value scales the slot's MODEL strength there

The helper recognizes the common block families - input_blocks, middle_block, output_blocks, double_blocks, single_blocks - which is how one string format works across SD1.5, SDXL, and Flux. The example above says "kill the first ~seven encoder blocks, keep the middle and the decoder," a classic "only change the later layers" profile. If you've never touched block weights, note that zeroing the early input blocks and keeping the output blocks is the profile people actually reach for when a LoRA's effect feels too global.

Crucially, block weights apply only to MODEL/UNet patches. The CLIP/text-encoder side of each slot uses its ordinary strength_clip_XX and ignores the vector entirely.

The inputs that matter

• model, clip - wire your checkpoint in; both come back out the other side
• slot_count - authoritative; 1–10
• per slot: lora_XX, strength_model_XX, strength_clip_XX, block_vector_XX

Outputs are model and clip, patched sequentially in slot order and ready for the KSampler and text encoders.

The one real trap here is the same one as every block-weight node: a vector that suppresses everything on a slot makes that slot silently do nothing, and debugging "why isn't my LoRA doing anything" with a CSV in the way is no fun. If you're new to this, leave vectors at their default until you have a reason.

Install & dependencies

ComfyUI Manager (search JLC ComfyUI Nodes) or:

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

Restart after install. No models to download, no extra pip deps - pyproject.toml lists none. Restarting ComfyUI once after a git pull update is the whole maintenance story.

Should you use it?

If you don't know why you'd block-weight a LoRA, you don't need this node yet - the plain loaders apply every LoRA uniformly and that's fine for most stacks. Reach for it when two LoRAs target the same region and you want them to stop fighting, or when a specific LoRA is bleeding into parts of the image you don't want touched. For the "one profile for everyone" case, the pack's Shared Block Weight variant gives you a single vector for the whole stack and a much cleaner node. Per-slot vectors are the flexible end of the spectrum, and they're visually dense - that's the price of the control.