What causes "Unknown lora: {lora_key}!" in invoke-ai/InvokeAI?

Re-select the LoRA in the LoRA loader node so the node picks up the current valid key.

invoke-ai/InvokeAI · error · ValueError

Unknown lora: {lora_key}!

Error message

Unknown lora: {lora_key}!

What it means

FluxLoRALoader.invoke looks up the LoRA by its model key via context.models.exists. If no model record with that key exists in the model manager, this ValueError is thrown, guarding the subsequent load and duplicate checks.

Source

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

    )
    clip: CLIPField | None = InputField(
        default=None,
        title="CLIP",
        description=FieldDescriptions.clip,
        input=Input.Connection,
    )
    t5_encoder: T5EncoderField | None = InputField(
        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,

View on GitHub (pinned to 0b6a024f2f)

Solutions

Re-select the LoRA in the LoRA loader node so the node picks up the current valid key.
Reinstall/re-import the LoRA file via the Model Manager so its key exists in the database.
If migrating workflows, replace the stale lora.key with the key from the destination installation's model list.

Example fix

// before: workflow references deleted key
lora_key = "stale-key-from-old-install"
// after: rebind via UI or lookup
lora_key = next(m.key for m in context.models.search_by_attrs(name="my_lora.safetensors")).key

Defensive patterns

Strategy: try-catch

Validate before calling

if not context.models.exists(self.lora.key):
    raise ValueError(f"LoRA {self.lora.key} missing from model manager; re-select it in the loader node")

Type guard

def lora_exists(context, key: str) -> bool:
    return context.models.exists(key)

Try / catch

try:
    output = lora_loader.invoke(context)
except ValueError as e:
    if str(e).startswith("Unknown lora"):
        log.error("LoRA not found: %s - re-import the model or rebind the key", lora_key)
    else:
        raise

Prevention

Re-select LoRAs in loader nodes after installing InvokeAI on a new machine.
Avoid deleting models referenced by saved workflows, or update the workflows afterwards.
Resolve model keys dynamically via the Model Manager API instead of hardcoding keys in scripts.

When it happens

Trigger: The LoRA model was deleted or uninstalled after the workflow was saved; the key in the graph points to a different InvokeAI installation/database; a stale workflow JSON references a removed model.

Common situations: Sharing workflow JSONs between machines where LoRA keys (hash-based) differ; models removed via the Model Manager UI while workflows still reference them; switching model-manager databases.

Related errors

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