ConditioningSetTimestepRange
Make a prompt only steer part of the denoise
- conditioning
- CONDITIONING
Every conditioning has a window of influence baked in: when during denoising it should steer. By default that window is the whole sample - 0% to 100% of progress. ConditioningSetTimestepRange narrows it. It's the prompt-level equivalent of the start/end percent knobs on ControlNetApplyAdvanced, and it's the tool behind a family of composition tricks that most people never realize exist.
Inputs
conditioning- the conditioning to window.start/end- fractions of sampling progress, 0 to 1.startis when the conditioning switches on,endis when it switches off.
The mechanism is one line in the source: it stamps start_percent and end_percent onto the conditioning. The sampler then consults those fields at each step and stops letting that conditioning influence the denoise outside the window.
What it's for
The classic use is compositional: you want the model to establish the scene early, then let the subject take over. Put your background prompt on a window of 0.0–0.5 and your subject prompt on 0.5–1.0, and you get a two-phase generation where each prompt only ever speaks during its turn. It's also how you keep a negative prompt from fighting the details: apply it only during the early structure-forming steps, then release it so the detail phase isn't pulling against it.
If that sounds like the ControlNet guidance-start advice, it is - the ControlNet community learned years ago that holding structure through the whole sample causes problems and releasing it once composition forms is the standard fix. This node brings the same principle to text conditioning.
The gotchas
The numbers are fractions of sampling progress, not steps, so they survive changes to step count - that's a feature. Keep end above start; a backward window does nothing sensible. And the window applies per conditioning entry, so chain separate ConditioningSetTimestepRange nodes if you want different windows on positive and negative. The subtle one: for this to compose two prompts cleanly, both need the same token shape (same encoder family), same as ConditioningAverage - windowing doesn't make mismatched conditionings compatible, it just scopes when they're audible.
Verdict
One of those nodes you'll ignore for a year and then suddenly need. It ships with ComfyUI core - ancient, stable, zero setup. If you're wondering why your "background first, subject later" workflow exists in some template, this is the node that makes it work. And when prompts seem to be fighting each other, the fastest experiment is windowing one of them to the first half of the sample and seeing what survives.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| conditioning | CONDITIONING | — | |
| start | FLOAT | 0.0000–1 | — |
| end | FLOAT | 1.0000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONDITIONING | CONDITIONING | — |