Load Checkpoint Hub Pro

Load Checkpoint Hub Pro is the flagship of this pack and the one node you'd build the whole workflow around. It does what a Load Checkpoint does - loads a checkpoint and hands you MODEL, CLIP, and VAE - and then keeps going: it also carries the sampling recipe (steps, refiner steps, CFG, sampler, scheduler, denoise), your positive and negative prompts, and a metadata string, all out of the same node.

One node, thirteen outputs, the entire generation plan. You wire it to a KSampler and a couple of CLIP Text Encode nodes, and you're done - the checkpoint, the settings, and the prompts all trace back to a single place you edit in one go.

How it works

The load itself is comfy.sd.load_checkpoint_guess_config() on the selected file, with the VAE and CLIP extracted and your embeddings directory pointed at so your trained embeddings resolve. "Guess config" is the important bit: it sniffs the checkpoint and loads the right architecture, so SD 1.5, SDXL, and the rest all work through the same node without you picking a config. The sampler and scheduler dropdowns are pulled live from comfy.samplers, and the prompt fields are multiline with dynamic prompts enabled.

The load also happens on every queue, so if you swap the checkpoint in the dropdown and hit run, you get the new one - no bypass-and-reload dance.

The outputs that matter

• MODEL, CLIP, VAE - the three loaded components. MODEL goes to the sampler, CLIP to your text encoders, VAE to encode/decode.
• steps, step_refiner, cfg, sampler_name, scheduler, denoise - the recipe, combo-typed where a combo socket is expected so they click straight into a KSampler or SamplerSelect.
• ckpt_name - the filename as a combo slot, if a downstream loader needs to know which checkpoint ran.
• positive_prompt, negative_prompt - plain STRING outputs. Note they're strings, not conditioning: you still run them through CLIP Text Encode before they reach the sampler. The hub carries your text; it doesn't encode it.
• metadata - a single-line string for workflow tags, passed through to wherever you keep records.

That last trio is the quiet killer feature for a model-testing workflow: your checkpoint name, prompts, and metadata all travel as data, so you can log exactly what produced each render without parsing it out of the image afterwards.

How this compares to a context bundle

If you've used rgthree's Context, you know the appeal of one wire carrying everything. This node is the explicit-wire version of that idea - every value gets its own socket instead of riding inside a bundle. More cables on screen, but nothing hidden inside a payload, which means no "which version of the value is in there" debugging. The KB's own guidance: explicit wires while you're actively iterating, context bundles when wire count becomes the actual problem. This node sits firmly on the explicit side, and for a workflow you're building and tuning, that's usually where you want to be.

Installing it

Part of MarwanDSAI/comfyui-mdsnodes. ComfyUI Manager: search "ComfyUI-MDSNodes", install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/MarwanDSAI/comfyui-mdsnodes

Restart, and no pip install - the pack's requirements.txt is empty and it declares zero dependencies.

Gotchas

Two things to keep straight. First, this node expects a checkpoint - the dropdown lists models/checkpoints, so a separate UNET/diffusion file won't appear (that's Load Diffusion Model Hub Pro's job, and note it does not output CLIP or VAE, so the two hubs are not drop-in swaps). Second, the version numbers tell a story: the README still says v1.0.13 while the package is at 2.0.0 and ships extra nodes the README doesn't mention - if the docs seem behind the menu, the code is ahead of the README, and the menu is what you should trust.