Optimizer Config ProdigyPlusScheduleFree

This is the fancy one. OptimizerConfigProdigyPlusScheduleFree wires in Prodigy-Plus-ScheduleFree, an optimizer that combines two ideas: Prodigy's automatic learning-rate finding and the schedule-free approach that removes the need for a learning-rate scheduler entirely. It comes from LoganBooker's prodigy-plus-schedule-free, which kijai bundles into the pack specifically for this node.

The appeal is "set it and forget it": no LR to tune, no scheduler to pick, and a pile of optional modern tricks you can toggle on if you know what they do. The catch is that pile of toggles - it's the most option-dense optimizer node in the pack, and most of them you should leave exactly where they are.

How it works

The node outputs optimizer_settings (type ARGS) for the Init node. Because it's schedule-free, there's no lr_scheduler input here - that's the point. The inputs that actually matter for a beginner:

• lr (default 1) - like Prodigy, you leave this at 1.0 and let the optimizer scale from there. This lives on the node itself, not the Init node.
• d0 (default 1e-6) and d_coef (default 1) - the initial learning-rate estimate and its coefficient. d_coef is the one knob people actually touch: raise it to make the adaptive rate more aggressive, lower it to be gentler. Leave d0 alone.
• use_stableadamw (default true) - a stability improvement, on by default and best kept on.
• split_groups (default true) - handles parameter groups separately; default is fine.
• min_snr_gamma (default 5) - standard loss weighting.

Then there's a row of experimental toggles - use_cautious, use_adopt, use_grams, use_orthograd, use_focus, stochastic_rounding - each swapping in a different research technique. Unless you're following a specific recipe that names one, leave them at their defaults. They're there for tinkerers, not for your first run.

When to reach for it

Try this when you want the most hands-off run possible and you're happy to trust an adaptive, schedule-free optimizer to handle the LR entirely. It's a legitimately convenient choice. If you're following a published recipe that specifies a concrete optimizer, LR, and schedule, though, this node is solving problems that recipe already solved - stick with what the recipe says.

Installing the pack

ComfyUI Manager: search ComfyUI Flux Trainer, install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-FluxTrainer
pip install -r ComfyUI-FluxTrainer/requirements.txt

Torch 2.4.0+ recommended, plus kijai's ComfyUI-KJNodes for the example workflows.

Common issues

You set lr to a tiny number. Same trap as plain Prodigy: leave lr at 1.0. This optimizer scales its own rate, and a small value fights that.

Toggle overload. Do not flip the experimental booleans on just because they're there. Each one changes the optimization dynamics, and stacking several without understanding them is a good way to get a run that behaves nothing like any recipe. Start with defaults, change one thing at a time.

Comparing it fairly is hard. Because it removes the scheduler and auto-tunes the LR, results won't line up with an AdamW run at the same "settings" - there's no shared settings to hold constant. Judge it on its own output via the validation nodes, not against an Adam baseline.