Flux Block LoRA Merger 🧹

Most people never merge a Flux LoRA at all - they stack it on a sampler and adjust the weight. That works, until it doesn't: the LoRA leaks into every generation, you can't remove it per-image, and a bad weight pollutes everything downstream. Flux Block LoRA Merger is for the other 10% of cases, where you want the LoRA baked in, but you don't want all of it. It merges a LoRA into your UNet while letting you exclude specific transformer blocks from the merge - which is a genuinely hard thing to do cleanly in a node graph, and exactly the kind of fiddly control ComfyUI exists for.

What it actually does

Flux's transformer is built from two families of blocks: double_blocks (the ones that mix text and image attention) and single_blocks. Every Flux LoRA carries per-block weights for these. This node scans the LoRA file's keys, groups them into things like single_blocks_5 or double_blocks_12, and only feeds the blocks you didn't exclude into ComfyUI's load_lora_for_models. The excluded keys never touch the model. Out the other end you get a patched MODEL you can wire straight into a KSampler, or - if you flip the save flags - a fully baked checkpoint file.

It's a small pack with zero extra dependencies: just ComfyUI's own safetensors, torch, and the built-in merging utilities. The author (who also maintains ComfyUI_Layers_Utility) keeps the UI friendly - dropdowns to add/remove block groups, a checkbox per excluded block, and a "Remove All Exclusions" reset button that shows up in the title. There's essentially no community chatter about this node yet (it pulls zero search impressions), so treat it as a niche dev tool: thin docs, real function.

The inputs that matter

• unet_model - your Flux UNet, typically out of a Checkpoint Loader or Unet Loader. The node clones it internally, so your source model isn't mutated.
• lora_path - dropdown of every .safetensors in models/loras. Your LoRA has to live there; the frontend won't populate the block lists until you actually select a file.
• block_prefixes - this is the heart. A multiline field holding lines like block:single_blocks_5. Anything not starting with block: is ignored, so the UI's toggles are really just writing these lines for you. If a workflow loads without the frontend helpers, you can type them by hand.
• weight - LoRA strength, default 1.0. For merging, 0.7–0.9 is a safer bake-in than 1.0, since you can't un-merge later.
• save_model / save_lora with their filename fields - save a full merged checkpoint, or save the filtered LoRA (the allowed blocks as a fresh safetensors). The second one is the sleeper feature: it's how you slim a LoRA down to just the blocks that carry a concept you care about.

Outputs: model (the merged model, wire to KSampler) and merge_report (a string like "Merged N keys, excluded: M", handy for sanity-checking that your exclusions actually took).

Installing it

Via ComfyUI Manager, search "Flux Block LoRA Merger", or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/tritant/ComfyUI_Flux_Block_Lora_Merger

Then restart ComfyUI. No requirements file, no model downloads - it rides entirely on what ComfyUI already ships.

Where people get burned

• The save path has a Windows-ism in it. The code hardcodes os.path.join(os.getcwd(), "ComfyUI\output") with a literal backslash. On Windows that lands in ComfyUI\output as expected; on Linux the backslash is a legal filename character, so you can end up with a directory literally named ComfyUI\output sitting wherever you launched ComfyUI. Check there before hunting through your normal output folder.
• It only understands Flux-style keys. Keys outside lora_unet_ / lora_transformer_ are silently ignored - text-encoder keys don't merge at all. That's by design, but it means the filtered-LoRA output genuinely is UNet-only.
• Baking is forever. Once saved, the LoRA's gone from the equation - no weight slider, no per-image toggle. Keep the original LoRA around if you might want the reversible version later.
• Saving the full model is heavy. A merged 12B Flux checkpoint is multi-gigabyte and eats VRAM to write. The save_lora path is much cheaper and usually what you actually want.

It's niche, it's fiddly, and the docs are thin - but for the "I want this LoRA's style, just not the blocks that overfit the character" workflow, this is the only node doing the job.