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
- Use only LoRAs trained for Z-Image (base = z_image) in this graph; remove Flux/SDXL LoRAs from the loader chain.
- Fix the base model metadata of the LoRA in the Model Manager if it is actually a Z-Image LoRA.
- If base shows 'unknown', reinstall the LoRA so a valid model record with base ZImage is created.
- 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
- Filter the LoRA picker by base model 'z-image' before attaching.
- Fix misregistered base metadata in the Model Manager.
- Keep LoRAs for different families in separate folders to avoid mixing.
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
- LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
- LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
- LoRA '{lora_key}' is for {stored_config.base.value if stored
- LoRA '{lora.lora.key}' is for {stored_config.base.value if s
- Unknown lora: {lora_key}!
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/afefad58fd810ecd.
Report an issue: GitHub.