OCS Substeps

This is where Overly Complicated Sampling actually picks the sampler - and there are 39 of them to choose from. OCS Substeps is the leaf node of the OCS stack: OCS Sampler ← OCS Group ← OCS Substeps. The Group decides when substeps run, this node decides what runs. It's also the node that lets you split a single step into multiple smaller ones, which is where "overly complicated" starts to earn its name.

What it is

Every OCS Group needs one or more OCS Substeps nodes attached. The node combines a substeps count with a step_method (the sampler). You can chain Substeps nodes through the optional substeps_opt input, and they run in order starting with the one furthest from the Group node.

The inputs that matter

• step_method (required) - the actual sampler. The familiar names are all here: euler, dpmpp_2m, dpmpp_2s, dpmpp_sde, heun, rk4. So are the interesting ones: res (Refined Exponential Solver, "generally works very well" per the author), pingpong, ttm_jvp, ipndm, deis, and the solver_diffrax / solver_torchdiffeq / solver_torchode / solver_torchsde backends. The (N) suffix on some entries tells you the model-call cost - euler costs 1, rk4 costs 4, so RK4 is roughly four times slower.
• substeps (required, default 1) - how many sub-steps each full step is split into. Generally one model call per substep, so 4 roughly quadruples sampling time. With the simple merge method a count above 1 mostly just costs you time; combine it with divide or overshoot on the Group node for it to do something.
• parameters (optional) - the YAML block. eta (ancestralness), s_noise, cfgpp (CFG++), the whole reversible block, and sampler-specific sections like bas and weoon for the author's own experiments.

The single OCS_SUBSTEPS output goes into the Group's substeps input.

What's worth actually using

Start with euler or dpmpp_2m to establish a baseline, then try res - it's consistently cited as the best all-rounder in the pack. heun and rk4 are there when you want extra accuracy and have the GPU time. The solver-backend samplers are a different beast: adaptive ones like dopri5 can burn 20–100 model calls per substep, which is the equivalent of running that many euler steps. That's not a bug, it's the cost of adaptive step sizing - but it means "why is this so slow?" has a real answer.

Installing and gotchas

Installed with the pack via Manager or git clone https://github.com/blepping/comfyui_overly_complicated_sampling into ComfyUI/custom_nodes, then restart. No model files. The solver backends need their Python packages installed (pip install diffrax torchdiffeq torchode torchsde) or those step methods will error out; everything else works out of the box.

Three gotchas worth knowing. deis, ipndm*, and gradient_estimation don't play well with ancestralness - leave eta around 0.25 or off. The adapter method wraps a normal ComfyUI SAMPLER, but ComfyUI's built-in CFG++ samplers don't work through it. And the pack is explicitly "in flux," so the 39-method list can grow or change between updates - a workflow from an older version may not resolve the same way after you update.