invoke-ai/InvokeAI · warning · NotAMatchError

model looks like Control LoRA

Error message

model looks like Control LoRA

What it means

`_validate_looks_like_lora` first rules out ControlLoRA weights: if `_get_flux_lora_format` identifies the file as `FluxLoRAFormat.Control`, the file is a Control LoRA, not a regular LoRA, and this config class raises `NotAMatchError`. Control LoRAs need to be imported as ControlNet-style models rather than standard LoRAs.

Source

Thrown at invokeai/backend/model_manager/configs/lora.py:599

        cls._validate_base(mod)

        return cls(**override_fields)

    @classmethod
    def _validate_base(cls, mod: ModelOnDisk) -> None:
        """Raise `NotAMatch` if the model base does not match this config class."""
        expected_base = cls.model_fields["base"].default
        recognized_base = cls._get_base_or_raise(mod)
        if expected_base is not recognized_base:
            raise NotAMatchError(f"base is {recognized_base}, not {expected_base}")

    @classmethod
    def _validate_looks_like_lora(cls, mod: ModelOnDisk) -> None:
        # First rule out ControlLoRA
        flux_format = _get_flux_lora_format(mod)
        if flux_format in [FluxLoRAFormat.Control]:
            raise NotAMatchError("model looks like Control LoRA")

        # If it's a recognized Flux LoRA format (Kohya, Diffusers, OneTrainer, AIToolkit, XLabs, etc.),
        # it's valid and we skip the heuristic check
        if flux_format is not None:
            return

        # Note: Existence of these key prefixes/suffixes does not guarantee that this is a LoRA.
        # Some main models have these keys, likely due to the creator merging in a LoRA.
        has_key_with_lora_prefix = state_dict_has_any_keys_starting_with(
            mod.load_state_dict(),
            {
                "lora_te_",
                "lora_unet_",
                "lora_te1_",
                "lora_te2_",
                "lora_transformer_",
            },
        )

View on GitHub (pinned to 0b6a024f2f)

Solutions

1. Import the model as a Control LoRA / ControlNet-style model rather than a standard LoRA
2. Check the model's documentation/repo to confirm its type before import
3. If it is genuinely a normal LoRA, re-export it with a non-Control key format (Kohya/diffusers)
4. Upgrade InvokeAI if support for Control LoRA as a distinct model type is needed

from invokeai.backend.model_manager.configs.lora import _get_flux_lora_format
from invokeai.backend.model_manager.metadata import FluxLoRAFormat
fmt = _get_flux_lora_format(mod)
if fmt == FluxLoRAFormat.Control:
    print("import as Control LoRA, not standard LoRA")

def is_control_lora(mod) -> bool:
    from invokeai.backend.model_manager.metadata import FluxLoRAFormat
    return _get_flux_lora_format(mod) == FluxLoRAFormat.Control

try:
    cfg = LoRAFluxConfig.from_model_on_disk(mod)
except NotAMatchError as e:
    if "Control LoRA" in str(e):
        import_as_controlnet(mod)

When it happens

Trigger: `from_model_on_disk` probing a Flux LoRA file whose key structure matches the Control LoRA format (e.g. keys like `lora_controlnet...` / control-specific patterns recognized by `_get_flux_lora_format`).

Common situations: Autoimporting a folder that contains Flux Control LoRA weights; downloading a 'lora' from a model hub that is actually a ControlLoRA; expecting control-style conditioning to work via the LoRA pipeline.

Related errors

• Control LoRAs cannot be used with FLUX Schnell
• Unknown lora: {lora_key}!
• LoRA "{lora_key}" already applied to transformer.
• LoRA "{lora_key}" already applied to CLIP encoder.
• LoRA "{lora_key}" already applied to T5 encoder.

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