invoke-ai/InvokeAI · info · NotAMatchError
model is a FLUX.2 model, not FLUX.1
Error message
model is a FLUX.2 model, not FLUX.1
What it means
After confirming the state dict is a FLUX checkpoint, _validate_is_flux explicitly excludes FLUX.2 models (detected via _is_flux2_model) because FLUX.2 has its own config class. Encountering this error means the file is a FLUX.2 checkpoint being matched against the FLUX.1 config; the probe will (or should) fall through to the FLUX.2 config class.
Source
Thrown at invokeai/backend/model_manager/configs/main.py:658
variant = override_fields.pop("variant", None) or cls._get_variant_or_raise(mod)
return cls(**override_fields, variant=variant)
@classmethod
def _validate_is_flux(cls, mod: ModelOnDisk) -> None:
state_dict = mod.load_state_dict()
if not state_dict_has_any_keys_exact(
state_dict,
{
"double_blocks.0.img_attn.norm.key_norm.scale",
"model.diffusion_model.double_blocks.0.img_attn.norm.key_norm.scale",
},
):
raise NotAMatchError("state dict does not look like a FLUX checkpoint")
# Exclude FLUX.2 models - they have their own config class
if _is_flux2_model(state_dict):
raise NotAMatchError("model is a FLUX.2 model, not FLUX.1")
@classmethod
def _get_variant_or_raise(cls, mod: ModelOnDisk) -> FluxVariantType:
# FLUX Model variant types are distinguished by input channels and the presence of certain keys.
state_dict = mod.load_state_dict()
variant = _get_flux_variant(state_dict)
if variant is None:
# TODO(psyche): Should we have a graceful fallback here? Previously we fell back to the "normal" variant,
# but this variant is no longer used for FLUX models. If we get here, but the model is definitely a FLUX
# model, we should figure out a good fallback value.
raise NotAMatchError("unable to determine model variant from state dict")
return variant
@classmethod
def _validate_looks_like_main_model(cls, mod: ModelOnDisk) -> None:
has_main_model_keys = _has_main_keys(mod.load_state_dict())View on GitHub (pinned to 0b6a024f2f)
Solutions
- Upgrade InvokeAI to a version with FLUX.2 support (LoRA_Diffusers_Flux2_Config / FLUX.2 main config) so the probe chain accepts the model.
- If you intended FLUX.1, re-download the correct FLUX.1 checkpoint.
- Check _is_flux2_model signatures in the state dict to confirm which generation the file is.
- If stuck on an old version, manually categorize the model or convert it, but upgrading is the proper fix.
Example fix
// before: old InvokeAI, FLUX.2 file -> 'model is a FLUX.2 model, not FLUX.1' // after: upgrade pip install -U invokeai # then rescan; FLUX.2 configs handle the model
Defensive patterns
Strategy: try-catch
Type guard
def is_flux2_model(sd: dict) -> bool:
from invokeai.backend.model_manager.configs.main import _is_flux2_model
return _is_flux2_model(sd) Try / catch
try:
cfg = probe_model(path)
except NotAMatchError as e:
if 'FLUX.2' in str(e):
print('FLUX.2 checkpoint detected — requires InvokeAI with FLUX.2 support') Prevention
- Upgrade InvokeAI before importing FLUX.2 models
- Label model downloads by generation (FLUX.1 vs FLUX.2)
- Confirm generation via state-dict signatures before import
When it happens
Trigger: from_model_on_disk on a FLUX.2 (Klein) checkpoint whose keys satisfy FLUX-style signatures but fail _is_flux2_model exclusion in the FLUX.1 config.
Common situations: Importing new FLUX.2 releases into an older InvokeAI where the FLUX.2 config class does not exist, so the probe ends at this error; ambiguous model files; documentation/version confusion between FLUX.1 and FLUX.2 downloads.
Related errors
- LoRA '{lora_config.name}' is a {lora_variant.value} LoRA and
- LoRA '{lora.lora.key}' is for {lora.lora.base.value if lora.
- FLUX.2 [dev] loader requires a FLUX.2 [dev] transformer, but
- No VAE source provided. Single-file / GGUF transformers requ
- No Mistral encoder source provided. Single-file / GGUF trans
AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29).
Data as JSON: /api/errors/06437aa84a7c8cc8.
Report an issue: GitHub.