Checkpoint Info Viewer v074

Every checkpoint in your folder looks the same from the outside - a 7 GB blob with a hopeful filename. Checkpoint Info Viewer v074 is the "read the library card" node for that blob: give it a path and it tells you the architecture, whether a VAE and CLIP are embedded, the clip type, category, notes, preferences, and the generation params that were recorded for it. It's the read side of the checkpoint catalog that the AAA Metadata System pack maintains.

It sits in the "loaders/checkpoint tester" family alongside the setter and the batch setter, and it's the lowest-effort node in that family to use. No dropdowns to fill, no scanning a whole directory - one path in, ten useful outputs out. If you inherited someone else's model folder and want to know what you're dealing with before you run anything, this is your first stop.

How it works

The node hashes the checkpoint file and looks up its record in the pack's JSON database (checkpoint_tester_db.json), the same store the info setter writes to. It also inspects the file to fill in model_type - that's the node's way of classifying what kind of file it is based on where it lives (checkpoint vs. unet vs. diffusion model vs. GGUF), which is genuinely useful now that "model" can mean several different things. Everything it returns is already in the database or cheaply derived from the path, so it's fast and safe: reading a header doesn't load a model into VRAM.

Inputs and outputs that matter

One required input: checkpoint_path, a plain string with the absolute path. Type it, paste it, done.

Outputs:

• model_name, architecture, model_type - what it's called, what it is, and what kind of file it is.
• has_vae, has_clip, clip_type - whether the file embeds a VAE and CLIP and how the CLIP is structured. Useful before you wire it into a loader that might double-load a VAE.
• category, notes - whatever a human (or a setter) recorded.
• preferences - the stored VAE/CLIP/device/T5 preferences.
• generation_params - the sampler/scheduler/steps/cfg defaults saved for this model, if any.

The wiring pattern that works well: run this first, read architecture and clip_type, then decide whether you need CheckpointInfoSetter_v074 to fix the record or CheckpointTester_v074 to actually load it.

Installing it

Part of AAA Metadata System by Eric Hiss (GitHub: EricRollei). Use ComfyUI Manager (search "AAA Metadata System") or:

cd ComfyUI/custom_nodes
git clone https://github.com/EricRollei/AAA_Metadata_System.git
cd AAA_Metadata_System
pip install -r requirements.txt

Restart ComfyUI. No models, no API keys - this node is all local bookkeeping.

Common issues

If a checkpoint you know exists comes back with empty or default-looking fields, it just hasn't been catalogued yet - the viewer can't invent an entry. Run the tester or the info setter over it once and re-query. If model_type looks wrong, it's path-based: the node classifies by which ComfyUI folder the file sits in, so a model that lives in the wrong folder gets labeled wrong. And since the data lives in a JSON file the pack owns, treat that file as part of your setup - if you move a model, the record follows via the file hash, but if you wipe the pack folder, the catalog goes with it.