DDRK Omega Auto (one-click)

Why reach for it

Sampler advice fell apart somewhere around 2024. "DPM++ 2M Karras, 25 steps, CFG 7" was the universal answer for years, and on a flow-matching model it's now actively wrong - Karras reshapes a sigma curve a straight trajectory doesn't need reshaped. Meanwhile the serious answer moved into packs like RES4LYF, which are genuinely good and come with a homework assignment.

DDRK Omega Auto is the opposite end of that. It's one node that reads your model, decides steps, CFG, schedule and integrator for it, and prints what it decided. It's a fair choice when you've got a new checkpoint and no interest in spending an evening finding out which sampler family it belongs to.

How it decides

It asks the model, not you. The family comes from the sampler object attached to the model - if it's a CONST it's flow matching, otherwise EDM - and the model's ComfyUI config class name picks a preset of starting steps and CFG: SD 1.5 at CFG 7/25 steps, SDXL 6/25, SD 3 or 3.5 at 4.5/28, Flux 1.0/20 (guidance-distilled, so strength comes from the FluxGuidance value in your conditioning, not from CFG), Qwen-Image 2.5/20, Chroma 4/26, Wan 5/25, LTX-Video 3/30.

Models that are few-step by construction are recognised as such and always sampled in turbo mode - Flux schnell, Z-Image Turbo and the distilled HunyuanVideo 1.5 SR - at 6 steps and CFG 1, on the model's own schedule, which for those checkpoints lands the steps where the distillation was aimed. The integrator is HC3 in every case: third order at one model call per step, and it damps itself back toward first order where high CFG makes extrapolation unsafe. That's the property you want from a one-click node: high CFG at few steps is where other multistep samplers overshoot.

The settings output is a string, also printed to the console on every queue. It reads something like DDRK Omega Auto: SDXL [EDM] | 25 steps (auto) | CFG 6 (auto) | HC3 integrator, Karras | ~25 model calls. Connect it to a Preview Any or a note node and you stop having to guess.

The inputs you'll touch

Wire model, positive, negative and latent_image exactly as you would a KSampler, and send latent to VAE Decode.

steps and cfg both default to 0, which means "you decide". Anything above 0 is used as-is - that's your override when a model card says otherwise. quality is the coarse budget dial: fast is roughly 0.6x the steps, balanced is the model's usual count, best is 1.5x the steps on SD/SDXL and on flow-matching models a second latent-space pass at 1.33x resolution instead. model_type matters more than it looks - a Turbo, Lightning, Hyper, LCM, DMD or schnell-style LoRA is invisible to a node reading your model file, so you have to tell it: set turbo / lightning / few-step and you get 4-8 steps at CFG 1. denoise is optional and 1.0 is text-to-image; drop it for img2img.

The two outputs are latent and settings. That's it. No sampler dropdown, no scheduler dropdown.

Install

Same pack, no dependencies beyond ComfyUI itself:

cd ComfyUI/custom_nodes
git clone https://github.com/HVOSTOVSKY/DDRK-Omega-Sampler

Restart. It's under sampling → DDRK Omega, and the repo also ships an example workflow - DDRK Omega Auto - text to image - in the templates browser if you'd rather load a working graph.

Where people get burned

Those preset steps and CFGs are the values model makers and ComfyUI's own templates use. They are not measurements, and a finetune or a LoRA can move them a long way. Read settings, and if the image is wrong, override rather than switching sampler.

best on a flow-matching model is the expensive one - about 1.7x the time in the author's own bench, plus the VRAM for a 1.33x canvas. It was measured on 8 GB with small models; a 20B Qwen-Image at 1 MP may simply not fit at 1.33x.

One version trap worth stating plainly: release 1.9.0 of this pack failed to import at all, so nothing loaded, and 1.8.0 changed the flow-matching defaults enough that the same seed produced different images. If you installed a while ago, update first. And if you load someone else's workflow that uses DDRK nodes, a "node not found" error is just the pack being absent - Manager, search the pack title.

Finally, temper your trust. This pack has almost no footprint in the discussion corpus - nobody's arguing about it, which means no independent A/Bs to lean on. What it does have is an unusually explicit "this part is measured, this part isn't" section that names the things that failed its own tests. That's more than most packs give you, but you're still the one validating the output.