Saya Sampling Config · beta45 compatible

SayaKSamplerConfig is a value node with a party trick. You type steps, a refiner step, CFG, sampler and scheduler in one place, and it hands all five back out as typed sockets so a dozen downstream sampler nodes can share them - right-click a KSampler's steps widget, convert it to an input, and wire this node's steps output into it. One authoritative source instead of six boxes you forget to keep in sync. That alone would justify the node in any large workflow.

The party trick is the part the "beta45 compatible" in the display name is bragging about, and it's worth understanding because it's the difference between this config node and most of the others. In ComfyUI, sampler and scheduler dropdowns are enum types, and the engine refuses to wire an enum output into an input unless the two lists are exactly the same set. Now add the modern reality: custom packs extend ComfyUI's stock sampler and scheduler lists. The RES4LYF-style ecosystem renamed whole swaths of sampling - res solvers, and named beta schedules like "beta57" (the beta schedule with alpha 0.5, beta 0.7) that anime and realism workflows now set by name. If your config node captured its scheduler list before such a pack extended KSampler.SCHEDULERS, its output is now a different enum than the sampler accepts, and your link refuses to connect or re-connects wrong.

This node sidesteps that by not hard-coding anything: at load time it reads the live lists straight from comfy.samplers.KSampler - samplers and schedulers - and builds both its input dropdowns and its return types from that same snapshot. Input enum and output enum are by construction identical, so whatever sampler you're feeding accepts them. When the author says "beta45 compatible," that's the claim: a custom beta45/beta57 scheduler added by another pack doesn't break this node's wiring, because the types are born equal.

The widgets are the values that matter:

• steps_total (default 4) and cfg (default 1.0) - note how few steps and how low a CFG: this is aimed at modern few-step / flow-style sampling, not SD 1.5's 20+ at CFG 7. A cfg of 1.0 is a red flag for old muscle memory.
• refiner_step (default 2) - the step where a second, refiner stage takes over. In the Saya pipeline's own phase list there's a refiner pass, and this is the knob that says when it starts.
• sampler_name and scheduler - the full runtime list, which on a current ComfyUI install is 40+ samplers including the res_* multistep family and nine schedulers.

All five mirror out with the exact same names: steps, refiner_step, cfg, sampler_name, scheduler. Nothing is computed or transformed - it coerces types and hands them through, so you can trust the wire matches the widget.

Install follows the whole pack: ComfyUI Manager, search saya-comfy-couple-plus, or

cd ComfyUI/custom_nodes
git clone https://github.com/alphaziod/saya-comfy-couple-plus

then restart. Only numpy/Pillow as extra deps, no model downloads. One real-world caveat the source itself notes: the lists are read when the pack imports, so if the scheduler-extending pack loads after Saya in the same startup, both are still consistent with whatever was registered when each read the list - order can matter if you chain multiple config nodes. Keep one source of truth per workflow and you're fine.

Honestly? For a single KSampler this node is overkill. For a multi-phase workflow where the base pass, hires, refiner and detailers all need to agree on settings - which is exactly the kind of graph this pack is built around - it's the difference between editing one box and hunting through four.