HiDream O1 Conditioning

If you came here looking for a ClipTextEncode node, stop. HiDream O1 has no separate text encoder - the Qwen3-VL backbone inside the model reads raw text directly, same way it reads pixels. What this node does is package your prompt into the little conditioning object the HiDream O1 Sampler is waiting for. That's the whole job, and it's a two-minute node, which is fine.

What it does

You type a prompt, it returns a conditioning object (type HIDREAM_O1_CONDITIONING) that plugs into the sampler's conditioning input. Three fields, all plain text:

• prompt - the instruction. Defaults to a cinematic portrait prompt. For this model, plain natural language works well; it's literally built to read sentences, and the upstream system prompt even suggests spelling out visible features instead of relying on names.
• negative_prompt - only does anything in full mode when guidance_scale is above 1.0. Dev mode ignores CFG entirely, so on a Dev model this box is decorative. Put something in it anyway - if you ever swap to Full, it starts working.
• enhanced_prompt - the interesting one. It's an optional string input, not a textbox. When you connect something to it and it's non-empty, it silently replaces whatever's in the prompt box. That's the hook for ComfyUI's bundled Prompt Enhance subgraph (the generic Gemini-based one) or any prompt-enhancer node you already use. Nice for A/B testing a polished prompt against your own draft without rewiring anything.

How it works

Mechanically it's a wrapper: it validates which prompt is active, bundles prompt/negative_prompt into a dict, and passes that along. The actual encoding happens inside the sampler when the model's vision-language path tokenizes your sentence. So don't expect this node to show embeddings or hidden states - it's plumbing, and the interesting parts are upstream (what you write) and downstream (how the sampler uses it).

Where people get confused

The absence of a text encoder gets reported as a broken workflow constantly - people see a conditioning-type input and go hunting for the encoder node that produces it, the way they would for SDXL. You don't need one. This node is the conditioning stage of a pixel-space model.

One real gotcha with enhanced_prompt: it only takes over when the connected string is non-empty, and the sampler cares about the resulting object, not the textbox. If your enhancer returns a blank or whitespace string you'll silently fall back to the plain prompt. That's usually what you want, but it's easy to misread as the node "ignoring" your enhancement.

Wiring it

HiDream O1 Conditioning ──conditioning──▶ HiDream O1 Sampler

That's it. Text goes in, sampler runs, image comes out. The other half of the model's interface - reference images - doesn't touch this node at all; that's the sampler's image_1 through image_12 inputs.