Nodes/ComfyUI-Prediction/Conditioned Prediction
ComfyUI Node

Conditioned Prediction

Where every prediction graph starts

By redhottensors·Created 3 years ago·Updated 2 years ago· 15
Conditioned Prediction
  • conditioning
  • prediction
namepositive

Every custom prediction graph in this pack begins at the same place: a Conditioned Prediction. This is the node that takes an ordinary CLIP-encoded CONDITIONING and turns it into a PREDICTION - the pack's internal type that the sampler can actually evaluate. No Conditioned Prediction, no custom guidance. It's the front door.

What it is

In a normal ComfyUI workflow, your prompt goes from CLIP Text Encode (Prompt) into the KSampler, and the sampler does the model math. This pack's sampler, Sample Predictions, doesn't take prompts at all - it takes a PREDICTION graph. Conditioned Prediction is the bridge: it wraps one conditioning, gives it a name, and exposes it as something the prediction nodes can combine, switch, and interpolate.

Inputs:

  • conditioning (CONDITIONING) - the output of a CLIP Text Encode node. Any conditioning works: a full prompt, an empty prompt, a negative.
  • name (STRING, default "positive") - an arbitrary label you choose.

Output: a prediction.

Why the name matters more than it looks

Names are free-form, but they're load-bearing. The pack uses them to deduplicate work and to keep the graph sane, and the README gives the standard trio: positive, negative, empty. Two rules to follow:

  • Make them unique. If two Conditioned Predictions share a name with different conditioning, the pack throws a RuntimeError - "Conditioning 'X' is not unique." You'll see it the moment you copy-paste a second prompt node without renaming it.
  • Be consistent. The names don't have to be these three, but if you call your main prompt positive in one node and pos in another, downstream nodes can't tell them apart. The README also notes the names "may eventually interact with ControlNet if/when it's implemented" - so pick names you'd be happy to see in a log.

How it works

Each sampling step, the node runs the model once with its conditioning and hands the result downstream. It's built on a caching predictor, which means the conditioning is evaluated once per step no matter how many nodes consume it - so your graph can reference positive in three different combinations without paying for three model runs. That's a quiet but important reason the pack's chains stay affordable.

A minimal first graph

The README's step-by-step is the shortest path to a working custom prediction:

  1. Sample Predictions is your sampler.
  2. sampler comes from KSamplerSelect (under sampling > custom_sampling > samplers).
  3. sigmas comes from BasicScheduler (under sampling > custom_sampling > schedulers - not the "sigmas" menu).
  4. CLIP Text EncodeConditioned Prediction for each prompt you want (positive, negative, empty).
  5. Chain them through the pack's other prediction nodes, then into noise_prediction.

Installing it

Ships in the ComfyUI-Prediction pack by @RedHotTensors (Project RedRocket). ComfyUI Manager → search "ComfyUI-Prediction", or:

cd ComfyUI/custom_nodes
git clone https://github.com/redhottensors/ComfyUI-Prediction

Restart ComfyUI. No extra pip dependencies or model downloads. It's under Add Node > sampling > prediction.

Common issues

  • "Conditioning is not unique" - duplicate names on two nodes. Rename one.
  • Wrong sampler. You still need Sample Predictions (not a plain KSampler) for the PREDICTION to be consumed.
  • ControlNet and advanced conditioning features aren't supported in the pack yet - regional prompting is "totally untested" per the README, so don't build your pipeline on it.
Categorysampling/prediction

Inputs (2)

NameTypeDefaultDescription
conditioningCONDITIONING
nameSTRINGpositive

Outputs (1)

NameTypeDescription
predictionPREDICTION