Advanced ControlNet schedules ControlNet strength across sampling steps and latents

A strength slider is not a schedule

ComfyUI-Advanced-ControlNet provides nodes for scheduling ControlNet strength across timesteps and batched latents, as well as applying custom weights and attention masks.

Start with what a vanilla ControlNet node does. It takes a control image, a strength and a start and stop percentage, and it applies the control through the sampling process. That is a flat, undifferentiated influence, and for a lot of work it is exactly right.

The cases this package exists for are the ones where it is not. A control image that should fade in halfway through rather than being present from the first step. A control image that should apply to one frame of a batch and not to the others. A control image that should be strong in the composition and weak in the detail, or the other way round. A prompt that should dominate in the early steps and a control that should dominate in the late ones.

All of those need the same primitive, a strength that varies over the sampling timeline and over the batch, and that is what the nodes provide.

The implementation is Python, GPL-3.0 licensed, the version in the project file is 1.6.0, and the last push was on 2026-07-28. There are no GitHub releases, so the package is installed the way every ComfyUI custom node is installed.

Timestep keyframes and latent keyframes

The readme names the two core concepts for scheduling, and they are worth reading carefully because they are easy to confuse.

Timestep keyframes hold the values that guide the settings for a controlnet, and begin to take effect based on their start_percent, which corresponds to the percentage of the sampling process. They can contain masks for the strengths of each latent, control_net_weights, and latent_keyframes, which are the specific strengths for each latent. All of those are optional.

Latent keyframes determine the strength of the controlnet for specific latents. All they contain is the batch_index of the latent, and the strength the controlnet should apply for that latent. And the readme explains the relationship between the two ideas directly: as a concept, latent keyframes achieve the same effect as a uniform mask with the chosen strength value.

So a timestep keyframe is a timeline and a latent keyframe is a per-item override. A latent keyframe says that frame three of this batch gets a strength of 0.4, wherever the timeline would otherwise put it.

The override semantics have one wrinkle that the input documentation spells out. The latent_kf_override input is an override for latent keyframes, useful if no other features from timestep keyframes are needed, and the note says this latent keyframe will be applied to ALL timesteps, regardless of whether there are other latent keyframes attached to connected timestep keyframes. The same warning appears for weights_override. In other words, the override is global across the timeline, not a merge with the per-timestep values.

Soft Weights is where the prompt and the control negotiate

The feature list calls out Soft Weights by name, and it is the most interesting idea in the package.

Custom weights allow replication of the My prompt is more important feature of the Auto1111 sd-webui ControlNet extension via Soft Weights, with the softness tweaked via base_multiplier. And the ControlNet is more important feature can be granularly controlled by changing the uncond_multiplier on the same Soft Weights.

The Auto1111 extension offered two presets: the prompt is more important, or the control is more important. Soft Weights makes that a dial, and the readme explains the granularity. Setting uncond_multiplier to 0.0 gives identical results to the Auto1111 feature, but values between 0.0 and 1.0 can be used without issue to granularly control the setting.

So the mechanism is a pair of multipliers on a soft weight curve, one for the base and one for the unconditional part, and you can reproduce the old behaviour exactly or move off it in small steps.

That is a meaningful difference in practice. A preset gives only two options, while a dial lets you find the balance that works for a particular model and a particular strength, which is a different value for every combination you use. It is the kind of control that a workflow author tunes once and then hard codes, so the fact that it is exposed as a number rather than a checkbox matters.

Two nodes, and one of them is not optional

The package provides the Apply Advanced ControlNet and the Load Advanced ControlNet Model nodes, and the readme is explicit about a constraint that trips people up.

The vanilla ControlNet nodes are also compatible and can be used almost interchangeably, but the only difference is that at least one of these nodes must be used for advanced versions of ControlNets to be used. The readme adds that this matters especially for sliding context sampling, like with the AnimateDiff-Evolved nodes.

So the Load Advanced ControlNet Model node is the one that does the work. It loads a ControlNet model and converts it into an Advanced version that supports the features in this repository, and the Apply node then applies it, automatically converting any ControlNet from the standard loaders into an Advanced version if it is a supported type.

The input documentation uses a colour key to mark what is required, what is optional, what starts as a widget but can be converted to an input, what is optional but not recommended, and what is an output. The key is worth reading, because the distinction between an optional input and an optional input you should not use is exactly the kind of thing a screenshot does not convey.

The required inputs for Apply Advanced ControlNet are the positive and negative conditioning, the control_net and the guiding image. The image input has a rule worth knowing: if one image is provided it is used for all latents, if more are provided each is used for a separate latent, and if there are not enough images to meet the latent count the images are repeated from the beginning to match vanilla ControlNet functionality. The mask input follows the same rule, and a non-binary mask carries a relative strength as well as an area.

Nine model families and a preview grade of support

The set of control models the package handles is long, and the list is the fastest way to see whether your workflow is supported.

There is ControlNet itself, T2IAdapter, ControlLoRA, ControlLLLite including the Anima LLLite v2 and inpainting models, ControlNet++, and CtrLoRA, with the relevant models linked on the CtrLoRA github page. There is SparseCtrl, and there is SVD-ControlNet, with the Stable Video Diffusion ControlNets trained by CiaraRowles listed for depth and lineart.

The Reference support is the most detailed entry, and it has its own set of modes: reference_attn, reference_adain, and the combined refrence_adain plus attn mode as the readme spells it. The style_fidelity and ref_weight options are equivalent to style_fidelity and control_weight in Auto1111, and the strength of the Apply ControlNet is the balance between the ref-influenced result and the no-ref result. There is also a Reference ControlNet (Finetune) node that allows adjusting the style_fidelity, the weight, and the strength of attn and adain separately.

So this is not a package that supports one model well. It supports the whole family, and the Reference modes in particular show a level of control that goes past the standard ControlNet interface.

The Advanced ControlNet nodes here fully support sliding context sampling, like the one used in the ComfyUI-AnimateDiff-Evolved nodes, and for ControlNet, T2IAdapter and ControlLoRA specifically the sliding context window support is listed as a feature.

Preprocessors are somebody else's node

The guiding image matters more than it looks, and this package does not provide it.

ControlNet preprocessors are available through the comfyui_controlnet_aux nodes, by Fannovel16. The Apply node's documentation says the image must be a preprocessed image if the loaded controlnet requires it, and the node does not perform the pre-processing itself.

That is a reasonable division of labour, since preprocessors are a separate and quickly moving set of models, but it does mean the workflow has two custom nodes where a beginner expects one. A canvas that the controlnet expects, such as a depth map or a pose skeleton, has to be produced before it reaches this node.

The documentation also has a gap that is worth flagging for anyone deciding whether to rely on it. The table of contents lists a Usage section and annotates it with the note that it will fill this out soon.

So the scheduling explanation and the node reference are thorough, and the worked examples are not there yet. For a package aimed at people building graphs by hand, the node reference is enough to start, but the missing usage section means the first workflow is something you work out rather than copy.

Packaged for the Comfy Registry with no dependencies of its own

The project file is short and describes how the package is distributed.

The dependency list is empty, which is correct for a ComfyUI custom node, because the nodes run inside the host application and use what the host provides.

The Comfy Registry metadata is the part to look at. The PublisherId is kosinkadink, the DisplayName is ComfyUI-Advanced-ControlNet, and there is a requires-comfyui value of 0.3.68 or greater. That is a real constraint, and it is the version check to do first, because a node that uses a recent ComfyUI API will fail on an older host in a way that is usually a stack trace rather than a friendly message.

The repository layout matches the packaging. There is an __init__.py for the node registration, an adv_control/ directory for the implementation, a tests/ directory, an examples/ directory with an anima_lllite_v2 example and a qwen_image_inpainting example, and an AGENTS.md for the tooling that contributes to it.

The examples are the interesting part for evaluation, because each one is a working graph for a specific model type. If the thing you want to do involves an Anima LLLite v2 model or a Qwen image inpainting setup, there is a reference workflow to read, which is worth more than a usage guide written for the general case.

Editorial conclusion

Adopt ComfyUI-Advanced-ControlNet when a single ControlNet strength is not enough for your workflow, for example when the control image should fade in partway through sampling or apply to only one frame of a batch, and when you run sliding context sampling with AnimateDiff-Evolved. Do not adopt it for a one line ControlNet workflow, because the vanilla node is simpler and the advanced node requires the extra Load Advanced ControlNet Model step. Verify first that your ComfyUI version is 0.3.68 or newer, that the control model you plan to load is one of the supported types, and that you pre-process the control image yourself, since the preprocessors live in a separate custom node.

Frequently asked questions

Official sources

1. Issues
2. Kosinkadink/ComfyUI-Advanced-ControlNet on GitHub
3. License: GPL-3.0
4. README