Flux.1 Krea dev — Setup and Parameters

The practical core in one sentence: Krea dev runs in exactly the place Flux.1 dev ran, without anything else changing. The DualCLIPLoader stays on flux, the same two encoders — CLIP-L and T5XXL — stay loaded, the guidance in CLIPTextEncodeFlux stays at 3.5–4.0, the SamplerCustomAdvanced stays at euler / simple / 20–25 steps, the sampler cfg stays at 1, the one-megapixel resolution rules stay the same. None of it gets touched. Krea dev is guidance-distilled like Flux.1 dev — same regime, same values.

What changes is one file. The Krea weights belong in the same ComfyUI checkpoints folder where your Flux.1 dev model already sits. Then you enter its filename — including .safetensors — into the Checkpoint field of the RAY-L panel. That's the entire intervention: one field.

The ControlNet stays untouched as well. The InstantX Flux Canny (flux-canny-instantx.safetensors) works with Krea dev exactly as it does with dev, because Krea is Flux.1-dev-compatible and uses the same ControlNet regime. ControlNet strength, Canny thresholds, seed logic — everything stays as described in 2.3.2.

That the swap works so seamlessly while the aesthetic still diverges is explained by its origin. Black Forest Labs supplied Krea with a pre-trained, guidance-distilled 12-billion-parameter model called flux-dev-raw — the same raw base from which Flux.1 dev also emerges. On that base, Krea ran a pure aesthetic post-training, with the stated goal of producing more realistic and less oversaturated images. Flux.1 dev and Krea dev are siblings from the same raw base that diverge only in post-training. That's why the pipeline stays identical — same encoders, same node structure — while the image itself reads differently.

Black Forest Labs calls the model "opinionated" itself: a text-to-image model with a deliberately distinct aesthetic stance rather than a neutral middle, aimed at avoiding the oversaturated "AI look." In the maker's own preference tests, Krea dev lands on a level with the closed solution FLUX1.1 pro. That's a vendor claim, not an independent result, and should be read as such. The dependable statement about the difference comes not from the datasheet but from the direct comparison on your own subject — and that starts with the question of how this aesthetic gets along with whatever LoRAs you hand it.

Because the architecture is identical, the same holds for LoRAs as for the ControlNet: a LoRA trained for Flux.1 dev loads and works on Krea dev too — and vice versa. Technically the two models are interchangeable. More interesting than whether a LoRA loads is how well it gets along with Krea's aesthetic.

Krea's aesthetic isn't a setting you dial away; it's trained into the weights — a force the image is pulled toward. A LoRA either works with that force or against it. A character or identity LoRA teaches content — facial structure, who the person is — and therefore lies across the base's aesthetic; it rides along on both models and stays robust, because it takes nothing away from the Krea look. A style LoRA, by contrast, teaches exactly what Krea already brings: the look itself. Here two aesthetics overlap, and the same style LoRA can land differently on dev and on Krea — on one base it paints onto an empty surface, on the other against a handwriting already there.

This can be checked directly with a character LoRA. Train the identity of a synthetic person and render it with an identical seed and prompt once on dev and once on Krea, and the person should stay the same — the identity comes from the LoRA — while the look differs, because it comes from the base: the same person, two aesthetics. It's also the cleanest method for the following section: hold the subject constant via a LoRA, and any visible difference is attributable to the base aesthetic alone and nothing else.

The comparison is only honest when the model alone varies: the same seed, the same prompt, the same guidance, the same sampler parameters, the same ControlNet edge. That's exactly why everything above stays unchanged — only then is a visible difference attributable to the model and not to a shifted control.

Testing runs along four dimensions that matter for holding up next to professional advertising photography — not along "looks more impressive." The verdicts below stand only once they've held across the series.

One comparison is not a series. Whatever is claimed here as a difference must have held across several seeds and several subjects — a single image pair pointing one way is an isolated case, not a property of the model.

Krea dev is under the same license as Flux.1 dev — the FLUX.1 dev non-commercial license. That is not the Apache 2.0 license of Flux.2 Klein 4B. For purely local testing and research it's immaterial; the moment the generated images are used commercially, the separate commercial license via the BFL licensing portal is required.

The choice and the licensing of the model rest with the user. RAY-L ships no model and prescribes none: like ComfyUI, it's a frame that can use different models. Which one is right for a given use — and under which license it's used — the user decides.

Krea dev costs nothing extra over Flux.1 dev. It's the same 12-billion-parameter model with the same VRAM demand and the same speed — the encoder and sampler requirements from 2.3.2 apply unchanged. The decision between dev and Krea is therefore not a hardware question but an aesthetic one.

The switch itself costs nothing and is reversible: reset one field, and the next run is dev again. Precisely this frictionlessness is the reason to place Krea dev where dev stood before — not as a new model with its own setup, but as the more photographic default of the same path.