ComfyUI Flux LoRA strength_clip Does Nothing: Why Your LoRA Strength Knob Is Half-Broken (and How to Check)

You load a Flux LoRA, wire it into the Load LoRA node, and start dragging the strength_clip slider to tune the effect. Nothing changes. The image is identical from 0.0 to 1.0. You assume the LoRA is broken, delete it, or hunt for a different LoRA of the same character or style.

In most cases the LoRA is fine. The real problem is a misunderstanding of what the two sliders actually control, and a quirk of how Flux LoRAs are usually trained. This article breaks down the “strength_model” vs “strength_clip” split, explains why strength_clip commonly appears to do nothing on Flux, and gives you a concrete way to check a LoRA instead of guessing.

The Two Knobs: strength_model vs strength_clip

A LoRA (Low-Rank Adaptation) is a set of small weight patches applied on top of existing models. In ComfyUI’s Load LoRA node, a single LoRA file can carry patches for two different models at once: the diffusion model (the UNet or, for Flux, the DiT transformer) and the text encoder (the CLIP model).

That is why there are two strengths. The official ComfyUI FAQ puts it plainly:

These separate values control the strength that the LoRA is applied separately to the CLIP model and the main MODEL. In most UIs adjusting the LoRA strength is only one number and setting the lora strength to 0.8 for example is the same as setting both strength_model and strength_clip to 0.8.

• strength_model scales how strongly the patch affects the diffusion model. This is the heavy hitter — it changes how latents get denoised, which is where most of a style or character LoRA lives.
• strength_clip scales how strongly the patch affects the text encoder. It changes how your prompt gets interpreted into conditioning, which usually produces a much subtler effect.

When both parts exist in the LoRA, both sliders should do something. But here is the key insight: a LoRA does not have to contain both. Whether a slider does anything depends entirely on what the person who trained the LoRA actually trained.

Why Flux LoRAs Usually Ignore strength_clip

This is the heart of the confusion. ComfyUI issue #8050 documents exactly this scenario: a user got perfect results with the SDXL Load LoRA node, then switched to Flux with a DualCLIPLoader and found that strength_clip had zero effect on the output.

The answer, from maintainer ltdrdata in that same thread, is that many Flux LoRA models are simply not trained on the CLIP model at all. Flux is a large DiT model with a separate text encoder; when people train a character or style LoRA, they frequently train only the diffusion transformer and leave the text encoder untouched. In that case the LoRA file contains no CLIP patch, and strength_clip scales an empty set of weights — so of course nothing changes.

This is not a bug. It is a property of the specific LoRA file you downloaded. The distinction matters because it flips your intuition: on SD1.5/SDXL it is common to nudge strength_clip and see a visible shift in composition, but on Flux the same action frequently does nothing because there is nothing there to scale.

How to Check Whether a LoRA Trained the Text Encoder

Rather than guessing, you can inspect the LoRA directly. The same GitHub issue points to the LoRA Block Info node from the Impact Pack (ComfyUI-Impact-Pack). It reads the internal keys of a LoRA file and shows you which named modules the patch targets.

The diagnostic step is simple:

1. Install or enable the Inspire Pack (Impact Pack) if you do not already have it.
2. Add a LoRA Block Info node and point it at your LoRA file.
3. Look at the list of block keys it returns.

If the keys point only at diffusion-model layers (for Flux, names like diffusion_model.* or transformer blocks), then the text encoder was not trained, and strength_clip will legitimately do nothing. If you see text_encoder.* or CLIP layer names in the list, then a CLIP patch is present and strength_clip should have an effect — and if it still does not, you can start looking for a real problem.

Common Traps That Mimic a Dead strength_clip

Before you conclude the LoRA is malformed, rule out the surrounding mistakes that can also make the entire LoRA appear inert.

• Base-model mismatch. A Flux LoRA only works on a Flux checkpoint. Loading a Flux LoRA against an SDXL or SD3.5 checkpoint produces garbage or no visible effect, on both strength knobs. Confirm the checkpoint family matches the LoRA.
• Wrong loader node. Older tutorials show a generic Load LoRA node, but Flux workflows often need the LoRA wired into the correct model path after the CLIP loader. If the LoRA node is not actually in the diffusion-model chain, strength_model will also look dead.
• Trigger words. Some LoRAs require an activation token in the prompt. If the token is missing, the LoRA may produce only a faint or zero response regardless of strength. Check the LoRA’s model page on Hugging Face or Civitai for required trigger words.
• Strength set to an extreme. Values far above 1.0 (say 1.5+ on Flux) can blow out the latent and wash the image out, which reads as “the LoRA broke” when it actually worked too hard.

None of these are specific to strength_clip, but all of them are easy to mistake for “this knob does nothing.” Isolate the variable: the only way to know strength_clip specifically is inert is to hold everything else constant and sweep only that one value.

A Reproducible Isolation Test

Set strength_model to a fixed, sensible value (usually 1.0), then render the same prompt at strength_clip = 0.0 and again at 1.0. Keep the seed, sampler, steps, CFG, and checkpoint identical.

• If the two images are pixel-identical: the LoRA has no CLIP patch (or a negligible one), and strength_clip is doing exactly what it should — nothing. This is the expected Flux outcome for many files.
• If the images differ: a CLIP patch exists and is active. Now the knob works, and you can tune it as intended.

This two-render test takes a couple of minutes and removes the ambiguity completely. It is the same principle as the maintainers’ advice in the linked issue — check whether the text encoder was trained before assuming the UI is broken.

When a CLIP Patch Exists But Still Does Nothing

There is a rarer case worth covering: the LoRA does contain text_encoder.* keys, yet strength_clip still appears to have no visible effect. Two explanations are common.

First, the CLIP patch may be visually subtle. Text-encoder patches shift conditioning, which often only nudges composition or style rather than producing an obvious “different image.” A slider that feels dead at a glance may still be changing the embedding vectors; compare the conditioning or inspect outputs at a fine granularity before declaring it inert.

Second, a genuine wiring error can leave the loaded CLIP model disconnected from the LoRA. In Flux workflows that use a DualCLIPLoader (Flux uses two text encoders, CLIP-L and T5), the LoRA must be applied to the correct one. If the patch targets CLIP-L but is applied to a path that never reaches the prompt conditioning, the CLIP weight never takes effect. Trace the model chain and confirm the LoRA output actually reaches the sampler’s conditioning input.

The official guidance is worth repeating: for Flux specifically, the ComfyUI_examples LoRA page shows the correct wiring pattern — the LoRA node patches the model output directly, and applying multiple LoRAs is just a matter of chaining additional Load LoRA nodes.

Conclusion: The Knob Is Not Broken

When a Flux LoRA ignores strength_clip, the overwhelmingly likely explanation is that the file was trained on the diffusion model only, and the text-encoder strength is scaling a patch that does not exist. This is normal, expected, and confirmable in seconds with the LoRA Block Info node or a two-render isolation test.

Save yourself the detour: before replacing a “broken” LoRA, check whether it trained the text encoder at all. Tune strength_model for the character or style you want, leave strength_clip at a sensible default when no CLIP patch is present, and reserve real debugging for the cases where a CLIP patch exists and still fails to move the image.

For the other silent failure that plagues Flux LoRAs — missing trigger words that make an entire LoRA do nothing — see our companion guide on fixing the silent LoRA no-op and missing trigger words.