CivitAI Add Model Hashes

Post an image made in Automatic1111 to CivitAI and it auto-links every checkpoint and LoRA you used - little resource cards show up under the post, no typing required. Post the same kind of image made in ComfyUI, and usually... nothing. CivitAI just shows your prompt and shrugs at the resources. This node exists to close exactly that gap.

Why ComfyUI images don't auto-link

It's not CivitAI dragging its feet on Comfy support. CivitAI's own team has said the actual blocker plainly on Reddit: their site matches resources by file hash, not filename, because a filename alone isn't a safe way to identify a specific model version - people rename files, two different LoRAs get uploaded under the same name, and so on. A1111's CivitAI extension embeds those hashes into image metadata automatically, every time. ComfyUI's stock loader nodes don't - they only ever write the plain filename (ckpt_name, lora_name, vae_name) into the saved workflow JSON. No hash in the metadata means no match on CivitAI's end, full stop.

RK_CivitAIAddHashes patches that specific hole from the ComfyUI side. Drop it into your graph and, right before your image gets saved, it walks the run's metadata, finds every checkpoint/LoRA/VAE loader, hashes the actual model file sitting on your disk, and writes a short hash back in - the same 10-character SHA256-prefix format CivitAI already uses to match resources. Do that, and your next upload should auto-detect and link your models the way an A1111 image always has.

How it actually works

This is the clever bit. ComfyUI quietly passes a live prompt object - the whole run's node graph, in API format - into any node that asks for it as a hidden input. It's the same object for the whole run, so if one node mutates it, anything that reads it afterward sees the change. RK_CivitAIAddHashes grabs that hidden prompt, loops over every node inside it, and for any input literally named ckpt_name, lora_name, or vae_name, it resolves the real file on disk, hashes it, and writes the result back as ckpt_hash / lora_hash / vae_hash. Then when your Save Image node runs later and embeds that same prompt object into the PNG, your hashes are already sitting inside it.

Which means wiring matters. Route the node's IMAGE output into your Save Image node rather than leaving it off to the side - that's what guarantees it executes before the save, which is the entire point of the node.

The inputs and outputs that matter

Exactly one input to touch: image - feed it whatever you're about to save. It passes straight through to the single IMAGE output, pixel-for-pixel unchanged; the real work happens on the hidden prompt data riding alongside it, not on the image itself. Wire that output into your Save Image node.

Installing it

Manager or manual, same as any pack:

cd ComfyUI/custom_nodes
git clone https://github.com/rklaffehn/rk-comfy-nodes

Restart ComfyUI. No extra Python packages, no model downloads - it's pure standard library (hashlib, os) plus ComfyUI's own folder_paths, so there's nothing to break during install. One honest flag, though: as of writing, the pack's GitHub repo doesn't resolve - the author's public account currently shows only unrelated forks, no rk-comfy-nodes of its own. If git clone 404s on you, that's why; it looks pulled or abandoned rather than renamed, so check whether it's still cached in your ComfyUI Manager's node list before assuming your setup is the problem.

Where people get burned

The silent-failure mode is the one to actually know about: the code wraps each node it visits in a bare try/except and just moves on if anything goes wrong, with no console warning you'd notice. So if a hash didn't show up, check the boring stuff first - is the loader you're using ComfyUI's standard one, with an input literally named ckpt_name, lora_name, or vae_name? A loader from a different pack with a differently-named widget gets silently skipped; those three exact parameter names are the whole list it recognizes.

Second, it only hashes what's actually flowing through those loader inputs - nothing wired, nothing hashed. And since it never touches pixels, don't expect any visible change to the image; that's correct behavior, not a bug. The work is invisible until you inspect the saved file's metadata or check what CivitAI does with it on upload. If you want to actually eyeball the result before you save, pair this with RK_CivitAIMetaChecker from the same pack instead of finding out after the fact on CivitAI's side.