LoRA Not Loading in ComfyUI Flux (Fix)

A LoRA that has no effect is harder to diagnose than one that crashes ComfyUI - the generation completes without error, but the LoRA simply does not do anything. This guide covers the six most common causes, a compatibility table for Flux LoRA types, and a fix checklist to work through systematically.

How ComfyUI Loads LoRAs

ComfyUI loads LoRA files using the LoraLoader node, which patches the model weights in memory before sampling begins. If the LoRA is not compatible with the loaded model, the patch either fails silently (no effect) or causes an error. The silent failure case is more common and harder to debug because the generation succeeds but ignores the LoRA entirely.

Flux LoRAs must be trained specifically for Flux. A LoRA trained on SDXL, SD 1.5, or SD 2.1 is architecturally incompatible with Flux - the weight shapes do not match. Attempting to load it will either produce no effect or cause a shape mismatch error.

Fix 1: Verify LoRA Location

The LoRA file must be in the correct subdirectory for ComfyUI to find it. ComfyUI scans specific directories for each model type. If the file is in the wrong location, it will not appear in the LoRA dropdown or will throw a "model not found" error.

# Correct location for LoRA files
ComfyUI/models/loras/your-lora.safetensors

# Not in subdirectories by default (unless you configure extra paths)
# Wrong: ComfyUI/models/loras/flux/your-lora.safetensors
# Wrong: ComfyUI/models/checkpoints/your-lora.safetensors

# Verify your LoRA is in the right place
ls ComfyUI/models/loras/

# If you want subdirectories, add them to extra_model_paths.yaml
cat ComfyUI/extra_model_paths.yaml

If you use subdirectories and ComfyUI is not finding them, add the path to extra_model_paths.yaml:

comfyui:
  loras: |
    ComfyUI/models/loras/
    /path/to/additional/loras/

Fix 2: Confirm the LoRA Was Trained for Flux

The most common cause of a LoRA having no effect: it was trained on a different base model. Verify the LoRA architecture before loading it.

# Check which base model a LoRA was trained on
python3 -c "
from safetensors import safe_open
import sys

with safe_open(sys.argv[1], framework='pt') as f:
    keys = list(f.keys())
    print('Total keys:', len(keys))
    # Flux LoRAs contain transformer_blocks keys
    # SDXL LoRAs contain unet keys
    # SD1.5 LoRAs contain model.diffusion_model keys
    flux_keys = [k for k in keys if 'transformer_blocks' in k or 'double_stream' in k]
    sdxl_keys = [k for k in keys if 'input_blocks' in k or 'unet' in k.lower()]
    print('Flux-style keys:', len(flux_keys))
    print('SDXL-style keys:', len(sdxl_keys))
    if flux_keys:
        print('Likely: Flux LoRA')
    elif sdxl_keys:
        print('Likely: SDXL LoRA (not compatible with Flux)')
    else:
        print('Unknown architecture - check first 5 keys:')
        for k in keys[:5]:
            print(' ', k)
" ComfyUI/models/loras/your-lora.safetensors

Fix 3: Set Correct LoRA Strength

Flux LoRAs typically work at lower strength values than SD 1.5 or SDXL LoRAs. Setting strength too high (above 1.0) with a Flux LoRA often produces distortion, burnt-out images, or complete garbage output. Setting it too low (below 0.1) produces no visible effect.

Recommended starting values for Flux LoRAs:

• Style LoRAs (artistic style transfer): start at 0.6, adjust between 0.3-0.9
• Character LoRAs (face/person likeness): start at 0.7, adjust between 0.4-1.0
• Concept LoRAs (objects, textures): start at 0.5, adjust between 0.2-0.8
• FLUX-specific trigger LoRAs: check the model card, some work at 1.0 exclusively

The LoraLoader node in ComfyUI has two strength sliders: model strength and clip strength. For Flux, set both to the same value. Some guides suggest setting clip strength to 0 or 1 independent of model strength - for Flux, this produces inconsistent results. Keep them matched unless the LoRA documentation specifies otherwise.

Fix 4: Use the Correct CLIP Model

Flux uses a dual CLIP encoder (CLIP-L and T5-XXL). If you load a LoRA trained with T5-XXL but your workflow only uses CLIP-L (because you used a DualCLIPLoader with the wrong configuration), text conditioning from the LoRA trigger words will not work even if the visual style is applied.

{
  "dual_clip_loader": {
    "class_type": "DualCLIPLoader",
    "inputs": {
      "clip_name1": "clip_l.safetensors",
      "clip_name2": "t5xxl_fp16.safetensors",
      "type": "flux"
    }
  }
}

The type field must be "flux" - using "sdxl" or "sd3" will load the models but wire them in the wrong order, causing CLIP conditioning to be ignored or misapplied. This is a silent failure: the workflow completes but the text encoder is not contributing correctly to the conditioning.

Fix 5: Clear Stale Cache

ComfyUI caches loaded models in VRAM to speed up sequential generations. If you swapped a LoRA file on disk without restarting ComfyUI, the old version may still be cached in memory. The new file on disk is not used until the cache is cleared.

To clear the model cache without restarting: in ComfyUI Manager, click "Free Model Memory" (this clears the VRAM cache without a full restart). Alternatively, restart ComfyUI completely - the model cache is always cleared on startup.

# If ComfyUI Manager is available:
# Manager -> "Free Model Memory" button clears the cache

# Or restart ComfyUI:
# Stop the process (CTRL+C), then:
python main.py --listen

Fix 6: Verify the LoRA File Is Not Corrupt

A corrupt LoRA file may load without error but apply incorrect or empty weight patches, resulting in no effect. Verify the file integrity before assuming the issue is configuration.

# Quick integrity check
python3 -c "
from safetensors import safe_open
import sys
try:
    with safe_open(sys.argv[1], framework='pt') as f:
        keys = list(f.keys())
        # Try actually reading a tensor (not just metadata)
        first_key = keys[0]
        tensor = f.get_tensor(first_key)
        print(f'OK: {len(keys)} keys, first tensor shape: {tensor.shape}')
except Exception as e:
    print(f'CORRUPT: {e}')
" ComfyUI/models/loras/your-lora.safetensors

Correct Workflow Structure for Flux + LoRA

The LoraLoader node must be placed between the checkpoint loader and the conditioning nodes, not after the sampler. A common mistake is connecting the LoRA to the wrong input or output port.

{
  "checkpoint_loader": {
    "class_type": "CheckpointLoaderSimple",
    "inputs": { "ckpt_name": "flux1-dev-fp8.safetensors" }
  },
  "lora_loader": {
    "class_type": "LoraLoader",
    "inputs": {
      "model": ["checkpoint_loader", 0],
      "clip": ["checkpoint_loader", 1],
      "lora_name": "your-flux-lora.safetensors",
      "strength_model": 0.7,
      "strength_clip": 0.7
    }
  },
  "clip_encode": {
    "class_type": "CLIPTextEncode",
    "inputs": {
      "clip": ["lora_loader", 1],
      "text": "your trigger word, your prompt"
    }
  },
  "ksampler": {
    "class_type": "KSampler",
    "inputs": {
      "model": ["lora_loader", 0]
    }
  }
}

Note that the model output from LoraLoader (index 0) goes to KSampler, and the clip output (index 1) goes to CLIPTextEncode. Both outputs must be used. If you only connect the model output and use the original CLIP from the checkpoint loader, the LoRA trigger words in your prompt will have no effect.