SD Base Version Number

Building an API that accepts "any checkpoint the user wants" sounds simple until you realize your defaults - resolution, CFG, sampler - need to be different for an SD1.5 model than an SDXL one, and different again for Flux. SDBaseVerNumber answers the question for you: feed it a loaded MODEL and it reports back, as a set of booleans, which architecture family you're actually holding.

How it works

It's an architecture fingerprint - the node inspects the loaded model and reports which family it matches. The pack's own one-line README description undersells this a little ("is it 1.5 or XL"), but the actual outputs cover five families: sd1.5, sdxl, aura (AuraFlow), flux, and hunyuan (Hunyuan DiT). Exactly one should read true for a normal checkpoint.

The inputs and outputs that matter

• model (MODEL) - the loaded checkpoint to inspect.
• Five boolean outputs: sd1.5, sdxl, aura, flux, hunyuan.

Feed the model in once near the top of your graph, then route on whichever boolean comes back true - into a switch or logic node elsewhere in your setup - to pick the right default resolution, sampler, or CFG range for that specific architecture, instead of hardcoding one set of defaults and hoping every checkpoint someone loads happens to match it.

How to install it

Via ComfyUI Manager: search comfyui-easyapi-nodes, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/lldacing/comfyui-easyapi-nodes.git
cd comfyui-easyapi-nodes
pip install -r requirements.txt

Restart ComfyUI. No models needed to install the node itself - obviously you still need whatever checkpoint you're actually inspecting.

Common issues & troubleshooting

The fixed five-family list doesn't know about anything newer. Load a model from an architecture outside this list and, since there's no "other" output, expect every single boolean to come back false rather than getting an error. That's easy to misread as "the node is broken" rather than "this checkpoint isn't one of the five families it recognizes" - worth a quick sanity test with a known SD1.5 or SDXL checkpoint first if the outputs look off.

Two outputs coming back true at once (or none doing so) for a model that should clearly be one of the five isn't expected behavior for a normal checkpoint and is worth treating as a real bug report rather than something to work around.

This is a UNET-level check, not a check of your whole pipeline. It looks at the MODEL you feed it, not at whatever VAE or CLIP/text-encoder you've paired it with. Mismatched components (an SDXL UNET wired to the wrong text encoder, say) won't show up here at all - this node only ever answers "which base architecture is this diffusion model," nothing about whether the rest of your loaders actually match it.