invoke-ai/InvokeAI · error · ValueError

LoRA "{lora_key}" already applied to T5 encoder.

Error message

LoRA "{lora_key}" already applied to T5 encoder.

What it means

Duplicate-guard for the T5 text encoder component: the loader raises ValueError when the requested LoRA key is already present on self.t5_encoder.loras. This prevents applying the same T5-side LoRA weights twice within one invocation.

Source

Thrown at invokeai/app/invocations/flux_lora_loader.py:76

        default=None,
        title="T5 Encoder",
        description=FieldDescriptions.t5_encoder,
        input=Input.Connection,
    )

    def invoke(self, context: InvocationContext) -> FluxLoRALoaderOutput:
        lora_key = self.lora.key

        if not context.models.exists(lora_key):
            raise ValueError(f"Unknown lora: {lora_key}!")

        # Check for existing LoRAs with the same key.
        if self.transformer and any(lora.lora.key == lora_key for lora in self.transformer.loras):
            raise ValueError(f'LoRA "{lora_key}" already applied to transformer.')
        if self.clip and any(lora.lora.key == lora_key for lora in self.clip.loras):
            raise ValueError(f'LoRA "{lora_key}" already applied to CLIP encoder.')
        if self.t5_encoder and any(lora.lora.key == lora_key for lora in self.t5_encoder.loras):
            raise ValueError(f'LoRA "{lora_key}" already applied to T5 encoder.')

        output = FluxLoRALoaderOutput()

        # Attach LoRA layers to the models.
        if self.transformer is not None:
            output.transformer = self.transformer.model_copy(deep=True)
            output.transformer.loras.append(
                LoRAField(
                    lora=self.lora,
                    weight=self.weight,
                )
            )
        if self.clip is not None:
            output.clip = self.clip.model_copy(deep=True)
            output.clip.loras.append(
                LoRAField(
                    lora=self.lora,
                    weight=self.weight,

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Deduplicate the LoRA application nodes in the workflow
  2. Verify each LoRA loader uses a unique model key
  3. Re-run with a fresh transformer/encoder chain if state carried over from a prior invocation
  4. Audit programmatic graph builders for repeated keys

Example fix

// before: same loader applied twice to T5 path
// after: apply once and reuse the output invocation
t5_out = FluxLoRALoader(lora=lora_key, weight=1.0)
Defensive patterns

Strategy: validation

Validate before calling

t5_keys = [l.lora.key for l in t5_encoder.loras] if t5_encoder else []
assert lora_key not in t5_keys, f"LoRA {lora_key} already on T5"

Type guard

def t5_lora_free(t5_encoder, lora_key: str) -> bool:
    return not t5_encoder or not any(l.lora.key == lora_key for l in t5_encoder.loras)

Try / catch

try:
    output = loader.invoke(context)
except ValueError as e:
    if 'already applied to T5' in str(e):
        output = None  # skip, already loaded on T5
    else:
        raise

Prevention

When it happens

Trigger: invoke() with self.t5_encoder set and an existing lora in self.t5_encoder.loras whose key equals lora_key — the same FLUX LoRA is being applied to the T5 encoder twice in the same graph run.

Common situations: Same LoRA connected to both T5 and another component plus repeated again; generated workflows that loop LoRA application without resetting state.

Related errors


AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/7f3b0a625cad0a64. Report an issue: GitHub.