Increasing guidance schedules (Wang et al. 2024)

If you always render at cfg 7, you're applying the same amount of guidance to step 1 - pure noise - as to step 49. That's a strange way to spend a budget, and Wang et al. (arXiv 2024) went and measured the alternatives: run the scale as a curve over the run, keep the average equal to your cfg so you're comparing like with like, and see which shape wins. Their answer was rising schedules, with a floor under them.

This node is the practical version: six shapes, one floor, no scale input. The sampler's cfg is the average it will maintain.

The mechanism

The shape runs over the run's progress tau (0 at the noisiest step, 1 at the last), normalized so that its mean equals the sampler's cfg:

• linear up, cosine up - rising; the paper's winners.
• linear down, cosine down - falling, i.e. the opposite hypothesis.
• v_shape, lambda_shape - down-then-up and up-then-down, the two "middle versus ends" shapes in one place.

The floor (default 4.0) clamps the scheduled scale from below: the scale never falls under it. The paper's reported values are 4 for SDXL and 2 for SD1.5, and the node's default matches the SDXL case.

Why floor matters: with a rising schedule and the average pinned at 7, the early steps have to go below average to pay for the later ones. Without a floor you can end up with steps at 2 or 3, where the model barely listens. The floor keeps the low end in a sane range and accepts that the time-average then sits slightly above your cfg.

Inputs and output

• model - loader → node → sampler.
• shape - linear up, cosine up, linear down, cosine down, V shape, Lambda shape; default linear up.
• floor - default 4.0. "The scale never falls below this (paper: SDXL 4, SD1.5 2)."

Output: MODEL.

Note what's not in the input list: there is no scale. The node reads the sampler's cfg as the average it targets, which is deliberate - the paper's whole comparison rests on keeping the guidance budget constant, and a node with its own scale field would invite you to double-guide by accident. If you want a bigger effect, raise the sampler's cfg.

Is it worth it?

It's good value for how few decisions it demands. The theoretical case - cool early steps commit to less, hot late steps refine more - lines up with what people observe when they lower cfg for layout and raise it for texture, and nothing here can go catastrophically wrong.

Where I'd reach for it over a fixed scale: when composition and colour are good but texture and fine prompt details are underbaked, and you don't want to globally raise cfg because the early steps are already bossy. Rising schedule, floor 4, sampler cfg 8 or 9.

And where I wouldn't: distilled checkpoints run at cfg 1, where there's no guidance to schedule.

Install

Manager → search CFG Megapack → install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/AbstractEyes/comfy-cfg-megapack

No dependencies, no downloads, nothing to configure - the pack ships without a requirements.txt because it only uses torch and the stdlib. It does need a current ComfyUI: the nodes are written against comfy_api.latest (the README reports 0.38.0, torch 2.11), so if you get nothing in the node menu after restarting, check the version.

Where people get burned

The floor eating the schedule. If the sampler's cfg is 5 and the floor is 4, there's almost no room for the curve to move - you've built a nearly constant schedule. Floor wants to be well below the average: cfg 8–10 with floor 4 is the sane pairing.

Comparing against a constant cfg and expecting the same image. By construction the average is held equal, so the difference is distribution, not strength. Sitting on the same seed, the rising version usually shows a slightly different layout and better late texture. That's the effect; don't go looking for a prompt-adherence jump.

Chaining a second "when" node. This node writes the schedule stage, shared with CFG When and the other schedule paper nodes. Later node wins, silently. (CFG Plan Readout lists what's actually installed.)

Falling shapes. The paper found rising schedules best; linear down and cosine down are in there for completeness and for people who want to test the opposite. If you're just going to leave it on a default, linear up is the default for a reason.

The CFG-function slot. Unrelated to scheduling - but a stock RescaleCFG, Mahiro or RenormCFG node chained after anything in this pack takes ComfyUI's single CFG-function slot, and then your schedule is queued against a rule that isn't running.