invoke-ai/InvokeAI · error · ValueError

LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.

Error message

LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.lora.base else 'unknown'} models, not Z-Image models. Ensure you are using a Z-Image compatible LoRA.

What it means

Each collected LoRA must declare BaseModelType.ZImage as its base; anything else (Flux, SDXL, etc.) cannot patch the Z-Image transformer and raises a ValueError naming the LoRA's actual base. The message interpolates lora.lora.base.value, or 'unknown' when base is None (common for record keys that cannot be resolved).

Source

Thrown at invokeai/app/invocations/z_image_lora_loader.py:156

        added_loras: list[str] = []

        if self.transformer is not None:
            output.transformer = self.transformer.model_copy(deep=True)

        if self.qwen3_encoder is not None:
            output.qwen3_encoder = self.qwen3_encoder.model_copy(deep=True)

        for lora in loras:
            if lora is None:
                continue
            if lora.lora.key in added_loras:
                continue

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

            if lora.lora.base is not BaseModelType.ZImage:
                raise ValueError(
                    f"LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.lora.base else 'unknown'} models, "
                    "not Z-Image models. Ensure you are using a Z-Image compatible LoRA."
                )

            # Warn on variant mismatch between LoRA and transformer.
            lora_config = context.models.get_config(lora.lora.key)
            lora_variant = getattr(lora_config, "variant", None)
            if lora_variant and self.transformer is not None:
                transformer_config = context.models.get_config(self.transformer.transformer.key)
                transformer_variant = getattr(transformer_config, "variant", None)
                if transformer_variant and lora_variant != transformer_variant:
                    context.logger.warning(
                        f"LoRA variant mismatch: LoRA '{lora_config.name}' is for {lora_variant.value} "
                        f"but transformer is {transformer_variant.value}. This may cause unexpected results."
                    )

            added_loras.append(lora.lora.key)

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Use only LoRAs trained for Z-Image (base = z_image) in this graph; remove Flux/SDXL LoRAs from the loader chain.
  2. Fix the base model metadata of the LoRA in the Model Manager if it is actually a Z-Image LoRA.
  3. If base shows 'unknown', reinstall the LoRA so a valid model record with base ZImage is created.
  4. Find an equivalent Z-Image LoRA or retrain/convert the LoRA for Z-Image.

Example fix

// before
lora.lora.base == BaseModelType.Flux  # Flux LoRA on Z-Image graph
// after
use lora with lora.lora.base == BaseModelType.ZImage
Defensive patterns

Strategy: validation

Validate before calling

for l in attached_loras:
    cfg = context.models.get_config(l.lora.key)
    if cfg.base != BaseModelType.ZImage:
        raise ValueError(f"LoRA {cfg.name} has base {cfg.base}; only z_image LoRAs work on Z-Image models")

Type guard

def is_zimage_lora(cfg) -> bool:
    return getattr(cfg, 'base', None) == BaseModelType.ZImage

Try / catch

try:
    out = z_image_lora_loader.invoke(context)
except ValueError as e:
    if "not Z-Image models" in str(e):
        context.logger.error(f"{e} - swap in a base=z_image LoRA.")
    else:
        raise

Prevention

When it happens

Trigger: A LoRA entry in transformer.loras or qwen3_encoder.loras has lora.lora.base different from BaseModelType.ZImage (or None) during loader invoke().

Common situations: Attaching a Flux or SDXL LoRA to a Z-Image graph; Model Manager metadata wrong so a Z-Image LoRA is registered under another base; key parsing yielding base=None for corrupted records; auto-loading a whole folder of mixed-family LoRAs.

Related errors


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