HiDream-I1 Dev

HiDream-I1 was April 2025's big open release - the first credible MIT-licensed challenger to Flux, and the community's verdict on it never really moved: excellent at following instructions, far too heavy for consumer hardware. It's a 17B sparse diffusion transformer with two text encoders (T5-XXL plus Llama-3.1-8B-Instruct), and that's where its famous prompt adherence came from and also where its weight problem came from. Running it locally meant quantizing it down to fit a 16GB card, and it faded as people decided that wasn't worth it. This node serves HiDream-I1 Dev from the cloud, which neatly solves the one thing that killed it locally: you get the prompt-following without the 17B.

Note the version caution from the KB: don't confuse I1 with HiDream-O1, a different 8B architecture from a year later. This node is I1 Dev, the model with the reputation for instruction-following and typography - which is why people still reach for it even after newer models landed.

How it works

Standard image-node pattern in this pack: an imageInference request to Runware, returned as a native IMAGE tensor. Where this node differs from the FLUX nodes is the default posture: steps defaults to 28 (it's a plain INT here, not a gate) and CFGScale is an off-by-default gate - the model's own default guidance applies unless you flip the toggle. HiDream-I1 wants a decent step count; unlike a distilled model, don't try to run it at 4 steps.

Inputs that matter

• positivePrompt (required) - this is the star. HiDream-I1's whole reputation is following complex, instruction-heavy prompts - layered directions, specific compositions, fine-grained detail. This is the node to reach for when a prompt has stages and other models round them off.
• negativePrompt - actually useful here: the tooltip notes it's ignored when CFG ≤ 1, but I1's guidance is a real lever, so negative engineering can work the way SDXL users expect.
• width / height - 128–2048px in 16px steps, default 1024².
• steps - default 28, range 1+. That's a good starting point; 28–35 is the comfortable band for I1-quality output. Fewer = faster/cheaper but noticeably softer.
• CFGScale - gate + CFGScale_value. Off = model default. If your output ignores the prompt, flip the gate on and raise it; if it's overcooked, lower it.
• scheduler - 76 options; (default) is fine.
• lora - the Runware LoRA builder socket. I1's LoRA ecosystem existed and the MIT license makes it commercially usable - if you have a model ID, this is the slot.
• watermark / acceleratorOptions - the pack's watermark and acceleration builders.
• numberResults (1–20), outputFormat (JPG/PNG/WEBP), outputQuality, safety, ttl - the usual set.

Single output: image → Preview or Save.

Installing

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

Or ComfyUI Manager → search Runware → install → restart. API key via Settings, RUNWARE_API_KEY, or runware auth login. No weights to download - the 17B stays on Runware's side.

The honest take

Is this the model you should default to in 2026? Probably not - newer, lighter models have closed the gap, and the cloud round-trip means you're paying per call for something that was always a bit of a specialist. But "give me a model that actually does what I write" is a recurring need, and I1 Dev is still one of the best at it. The MIT license also makes it the sane commercial pick if your cloud pipeline needs a license-clean image model - no non-commercial gotchas like the FLUX tiers. Just don't crank steps to 50 "for quality" on a paid cloud call; 28 is the model's comfort zone and extra steps mostly cost money. If your prompt keeps getting ignored elsewhere, this is the node that will make you feel heard.