Load Checkpoint Preset

Let's get the headline out of the way: this node does not load a checkpoint. The name oversells it. What "Load Checkpoint Preset" actually does is load the settings that go with a checkpoint - VAE, CLIP, clip skip, steps, CFG, sampler, scheduler, even default positive/negative prompts - and hand them to you as outputs. You still need a real loader downstream to pull the actual weights. Think of it as a preset router, not a loader.

Why bother? If you swap models often you know the drill. Every checkpoint wants different steps, a different CFG, a different VAE, and honestly a different flavor of prompt. Keep that knowledge in one YAML file and this node becomes a single source of truth: pick the model once, and everything downstream fills itself in. It's the same pattern as a context bus or an Efficiency-style mega-loader, just split into individual values you can wire wherever you want instead of one opaque pipe.

How it works

The brain is a file called models_config.yaml in the pack's root folder (you create it yourself; the README has a template). Each key is a regex matched against the model filename, and each entry lists the settings to apply:

"SDXL.*":
  vae_name: "sdxl_vae.safetensors"
  clip_skip: -2
  steps: 30
  cfg: 7.0
  sampler_name: "euler"
  scheduler: "normal"

".*":
  steps: 30
  cfg: 7.0
  sampler_name: "euler"

Two things make this cleverer than a simple map. First, matching is order-sensitive with fall-through: patterns are merged top to bottom, the first match wins per key, and later patterns only fill in keys that are still unset. So you can put model-specific overrides first and a ".*" catch-all last that supplies defaults. Second, a __keywords__ section lets you define placeholders like {quality} and {neg} that get substituted inside the positive/negative strings.

When you change the model_name dropdown, the node's frontend calls a local API endpoint, reads the matching preset, and writes every value back into the node's widgets. That auto-refresh is the "preset" part of the experience - pick a model and watch steps, CFG, and the prompt boxes repopulate.

The inputs and outputs that matter

The inputs are a full generation config: model_name (the dropdown that triggers everything), plus vae_name, clip_name, clip_type, clip_skip, steps, cfg, sampler_name, scheduler, and optional positive/negative. There's also a preset_name field that gets stamped with the comma-separated list of regex patterns that actually matched, so you can see what applied instead of guessing.

The outputs mirror the inputs: model_name, vae_name, clip_name, clip_type, clip_skip, steps, cfg, sampler_name, scheduler, positive, negative. Feed the names into your real loaders (checkpoint, CLIP, VAE), and steps/cfg/sampler_name/scheduler into your KSampler. The prompt strings can go straight into CLIP Text Encode nodes.

Install

ComfyUI Manager (search "ComfyUI-GadgetNodes"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/2daadv/ComfyUI-GadgetNodes.git
pip install -r ComfyUI-GadgetNodes/requirements.txt

Then restart. No model downloads - the pack itself is dependency-light (dynamicprompts and requests).

Where people get burned

• No YAML file, no presets. It doesn't crash; it silently runs with defaults. The first time you add models_config.yaml you need to reselect the model for the auto-apply to fire.
• The auto-apply is a frontend hook. It runs in the classic LiteGraph UI. On the newer Nodes 2.0 frontend the README warns this may not work - the node still outputs values, but you may have to set them by hand. Also, editing a widget by hand then changing the model will happily overwrite your edit. That's the feature, not a bug.
• Regexes match filenames. Name your files so they match, and mind the YAML order if you rely on the fall-through behavior.

It's a quiet node - no community thread traffic that I could find, so treat the README as the contract. If you live in one model, it's overkill; if you rotate through a dozen checkpoints, it's the node that remembers what each one wants.