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

  1. Upgrade InvokeAI to a version with FLUX.2 support (LoRA_Diffusers_Flux2_Config / FLUX.2 main config) so the probe chain accepts the model.
  2. If you intended FLUX.1, re-download the correct FLUX.1 checkpoint.
  3. Check _is_flux2_model signatures in the state dict to confirm which generation the file is.
  4. 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

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


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