SimKarr Scheduler

Schedulers in ComfyUI are a dropdown, and you pick one. SimKarr is what happens when you refuse: it builds a sigma schedule that runs one algorithm for the first chunk of steps and a different one for the rest. Simple + Karras, or Karras + Simple, your call.

Drop-in replacement for the stock BasicScheduler node - same shape (model, steps, a scheduler decision, denoise), same single sigmas output - which is the cleanest way to think about it. Swap the node, keep the wires.

The idea, and why it's an SDXL-shaped idea

A simple (linear-ish) schedule removes roughly equal amounts of noise per step. Karras concentrates the work in the middle of the run, which is why DPM++ 2M Karras was the universal default for years: on a curved DDPM trajectory, reshaping where the effort goes is a genuine correction, and it buys you quality at lower step counts.

SimKarr splits the difference, and the tooltips tell you the author's intent directly:

• mode: simple_karras - "Simple first (composition) → Karras second (details)."
• mode: karras_simple - "Karras first (character) → Simple second (stabilization)."

So it's not random. You're choosing whether the reshaping happens during composition or during cleanup. simple_karras is the one to try first on an SDXL-family model: flat and stable while the layout sets, then a mid-run push where details live.

The caveat that matters more than the node. Karras is a correction for DDPM-style models - SD 1.5, SDXL, and every SDXL finetune (Illustrious, NoobAI, WAI, Pony V6). On flow-matching architectures (Flux, Z-Image, Klein, ERNIE, and essentially everything new) Karras and exponential aren't merely suboptimal, they're near-universal failures, because a straight trajectory has nothing for an aggressive sigma reshuffle to fix and plenty for it to break. Half a hybrid Karras schedule is still half a Karras schedule. If your checkpoint came out after 2024 and isn't an SDXL derivative, skip this node.

The inputs

• model - needed because the schedule is read off the model's own sampling type; Karras and simple aren't the same curve between architectures.
• steps - INT, 1 to 10000, default 20. The sampler derives its actual step count from the sigma list you hand it, so this is really "how long the schedule is."
• split_ratio - FLOAT, 0.1 to 0.9, default 0.33: the "fraction of steps for FIRST algorithm." At 0.33 with 30 steps, roughly the first third follows the first algorithm and the rest the second.
• mode - the combo above.
• denoise_mode (BOOLEAN, default off) plus denoise (FLOAT, 0.01 to 1, default 1). This is the partial-denoise pair: with a custom sigma schedule, the noise level you start at is encoded in the sigmas themselves, so truncating the list is what "denoise 0.6" means. Turn denoise_mode on for img2img-style runs, and don't expect the denoise widget on a downstream KSampler to do anything when it's being fed explicit sigmas.

Output is a single sigmas. Wire it into SamplerCustom/SamplerCustomAdvanced, or into the pack's own CFG Sculptor Advanced, which takes sigmas as a required input - so if you're already there experimenting with CFG curves, this is the other half of the same experiment.

The node's one-line description claims "NaN-safe, monotonic," which is worth a sentence rather than a shrug. A sigma list that isn't monotonically decreasing is a classic route to black frames and NaN errors, so the author is advertising that the hybrid join is guarded. If you do get black images out of a custom sigma setup, the usual suspects are the standard ones: fp16 misbehaving on older GPUs, or --disable-nan-check masking NaN rather than fixing it.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Rimor-dev/ComfyUI-CFG-Sculptor
# restart ComfyUI

The README's clone line says Rimor/; the repo is Rimor-dev/ComfyUI-CFG-Sculptor. Manager: search ComfyUI-CFG-Sculptor. Torch and numpy, no model files, but you need a current ComfyUI with comfy_api support - this is a newer-API pack.

Verdict

It's a two-line experiment with a real premise and no community footprint, so treat it the way you'd treat any schedule tinkering: fixed seed, same prompt, one change, several generations each. If you're on an SDXL finetune and you like DPM++ 2M Karras already, the interesting question is whether simple_karras at 0.33 sharpens the last third without the mid-run saturation Karras gives you. If you're on Flux or anything Z-Image-shaped, the answer is no and the question is moot.