AI · Prompt Architecture
Prompts for Flux
Two encoders, two fields — and why T5 logic is the foundation for all future models.
Two encoders, two fields
Flux.1 dev works differently from SDXL — not with one encoder but two simultaneously: CLIP-L and T5XXL. Both process your text in parallel, in completely different ways. That's why the ComfyUI node CLIPTextEncodeFlux has two separate input fields — and why it makes a measurable difference what you put in which field.
The basic rule:
This isn't a stylistic detail. Giving both fields the same text — in any format — results in a substantial loss of image quality and prompt precision. CLIP-L expects lists, T5XXL expects language. Feeding both sentences, or both keywords, costs in either case.
clip_l — the keyword list
The clip_l field works according to the same logic as an SDXL prompt — with one caveat: weighting syntax ((word:1.3)) works considerably weaker here than in pure SDXL, because T5XXL handles most of the semantic control. Order still counts — earlier tokens are weighted more heavily.
Content: the most important concepts of your image idea, compact and prioritized.
Scandinavian kitchen interior, minimalist Nordic design, white upper cabinets, light oak wood lower cabinets and island, gray stone countertops, floor-to-ceiling windows, soft natural daylight, photorealistic, editorial photography
The 77-token limit of CLIP-L applies here too — keep it compact.
t5xxl — the full scene description
The t5xxl field understands real language. Here you don't write a list — you describe an image the way you'd explain it to an assistant who's going to photograph it.
Two things T5 actually processes differently from CLIP:
Relationships between elements
"The streetlight casts a rim light through the fog" is for T5 a statement about a relationship — light source, effect, medium, all in one sentence. CLIP would read this as "streetlight", "rim light", "fog" as three unconnected concepts.
Syntactic prominence
What is the subject of a sentence gets more weight than what appears in a subordinate clause. If an element is missing or weak in the result — check whether it has syntactic prominence in your text or is only mentioned in passing.
Example: "natural daylight that pours in through floor-to-ceiling windows" — the windows are secondary to the light here. Result: light was rendered, windows weren't. Fix: give them their own sentence.
A bright, spacious Scandinavian kitchen is photographed from eye level with a 35mm lens. Floor-to-ceiling windows span the back wall, flooding the room with natural daylight. The cabinetry combines matte white upper cabinets with light oak wood lower cabinets and a matching island, while the gray stone countertops reflect the soft light realistically. A single ceramic vase sits on an otherwise uncluttered counter. The composition has strong depth and realistic proportions, shot in the style of an Architectural Digest editorial feature.
Rule of thumb: what you really want to see stands as its own sentence — not as a relative clause, not as a prepositional phrase.
Two materials need a relationship
This rule applies with Flux just as it does with SDXL — but with Flux you have a better tool for implementing it: the T5 sentence.
Instead of
matte white cabinetry, light oak wood fronts
With explicit spatial assignment in the t5xxl field
The cabinetry combines matte white upper cabinets with light oak wood lower cabinets and a matching island.
CLIP can only approximate relationships through token order and weighting. T5 understands "combines... with..." as a genuine structural statement. This is one of the cases where Flux has a clear advantage over SDXL — not in overall result quality, but in the precision of complex spatial descriptions.
No negative prompt
With Flux.1 dev there is no working negative prompt — this isn't an interface limitation, but a consequence of the model architecture. Flux is a "guidance-distilled" model: the classic mechanism on which negative prompts are based (Classifier-Free Guidance) was already incorporated during training and is no longer available as a separate control channel.
What works instead: rephrase unwanted elements positively.
| Negative reflex (doesn't work) | Positive rephrasing (works) |
|---|---|
| no clutter | uncluttered surfaces, minimal decoration |
| not blurry | sharp focus, crisp detail |
| no people | empty room, no figures |
| avoid harsh shadows | soft, diffused lighting |
This rephrasing is often more precise than a negative prompt ever was — because you're describing the image you want, not the one you don't want.
guidance — the third value in CLIPTextEncodeFlux
The CLIPTextEncodeFlux node has a third value alongside the two text fields: guidance. This isn't CFG in the classical sense — it's an internal scaling factor that determines how strongly the model follows the combined conditioning.
This value is not the same as cfg in the KSampler. The KSampler cfg value must be set to 1 for Flux.1 dev — any higher value degrades the result because it works against the built-in guidance distillation. This is one of the most common mistakes when starting out with Flux.
The complete Flux.1 dev workflow at a glance
clip_l (keyword list, max. 77 tokens): [Subject, Composition, Environment, Light, Material, Atmosphere, Style] — comma-separated, priority determines order t5xxl (full sentences, up to ~512 tokens): Complete scene description with explicit relationships between elements. Important elements as their own sentences. Spatial assignments written out in full. guidance (in CLIPTextEncodeFlux): 3.5–4.0 (standard) KSampler values for Flux.1 dev: cfg: 1 · steps: 20–25 · sampler: euler · scheduler: simple
Flux.2 — where things are heading
Flux.2 dev takes another step: the previous two-encoder architecture (CLIP-L + T5XXL) has been replaced by a single, large multimodal language model that handles text embedding, prompt upsampling, and safety filtering simultaneously. No separate CLIP-L, no separate two-field interface.
This confirms the tendency already visible in the foundation article: models are moving away from CLIP logic and toward genuine language understanding. The T5 rule of thumb — full sentences, explicit relationships, syntactic prominence — remains the right foundation for Flux.2 as well. Only now you apply it not in a separate field, but in a single input field.
The prompt logic you learned for t5xxl transfers directly to Flux.2.
Portability — a summary
| Target model | Source |
|---|---|
| SDXL (Juggernaut XL) | clip_l field, add weighting where needed |
| Flux.1 dev | both fields together |
| Flux.2 / SD 3.5 / Ideogram 4 | t5xxl field, directly transferable |
This is more than a practical shortcut. Learning to write precise, relationship-rich sentences in the t5xxl field — explicit spatial assignments, syntactically prominent main elements, fully described lighting situations — builds a competence that holds regardless of the model.
All modern models with language understanding — Flux.2, SD 3.5, Ideogram 4, and whatever comes next — expect exactly this kind of wording. They differ in architecture, training weights, and strengths, but not in their basic logic: they read language, not lists.
The clip_l field, by contrast, is more specific: it serves CLIP-based encoders whose importance shrinks with each model generation. It remains relevant as long as SDXL and Flux.1 are in use — but it's not a foundation for the future, it's a tool for the present.
The practical consequence: invest more care in the t5xxl field. Not because clip_l is unimportant — but because the quality of your t5xxl formulation determines how well you work with every model that comes after Flux.1.