Checkpoint & Sampler

Checkpoint & Sampler is the pack's flagship "everything in one node" - it loads a checkpoint, encodes your prompt, builds the empty latent, samples, and decodes the VAE, all behind a single node that spits out a finished image. If you're a beginner staring at the standard ComfyUI graph of six nodes and thinking "do I really need all these wires," this is the node that says no. If you're a power user, you'll recognize it as the same philosophy ComfyUI-Easy-Use popularized: hide the plumbing, expose the knobs that matter.

What's behind the curtain

Mechanically it's a standard pipeline in a trench coat. It loads the checkpoint (cached per node instance - change the ckpt_name and it reloads), applies any lora stack you feed in, tokenizes and encodes the positive/negative text, applies a controlnet stack if one is attached, creates an empty latent at your chosen resolution, runs the sampler, and decodes to an IMAGE. The only output is image, ready for a save node or further post-processing.

The inputs that matter

Most are the usual sampler suspects you already know:

• ckpt_name - dropdown of your checkpoints.
• resolution - 33 presets from 128×128 up through the SDXL aspect ratios. The whole point: no Empty Latent node, no math.
• positive_text / negative_text - multiline prompts; the negative ships prefilled with a solid generic negative (bad anatomy, extra fingers, watermarks - the standard laundry list), which is a nice default you can clear.
• steps, cfg, seed, sampler_name, scheduler, denoise, batch_size - the regular dials, all present.
• optional_lora_stack and optional_controlnet_stack - wire in the pack's loraStack / controlnetStack nodes to add LoRAs and ControlNets without expanding the graph.

The trade-off

This is a convenience node, and convenience is the cost. You can't inject a noise image, you can't do a hires pass in the middle, and the sampler runs its whole pipeline inside one opaque box - when something's wrong, you get an image or an error, not a stage to inspect. For quick tests, iteration on prompts, or workflows you're handing to non-technical people, that's a fair deal. For anything where you need per-stage control, keep the full graph and treat this as a sketch tool.

One thing worth knowing: because the checkpoint is cached on the node, it stays loaded between runs, so repeated generation is fast until you switch models. That also means a big model swap takes a beat while it unloads the old one.

Installing it

It's the flagship of windfancy/zsq_prompt. ComfyUI Manager: search "zsq_prompt", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/windfancy/zsq_prompt

then restart. The pack's requirements.txt is heavy (transformers, ultralytics, onnx, opencv-contrib) but most of it serves other nodes in the pack; the sampler path itself runs on ComfyUI's own stack. And the now-familiar caveat: Manager may flag zsq_prompt as "conflicting" because of its generic class names - the community says ignore that unless you're actually running the other pack.

Verdict

The one zsq_prompt node with real appeal beyond the pack's own ecosystem. If you mostly want "prompt in, image out" without managing a six-node graph, this is a genuinely good fit.