Get Checkpoint Metadata & Keys

A safetensors file isn't just a blob of numbers - it opens with a JSON header describing what's inside (metadata, sometimes training provenance, sometimes nothing) followed by every tensor's name and shape. Most of the time you never see any of that; you point a checkpoint loader at the file and ComfyUI just works. This node is for the moment you need to actually look - before you rename keys, before you prune layers, before you merge two checkpoints and get a shape-mismatch error you don't understand.

What it does

One input: ckpt_name, a dropdown of whatever's in your checkpoints folder. Two outputs, both plain strings: metadata (whatever's in the file's JSON header - this varies wildly by checkpoint; some carry nothing useful, some carry the tool and settings used to produce the file) and keys (the full list of tensor names inside - every layer, by its exact internal name).

That's the entire node, and that's the point. It doesn't transform anything, it just exposes what's already in the file so you can read it - feed the outputs into a Show Text node or similar to actually see them in the UI.

Why you'd reach for it

This is the diagnostic step before every other node in this pack's Keys/Merging family actually makes sense. CheckpointPruneKeys needs you to type exact key names into keys_to_prune - you get those names from here. A checkpoint merge failing with a shape mismatch on some tensor is a lot easier to debug once you can see both files' key lists side by side and spot which layer diverges. And plenty of checkpoints on CivitAI and elsewhere carry genuinely useful metadata in that header - base model, sometimes even training notes - that the checkpoint loader you normally use never surfaces to you.

Installing it

ComfyUI Manager: search Model Utility Toolkit, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils

Restart ComfyUI. No downloads needed - it reads a file you already have.

Where people get burned

The most common surprise is an empty or near-empty metadata output. Not every checkpoint's author bothers to write anything into the safetensors header - plenty of merges and casual fine-tunes ship with nothing but the tensors themselves, so don't assume a blank result means the node is broken. It usually means the file genuinely doesn't carry provenance information.

The other one is scale: a large checkpoint can have thousands of individual tensor keys, and dumping that straight into a Show Text node produces a wall of text that's technically correct and practically unreadable. If you're hunting for a specific layer or pattern (say, everything touching attn2 or a particular block index), pipe the keys output into a text search or filter rather than eyeballing the whole list - this node gives you the raw data, it doesn't do the searching for you. And remember that key naming isn't universal even within one architecture: two checkpoints that both claim to be the same base model can still use slightly different internal names depending on which tool exported them, which is exactly the kind of mismatch CheckpointTwoMerger's mismatch_mode setting exists to survive.