Advanced V-Prediction Checker

V-prediction models are the ones that finally do dark night scenes instead of medium-gray everything - NoobAI vpred made that mainstream, and it's also the reason the same workflow can silently break when you swap checkpoints. Epsilon models want CFG 5–7; vpred burns there and wants CFG++ at 1.5–2.0 or a RescaleCFG node. So when a workflow needs to behave differently depending on which model you've loaded, you need a node that asks "is this thing vpred?" and returns a clean yes/no.

That's all the Advanced V-Prediction Checker does, and it does it in about fifty lines. You feed it the MODEL object straight from your loader, it reads model.model.model_type - the exact ModelType enum ComfyUI assigned when it loaded the checkpoint - and hands back a BOOLEAN (is_match) plus a STRING (model_type) telling you the name it actually saw.

The source handles a subtle ComfyUI wrinkle: some model types are computed lazily as a callable rather than a plain enum, so the node resolves that first, falling back to reading the state dict if needed. Then it checks the result against the three v-prediction flavors ComfyUI distinguishes: V_PREDICTION, V_PREDICTION_EDM, and V_PREDICTION_CONTINUOUS. For the SDXL anime checkpoints everyone actually cares about, the one you'll see is plain V_PREDICTION.

The inputs that matter

Only three, all required, and you'll mostly touch two of them:

• model - wire in whatever MODEL output your Checkpoint Loader (or Unet Loader, or diffusers loader) produced.
• check_mode - any_vpred (default) returns true for any of the three vpred flavors; specific_type makes it compare against exactly one.
• specific_type - only read when check_mode is specific_type. The default V_PREDICTION is the right pick for NoobAI/Illustrious vpred. Ignore this unless you know you need the narrower test.

What you do with it

The whole point is logical switching, and the README is explicit: use it with an if/else-style node. The boring-but-effective pattern: is_match feeds the condition of a boolean gate or switch, and the branch turns a RescaleCFG node on (or reroutes the sampler) only when vpred is detected. That's how you keep one workflow that runs both noobaiXLVpred and a plain eps model without babysitting it every time you swap checkpoints.

The second output is the underrated half. model_type is a diagnosis in string form: if you're certain a model is vpred but it reports EPS (or EPSON), ComfyUI didn't classify it that way - which is exactly the "static, no error" failure the v-prediction panel warns about. You can wire it into a text display or just read it in the node.

Installing it

No dependencies, no model downloads, no requirements.txt - it only imports comfy.model_base and ships pure-Python. Via ComfyUI Manager, search "ComfyUI_CheckVprediction" and hit Install. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Windecay/ComfyUI_CheckVprediction

Restart ComfyUI. It shows up under custom/model_check as "Advanced V-Prediction Checker."

Troubleshooting

Keep expectations honest: this node reports, it doesn't change. If is_match is true but you didn't actually branch your CFG handling, you get the same washed-out vpred-at-high-CFG output as before. It also only knows what ComfyUI's loader decided - if a checkpoint was mislabeled or loaded through a path that didn't flag it, the checker faithfully reports that wrong answer.

One genuinely useful detail from the code: the lazy model_type handling exists because ComfyUI computes some types on demand from the state dict. If a model reports unexpectedly, double-check it through the loader before blaming the node. Tiny niche pack, single commit, from the same author as the LTX low-VRAM ComfyUI-ReservedVRAM node - the kind of small utility people install for one workflow and quietly keep.