FLUX Model Layer Editor

What it is

This one's easy to confuse with this pack's LoRA-focused Selective Loaders, so the distinction up front: those edit a LoRA's per-block contribution. This node edits the base checkpoint itself - scaling FLUX's own transformer blocks up or down before any LoRA gets applied on top. It's a different lever entirely. If a base FLUX checkpoint has a bias baked into certain layers - too much saturation, a stubborn style tendency, a block that's overcorrecting something - this is where you'd go to dial that block down at the source, rather than fighting it downstream with prompting or a corrective LoRA.

This is genuinely unusual territory; nothing in the wider community's LoRA and model-editing writeups documents base-model block scaling as a mainstream technique the way LoRA training or block-level LoRA loading are. Treat it as a power-user tool for a specific problem (a checkpoint that's almost right except for one identifiable region) rather than a routine step in your workflow.

How it works

FLUX's transformer splits into 19 "double" blocks (the ones processing image and text streams jointly, generally higher-impact) and 38 "single" blocks (downstream, generally lower-impact) - the same split this pack's FLUX Selective Loader works with, applied here to the checkpoint's own weights instead of a LoRA's. You get an on/off toggle and a strength multiplier for each of the 57 blocks, applied to the base model before anything else touches it. The pack ships a related, more surgical tool - a Deep Debiaser suite that goes down to individual attention heads and MLPs within a block rather than whole blocks - and one community post used exactly that finer-grained tool on Klein to fix detail preservation by scaling a single problem sub-block down to 0.75. This node operates one level up from that: whole blocks, not sub-components, but the same underlying idea of surgically dialing down a specific region of the model rather than the whole thing.

Inputs and outputs that matter

• model - the base checkpoint you're editing.
• preset - Default (everything at 1.0), All Off, Half Strength, Double Only, Single Only, or Custom.
• double_0–double_18 and single_0–single_37, each paired with a _str slider (range -2 to 2, tighter than the LoRA loaders' -5 to 5, since you're scaling the base model rather than a small adapter).
• other / other_str - anything outside the 57 mapped blocks.
• Optional save_preset_name / delete_preset_name - save your own block configuration for reuse, or remove one you saved earlier.
• Optional save_model, save_path, save_filename, source_model_path - bake the edited checkpoint to disk as a new safetensors file instead of applying it live every run.

Outputs: model (the edited checkpoint, apply LoRAs on top of this as normal), analysis and analysis_json - a report of what got scaled.

Installing it

No external training backend needed - this node works the moment the pack is installed. ComfyUI Manager (search "Realtime LoRA Trainer") or:

cd ComfyUI/custom_nodes
git clone https://github.com/ShootTheSound/comfyUI-Realtime-Lora

Restart ComfyUI. The pack's workflows/Lora Analysis, Block and Model Editing/ folder includes a Model Layer Editor demo (built against Z-Image, but the same node exists per-architecture - search for "FLUX Model Layer Editor" specifically).

Common issues

Setting a block to 0 produces noise or garbage output. This is expected, not a bug - completely zeroing a transformer block removes structure the rest of the network depends on. Stick to the 0.5–1.5 range for meaningful adjustments; treat 0 as a diagnostic extreme, not a usable setting.

Not sure which block is responsible for a problem. There's no automated attribution here the way the LoRA analyzer gives you impact scores - this node is closer to a scalpel than a diagnostic tool, so expect to experiment iteratively rather than have the node point you at the culprit.

Edited model behaves inconsistently across different LoRAs. That's the nature of editing the base rather than a LoRA - every LoRA you apply afterward interacts with your edited blocks differently. If you're chasing a fix for one specific LoRA's interaction with the base model, it may be more direct to adjust that LoRA's own block strengths instead of the base checkpoint.

Forgot the _str range is narrower here than the LoRA loaders. -2 to 2, not -5 to 5 - a "5" typed by muscle memory from a Selective Loader will get clamped or rejected.