hidream-o1 / HiDream-O1-Image / createImage

HiDream-O1 is the weird one in this pack, and the weirdness is the point. It's an 8B pixel-space model - no VAE, no separate text encoder, one Pixel-level Unified Transformer that natively handles raw pixels and text in a single token space, at up to 2048×2048. The community's verdict was "the best recursive editor of 2026 and the least used." Civitai Image Gen (hidream-o1 / HiDream-O1-Image / createImage) runs it on the cloud, which sidesteps the two things that killed it locally: the "minutes per image" speed and the missing-VAE/CLIP confusion that tripped up half the local installs.

What it is

The text-to-image node for the hidream-o1 ecosystem. Required: prompt. Optional: output_format, image_metadata, negative_prompt, width / height (default 2048 - this model's native resolution, not optional per the KB's facts; the range bottoms out at 64 but you're wasting it below ~1MP), steps (default 40, up to 150), cfg_scale (default 5), seed, quantity (1–4), checkpoint_model (CIVITAI_AIR socket - note the field name; HiDream ships an -Image-Dev variant you can pin here), loras, api_config.

Outputs: images, errors, workflow_id, raw_json.

Notice what's missing: no sampler/scheduler menus. The hidream-o1 node doesn't expose them - the engine handles sampling its way, which is one fewer thing to fiddle with and one fewer thing to get wrong.

Why it matters

The KB's HiDream writeup is clear that its real superpower is recursive editing without degradation - because it never round-trips through a lossy latent, iterating on an image doesn't compound compression loss. This node only exposes createImage, but the architecture is the same one behind that editing praise. The honest caveats from the same essay: it's slow (minutes per image), it went quiet fast in the community, and there's no LoRA ecosystem to speak of.

Install & gotchas

Standard pack install - ComfyUI Manager (search Civitai Comfy Nodes), comfy node registry-install civitai-comfy-nodes, or git clone + pip install -r requirements.txt. Auth via CIVITAI_API_TOKEN, OAuth, or a Civitai Auth node.

The traps, specific to this model:

1. The 2048 default is not decorative. HiDream's native resolution is 2048² and it's slow to render there - on the cloud that's a metered job that takes a while, so budget time and Buzz for a real run. The timeout_minutes on your Civitai Auth node (default 30) may need raising for 2048 renders.
2. No VAE/CLIP confusion here, because there's nothing to confuse. Locally, people tripped over HiDream having neither; on the cloud that whole class of error vanishes - one of the genuine advantages of this being a hosted node.
3. quantity caps at 4. The engine's batch limit; each image is billed, and slow ones cost more wall-clock even if the Buzz is flat.

One honest take: this is the curiosity node of the pack - the one you run to understand what pixel-space generation actually buys you, without the local install pain. If your workflow is about iterating on an image over many passes, HiDream's no-degradation story is worth exploring. If you just want pretty images fast, pick a different engine and save the wait.