invoke-ai/InvokeAI · error · TypeError

Expected Main_Checkpoint_Wan_Config, got {type(config).__nam

Error message

Expected Main_Checkpoint_Wan_Config, got {type(config).__name__}.

What it means

The Wan single-file (non-GGUF) checkpoint loader asserts it receives Main_Checkpoint_Wan_Config. Any other config type means the registry routed the model to the wrong loader, so a TypeError naming the actual type is raised.

Source

Thrown at invokeai/backend/model_manager/load/model_loaders/wan.py:484

    This is what CivitAI fine-tunes and ComfyUI-oriented Hugging Face repos ship.
    Handles the full matrix of community conventions: the optional
    ``model.diffusion_model.`` key prefix, the native upstream key layout as well
    as the diffusers one, ComfyUI ``fp8_scaled`` weights (dequantized to the
    compute dtype at load time), and plain ``float8_e4m3fn`` weights with no
    scales (cast the same way as any other non-bf16 dtype).

    Like the GGUF loader, one file is one expert; A14B pairing happens at the
    WanModelLoaderInvocation layer.
    """

    def _load_model(
        self,
        config: AnyModelConfig,
        submodel_type: Optional[SubModelType] = None,
    ) -> AnyModel:
        if not isinstance(config, Main_Checkpoint_Wan_Config):
            raise TypeError(f"Expected Main_Checkpoint_Wan_Config, got {type(config).__name__}.")

        if submodel_type != SubModelType.Transformer:
            raise ValueError(
                "Only the Transformer submodel is available from a single-file Wan checkpoint. "
                "Pair with a standalone Wan VAE and Wan T5 encoder for the other components."
            )

        return self._load_from_singlefile(config)

    def _load_from_singlefile(self, config: Main_Checkpoint_Wan_Config) -> AnyModel:
        import accelerate
        from diffusers import WanTransformer3DModel
        from safetensors.torch import load_file

        from invokeai.backend.util.logging import InvokeAILogger

        logger = InvokeAILogger.get_logger(self.__class__.__name__)

View on GitHub (pinned to 0b6a024f2f)

Solutions

Re-import or correct the model record so a regular single-file Wan checkpoint uses Main_Checkpoint_Wan_Config.
If the file is GGUF-quantized, register it with Main_GGUF_Wan_Config so the GGUF loader handles it.
Upgrade InvokeAI if routing behavior seems inconsistent with your version's model types.

Example fix

// before
config = Main_GGUF_Wan_Config(...)  # routed to regular checkpoint loader

// after
config = Main_Checkpoint_Wan_Config(...)  # or GGUF loader for quantized files

Defensive patterns

Strategy: type-guard

Validate before calling

def is_wan_checkpoint(config) -> bool:
    return type(config).__name__ == 'Main_Checkpoint_Wan_Config'

Type guard

from invokeai.backend.model_manager.config import Main_Checkpoint_Wan_Config

def is_wan_checkpoint_config(config) -> bool:
    return isinstance(config, Main_Checkpoint_Wan_Config)

Try / catch

try:
    model = wan_ckpt_loader.load_model(config, SubModelType.Transformer)
except TypeError as e:
    if 'Expected Main_Checkpoint_Wan_Config' in str(e):
        model = wan_gguf_loader.load_model(config, SubModelType.Transformer)
    else:
        raise

Prevention

Register regular safetensors Wan checkpoints with the checkpoint (non-GGUF) model type.
Let the model manager create model records instead of writing configs by hand.
Re-scan/re-import models after InvokeAI upgrades that change config classes.

When it happens

Trigger: Main_Checkpoint_Wan loader receives a GGUF config, a diffusers-style Wan config, or another checkpoint config subclass — typically from a model record whose format/type fields don't match the loader the registry selected.

Common situations: Selecting the wrong model type/format during import; hand-edited model records; registry/config class changes across InvokeAI versions.

Related errors

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