Nodes/PromptModels Studio/Google AI - Compatibility Checker
ComfyUI Node

Google AI - Compatibility Checker

Will this LoRA work with that checkpoint?

By cdanielp·Created 9 months ago·Updated 2 months ago· 28
Google AI - Compatibility Checker
    • is_compatible
    • compatibility_report
    checkpoint_path
    lora_path
    api_key
    modelgemini-2.5-flash

    "Will this LoRA work with my checkpoint?" is one of the most repeated questions in the whole Stable Diffusion ecosystem, and it's usually answered by trial, error, and a red error message. GoogleAI_CompatibilityChecker tries to answer it before you load anything: point it at a checkpoint file and a LoRA file, and Gemini compares the two models' tensor keys and gives you a yes/no plus a plain-language compatibility report. It's not a guarantee - but it's a lot smarter than guessing.

    What it's for

    Pre-flight checks and mystery-model triage. You've got a checkpoint you barely remember downloading and a LoRA that might or might not match its base. Run the checker and get a boolean is_compatible you can wire into workflow logic, plus a report explaining why: which key families match, which don't, and whether the LoRA looks like it was trained for that architecture at all. It's the diagnostic cousin of the Architecture Detector, focused on pairs rather than single files.

    How it works

    The node extracts metadata and tensor-key information from both files (via safetensors), builds a comparison, and sends it to Gemini with a compatibility-focused system prompt. The model reads the key signatures - LoRA keys embed their target architecture (lora_unet_..., lora_te1_...) - and returns a structured verdict that the node parses into the boolean plus the report string. The honest limits are structural: it's reasoning from key naming conventions, not actually attempting a load. Two files can share key names yet still fail to load for subtler reasons, so treat the boolean as a strong prior, not a contract.

    Inputs and outputs that matter

    • checkpoint_path (STRING) - path to the base model file.
    • lora_path (STRING) - path to the LoRA file.
    • model (COMBO, default gemini-2.5-flash) - flash is fine for this; it's a classification task, not deep reasoning.
    • api_key - resolves from GEMINI_API_KEY or the pack's .env.
    • is_compatible (BOOLEAN) - the machine-readable verdict. Wire it to a switch or just read it.
    • compatibility_report (STRING) - the human-readable reasoning. This is where the value is.

    Installing it

    One of the 15 Google nodes in COMFYUI_PROMPTMODELS (PromptModels Studio in Manager):

    cd ComfyUI/custom_nodes
    git clone https://github.com/cdanielp/COMFYUI_PROMPTMODELS
    

    Add GEMINI_API_KEY=AI... to the pack's .env, restart. Needs ComfyUI 0.26.0+.

    Common issues

    Path errors are the most common failure - both files must exist at the paths you type, and absolute paths are the safe choice. The verdict can be wrong in the awkward cases: LoRAs trained on derivatives, or checkpoints with heavily renamed key blocks, can produce a false "incompatible" or a false "compatible." If you get a "no" you don't believe, load it anyway - the tool is here to save you time, not to replace your judgment. And it's a billed Gemini call, so don't put it in a loop over a folder of a hundred LoRAs.

    CategoryGoogle AI/Diagnostic

    Inputs (4)

    NameTypeDefaultDescription
    checkpoint_pathSTRING
    lora_pathSTRING
    api_keyoptSTRING
    modeloptCOMBOgemini-2.5-flash4 options: gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-2.5-flash, gemini-2.5-pro

    Outputs (2)

    NameTypeDescription
    is_compatibleBOOLEAN
    compatibility_reportSTRING