Apply DreamO

DreamO is ByteDance's unified image-customization framework: one Flux-based model that does subject transfer, face identity, and style transfer, depending on how you condition it. The other two nodes in this pack get the references ready. ApplyDreamO is the one that does the work. Its name undersells it - it's not applying a LoRA, it's patching Flux so your reference latents are consumed at all. Without it, everything DreamORefEncode produced goes nowhere.

You feed it your Flux dev MODEL (after the DreamO and flux-turbo LoRAs are stacked on) and at least one reference LATENT, and it hands you back a patched MODEL that you send to the sampler. That's the whole contract: model in, model out.

How it works

The mechanism is the same trick that made PuLID-Flux work, and the pack credits ComfyUI_PuLID_Flux_ll for it. ApplyDreamO clones your model, loads a small embedding.safetensors (auto-downloaded into ComfyUI/models/dreamo), and stashes your reference latents in the model's transformer_options. Then it registers an outer-sampling wrapper that swaps Flux's forward functions for DreamO's versions on the way in and restores them when sampling finishes.

Inside those swapped forwards, the reference latents get concatenated into the image token sequence alongside your noisy latent. Two tiny learned embeddings make it legible to the model: a task embedding (tells it whether this run is ip/id/style) and an index embedding (marks each reference's position). The code even guards against double-patching - connect a second ApplyDreamO in series and the wrapper is only added once.

The inputs and outputs that matter

• model - your Flux dev MODEL (fp8 is fine), LoRAs already applied.
• ref1 (required) - a LATENT from DreamORefEncode.
• ref2, ref3 (optional) - two more references if you want them.
• Output: MODEL - wire this into the sampler, not the base model. The most common mistake is feeding the unpatched model to KSampler and wondering why nothing happened.

One required reference and up to three total is the real power move: a face ref in ref1 for identity plus a style ref in ref2, and DreamO mixes both. The shipped v1.1 workflow does exactly one, but the slots are there.

The gotcha that catches everyone

You must set cfg=1 in the sampler. The pack's README says it plainly: the code does not implement true CFG, so DreamO's reference conditioning gets confused (and the image blows out) at any higher guidance. The negative prompt is effectively inert. The bundled workflow runs 12 steps, euler, simple, cfg 1 - start there and only move step count.

Install

From ComfyUI Manager, search "DreamO" and install ComfyUI-DreamO, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ToTheBeginning/ComfyUI-DreamO.git
pip install -r requirements.txt

Then restart ComfyUI. Two install traps: the requirements pull in the forked facexlib, not the original (install the wrong one and you get face parsing errors), and the pack is built against a mid-2025 ComfyUI - an old ComfyUI can throw compatibility issues. Model-wise you need FLUX.1-dev (bf16 or fp8), t5xxl, clip_l and the ae VAE, plus the DreamO LoRAs and flux-turbo.safetensors in models/loras. The embedding.safetensors this node needs downloads itself.

Troubleshooting

DreamO at 1024 is a memory hog - the reference preprocessing on top of Flux pushes many cards over. People report OOMs that no other workflow gives them; fp8 Flux plus ComfyUI's --lowvram/--medvram flags is the usual fix. And if you upgraded to the pack's v1.1 with an old saved workflow, expect blank images until you rebuild the node graph - v1.1 changed DreamORefEncode's inputs, which breaks stale workflows.