FLUX / Black Forest Labs

1. Introduction

1.1 Platform Overview

Black Forest Labs (BFL), headquartered in Germany, was founded by former core members of the Stable Diffusion team and is this group's representative of the "open weights + community workflows" approach. Its product line spans FLUX.1 (released in 2024, including dev / schnell / pro) and the current FLUX.2 series.

The key to understanding FLUX is recognizing that it is not a platform, but a set of weights plus an API. Unlike Midjourney (web editor), Leonardo (multi-model aggregation + team workbench), and Runway (all-in-one film/video editor), BFL officially offers only: one API, one Playground, and a set of open weights. It has no asset library, no project space, no brand asset pack, and no team seats.

This "thin platform" strategy is not a lack of capability but a clear division of engineering labor: BFL is responsible for making the models commercially usable, reproducible, and clearly licensed; orchestration, state, assets, and evaluation are carried by the upstream ecosystem (ComfyUI, Diffusers, aggregator platforms). In the Harness six-layer model, this means FLUX's official platform layer mainly falls on L1 (context contract), L3 (model routing and reproducibility switches), L5 (MP metering), and L6 (license tiers), while L2's tool ecosystem and L4's asset persistence are borne by the community.

1.2 FLUX.2 Model Matrix

The following table is the model matrix given directly in the official docs (very high confidence) and is central to understanding FLUX.2's engineering positioning:

Three official facts that must be noted as supplementary:

1. Structured Prompting: officially supports the JSON fields subject / background / lighting / style / camera_angle / composition. This is this group's only prompt structure contract defined officially.
2. Fixed snapshot endpoints: flux-2-pro-preview / flux-2-klein-9b-preview carry the latest improvements; flux-2-pro / flux-2-klein-9b are fixed snapshots, for workflows that need reproducibility and compliant model stability. This is one of the most important Harness design signals in this group.
3. [klein] does no prompt upsampling; the official requirement is to write detailed, descriptive prompts — i.e., context quality is the caller's responsibility.

1.3 Open Distribution & License Tiers

FLUX.2's license tiers are the clearest in this group:

Third-party cloud prices (reference, non-official): Replicate Pro $0.015 + $0.015/MP; fal.ai Pro $0.03 for the first MP + $0.015 for subsequent MPs; Replicate Dev $0.012/MP.

Self-hosted commercial licensing (third-party figures, $999/month including 100,000 images/month, $0.01/image beyond) is a low-confidence single source, marked [To be verified], and must not be used as the basis for procurement.

2. Glossary

2.1 General AI Image Terminology

2.2 FLUX / BFL-Specific Terminology

2.3 Terminology for Try-On & Face-Swap

3. Feature Description

3.1 Core Capabilities

• Text-to-image, image-to-image, and multi-reference image editing (up to 8~10 source images).
• Multi-reference photorealistic compositing: in official showcase scenarios, 8 consistent characters can be maintained in a single fashion shoot.
• Pose guidance, exact brand-color control, typesetting and text rendering, infographics, and Grounding Search ([max]-exclusive).
• Open weights: [klein] 4B (Apache 2.0) is commercially usable and locally deployable, requiring only about 13GB VRAM to run.
• Ecosystem: directly loadable in ComfyUI / Diffusers; aggregated by Adobe Firefly, Leonardo.ai, LiblibAI, and others.

3.2 Structured Prompting Contract

FLUX.2 officially supports organizing prompts via JSON fields:

Its Harness significance: most platforms treat the prompt as a single natural-language string, with parameters hidden in CLI-style flags such as --ar and --stylize; FLUX.2 instead structures the prompt itself into serializable fields. This yields three direct engineering benefits:

1. Programmable: fields can be auto-populated by upstream systems (PIM, brand guideline libraries, CMS) without string concatenation.
2. Diffable: the context differences between two generations can be compared field by field, easing regression localization.
3. Validatable: missing fields can be caught by static checks before invocation.

Combined with the official statement that "[klein] does no prompt upsampling and requires detailed descriptive prompts", BFL's stance becomes clear: context quality is the caller's responsibility; the platform does not back you up. This contrasts with platforms that auto-expand prompts — those are easier to use but introduce uncontrollable implicit rewriting.

3.3 Exact Color Control

Exact Color Control allows directly specifying a hex brand color and matching it precisely. Official examples include gradient colors (#02eb3c → #edfa3c) and the precise reproduction of a 6-color eyeshadow palette.

For brand marketing scenarios, the value of this capability lies in upgrading the "brand color" from a prompt adjective ("brand green") to a verifiable numeric contract (specifying a hex). In Harness terms, this converts a vague dimension of L1 context into an assertable parameter, enabling automated verification — for example, a check script that compares the dominant color of the output image against the target hex for color difference.

3.4 Ecosystem Integration

4. Platform Architecture

图 4-1｜FLUX.2 薄平台架构：官方层 × 社区层三层栈

数据来源：基于本文分析绘制的示意图。

4.1 Official API Layer

The architecture of the BFL official API is extremely minimal: a set of endpoints named by model, priced per MP, with an output limit of 4MP. Its most noteworthy design is the dichotomy of preview endpoints and fixed snapshot endpoints:

flux-2-pro-preview        → 承载最新改进，输出可能随时间变化
flux-2-pro                → 固定快照，权重不变，跨时间输出一致
flux-2-klein-9b-preview   → 同上，klein 线
flux-2-klein-9b           → 固定快照

This dichotomy turns a usually hidden engineering problem — "will the model change when I'm not looking" — into an explicit switch. For regulated industries (finance, pharma, government) and production pipelines that need regression verification, fixed snapshot endpoints are a hard requirement.

4.2 Open-Weight Layer

The open-weight layer is the fundamental difference between FLUX and closed-source platforms. [klein] 4B and Base 4B are released under Apache 2.0, meaning:

• Commercially usable, modifiable, and redistributable.
• Locally deployable, keeping data within the intranet.
• Fine-tunable and LoRA-trainable, freezing characters, styles, and brands into private weights.
• Runs on a consumer GPU with ~13GB VRAM (4-step distillation + 4B parameters).

[klein] 9B and Base 9B go the NCL (non-commercial) route; [dev] is free and non-commercial. The business logic of this tiering is clear: open the smallest usable model for free to occupy the ecosystem, and keep high-quality, high-resolution capabilities in the paid API.

4.3 Community-Supported Layer

Because the official platform layer is very thin, the actual orchestration, assets, and workflows are carried by the community layer, centered on ComfyUI:

• L2 tool layer: each capability is a node (LoadImage, KSampler, VAE Decode, SaveImage, etc.).
• L3 orchestration layer: a workflow is a JSON graph that can be put under version control, run node by node, and executed programmatically via the Comfy SDK.
• L4 state layer: community LoRA and workflow template files handle the persistence of character and style assets.

This is a typical sample of the group's "thinnest official platform layer, thickest community-supported layer", and the starkest contrast with closed-source products that "build Harness into the platform".

5. Harness Design

5.1 Six-Layer Capability Overview

5.2 L1 Context Engineering Layer

FLUX.2's L1 consists of four types of context sources, all explicitly defined by the official docs:

1. Structured prompting (six JSON fields).
2. Multi-reference images: [klein] up to 4; [pro] / [flex] / [max] up to 8 (API) or 10 (Playground); the official showcase displays a fashion shoot with 8 consistent characters.
3. hex brand color: precise numeric injection.
4. Grounding Search ([max]-exclusive): incorporates real-time retrieval results into the generation context, for scenarios that need factual correctness (match scores, real-time weather, historical events).

The official docs also make clear that [klein] does no prompt upsampling and that callers must write detailed, descriptive prompts. The Harness implication of this constraint is: context quality is the caller's responsibility, and the platform performs no implicit rewriting, so the context is fully auditable — the prompt the caller sees is exactly what the model receives. For compliance scenarios that need a "burden-of-proof shift" defense (see the Beijing Internet Court ruling in Section 7.4), this property has direct legal value.

5.3 L2 Tools & Execution Layer

Official layer: generation, multi-reference editing, typesetting, and search are all exposed as API endpoints. The tool forms are extremely minimal, with no tool-registration mechanism and no Function Calling ecosystem.

Community layer: ComfyUI and Diffusers wrap each capability as a node, and nodes can be freely published by third-party developers (such as comfyui-kjnodes, comfyui_essentials). This constitutes a de facto open tool-registration ecosystem — even though it is not operated by BFL.

Therefore, FLUX's L2 should be understood as "the official side provides primitives, the community provides the toolset".

5.4 L3 Orchestration & Control Layer

FLUX.2's L3 has two levels:

Official layer: model selection is orchestration. [klein] (real-time, high volume) → [pro] (production-grade) → [flex] (typesetting) → [max] (highest quality + retrieval) forms a clear routing strategy. Callers choose a model by task type, which is itself an orchestration decision. Combined with the preview/fixed-snapshot dichotomy, "whether to be reproducible" becomes an explicit switch.

Community layer: workflow as JSON graph. ComfyUI serializes the entire generation pipeline into JSON, making it version-controllable, runnable node by node, and executable via SDK. This is the only form in this group that turns orchestration artifacts into version-controllable Artifacts.

The division of labor between the official and community layers is clearest here: BFL defines "which model to use", and the community defines "in what order to do things".

5.5 L4 Memory & State Layer

The official layer has almost no L4. No asset library, no project space, no asset pack, no team seats. The only "memory" exists at the weight level: Base variants are designed for fine-tuning and LoRA training, so callers can freeze characters, styles, and brands into private weights.

The community layer shoulders L4: community LoRA files, workflow templates, and self-hosted storage. This means L4 reliability is determined by the caller's own engineering practice — no platform guarantees your assets won't be lost or your versions won't get mixed up.

The practical implication for buyers: choosing the FLUX route means choosing to build L4 yourself. For teams with engineering capability this is freedom; for teams without it, it is risk.

5.6 L5 Evaluation & Observability Layer

• Cost observability: unified MP metering with a 4MP output limit, so the upper bound of per-image cost is computable (see Section 6.3).
• Reproducibility: fixed snapshot endpoints are the only "time-dimensional regression guarantee" provided by a platform in this group.
• Quality evaluation: no official Eval Set or Golden Dataset seen. Quality evaluation must rely on third-party public benchmarks (such as GenEval, DPG-Bench) or self-built evaluation sets.

Notably, the open-weight route has a unique L5 advantage: it can lock weights locally and build a private regression set, unaffected by platform model updates. This is two sides of the same coin as fixed snapshot endpoints — the former locks via your own control, the latter via the platform.

5.7 L6 Governance & Security Layer

FLUX.2's L6 is a strength in this group, but strong in licensing rather than content:

• Very clear license tiers: Apache 2.0 (commercial use allowed) / NCL (non-commercial) / closed API / [dev] non-commercial. This is the clearest intellectual-property boundary in this group.
• Self-hosted commercial license: third-party figures of ~$999/month (including 100,000 images/month, $0.01/image beyond), low confidence.
• Content safety: no public statement on content rewriting or moderation for [klein]. This must be stated clearly: when deploying open weights yourself, the content-moderation responsibility rests entirely with the deployer, and the platform provides no guardrails.

This contrasts with closed-source platforms: closed-source platforms provide moderation (but interceptions are usually still billed, and the process is opaque), while open weights provide freedom (but guardrails must be built yourself).

5.8 Division of Responsibilities Between Official & Community Layers

This is the comparison this article most needs to spell out. The table below splits the six-layer capabilities by "who is responsible":

To sum up in one sentence: the FLUX route trades a "thin platform layer" for the caller's freedom and auditability. It suits teams capable of building the upper Harness layers themselves, not teams that want out-of-the-box use.

5.9 Maturity Assessment

FLUX.2 belongs to the "strong primitives + weak platform + strong ecosystem" form: L1 is strongest (the group's only official structured-prompting contract + hex color + Grounding), L2 is medium (thin official, thick community), L3 is strong (model routing + reproducibility switch), L4 is medium (weights layer only, no platform abstraction), L5 is medium (cost measurable, reproducibility guaranteed, quality evaluation missing), and L6 is strong (clear licensing, but content safety is your own).

Compared with Qwen-Image, another open-weight representative in this group, the key difference lies in the direction of L4: FLUX.2 sticks with Apache 2.0 for [klein] 4B, while Qwen-Image 3.0 has turned closed-source. This "open vs. closed" tension is one of the most important cross-cutting topics in this group.

6. Real-World Cases

6.1 Official Showcase Scenarios

The scenarios showcased officially by BFL (not customer cases) include:

• 8 consistent characters in a fashion shoot.
• Product-photography-quality generation.
• Infographics and data visualization.
• Magazine cover typesetting.
• Car advertisement slogans.
• Precise brand-color matching (gradient #02eb3c → #edfa3c, 6-color eyeshadow palette).

These are capability demos, not customer performance data, and must not be conflated when writing or shortlisting.

6.2 Aggregators & Community Usage

• Adobe Firefly: FLUX.2 pro usable directly within the platform (medium confidence).
• Leonardo.ai: provides Flux.2 Pro model switching (medium confidence).
• LiblibAI 2.0: open-source model aggregation + ComfyUI (medium confidence).
• Community: ComfyUI / Diffusers local pipelines and LoRA fine-tuning (qualitative fact, no quantitative data).

Vendor cases with quantified performance data: none found. Under this group's uniform discipline, vague phrasing such as "widely used in e-commerce and design" must not be substituted.

6.3 Cost Conversion Examples

Based on official prices, deterministic conversions can be made (MP conversion: 1024×1024 ≈ 1.05MP; 2048×1024 ≈ 2.1MP):

Per-image cost at 1024×1024 (≈1.05MP)

Per-image cost at 2048×1024 (≈2.1MP)

Three engineering conclusions:

1. [klein]'s cost is almost independent of resolution (dominated by the $0.014 base fee), so its advantage over [pro] / [flex] widens in high-resolution batch scenarios. At 1.05MP klein is about 48% of pro; at 2.1MP it drops to about 26%.
2. [flex] is a typesetting-specialized tier at 2× the unit price of [pro] and should not be used as a general-purpose generation tier.
3. When horizontally comparing prices with closed-source platforms (e.g., Tongyi Wanxiang wan2.7-image at ¥0.2/image, Volcengine Jimeng at ¥0.22/image), FLUX.2 [klein] 4B's ≈ $0.015/image is in the same order of magnitude, but the former is locally deployable and commercially usable under Apache 2.0 — this is the real competitive edge of the open-weight route.

7. Summary

7.1 Strengths

1. The group's only official structured-prompting contract: six JSON fields, programmable, diffable, and validatable.
2. Reproducibility is a first-class engineering feature: preview and fixed snapshot endpoints turn "will the model change" into an explicit switch.
3. Clearest license tiers: Apache 2.0 commercial, NCL non-commercial, closed API, with an unambiguous IP boundary.
4. Locally deployable, data stays within the intranet: [klein] 4B ~13GB VRAM, commercially usable under Apache 2.0.
5. Predictable cost structure: linear MP pricing + a 4MP output limit, so the upper bound of per-image cost is computable.
6. Fully auditable context: [klein] does no prompt upsampling, so what the caller writes is exactly what the model receives.
7. Thickest ecosystem: directly loadable in ComfyUI / Diffusers, aggregated by Adobe, Leonardo, and LiblibAI.

7.2 Limitations & Applicable Boundaries

1. Extremely thin platform layer: no asset library, no project space, no team seats, no brand asset pack.
2. L4 must be self-built: asset persistence is determined by the caller's engineering practice, with no platform guarantee.
3. No official Eval Set: quality regression requires self-built evaluation sets.
4. Content moderation is your own responsibility: no public statement on content rewriting or moderation for [klein]; for open-weight deployments the guardrail responsibility rests entirely with the deployer.
5. [klein]'s reference-image limit is only 4; multi-character scenarios must go through [pro] / [flex] / [max].
6. Self-hosted commercial license pricing is unclear: third-party single source $999/month.
7. Not for teams without engineering capability: choosing FLUX means choosing to build the upper Harness layers yourself.

7.3 Selection Recommendations

7.4 Compliance Notes

• The Measures for the Labeling of AI-Generated Synthetic Content (CAC Notice 〔2025〕 No. 2) took effect on 2025-09-01. Article 4 requires that when providing download, copy, and export functions, explicit labeling must be included in the file (for image-type content, "add a prominent prompt label at an appropriate position"); Article 5 requires one must add implicit labeling in the file metadata (including the AI-generated-nature attribute information, the service provider's name or code, the content number, etc.) and encourages adding it in digital-watermark form; Article 6 requires dissemination platforms to verify implicit labeling and handle it in three tiers; Article 10 is a red line — one must not maliciously delete, alter, forge, or conceal labels, and must not provide tools or services for others to do so.
• Compliance responsibility for the open-weight route rests entirely with the deployer. When building your own service with [klein] 4B, the deployer is the "service provider" in the sense of the Measures, and must implement explicit labeling and metadata implicit labeling itself; it may not disclaim liability on the grounds that "the model doesn't come with this feature".
• If used for try-on or face-swap, Article 1018 of the Civil Code of the People's Republic of China (a portrait is an "external image that can be recognized") and Article 1019 (must not infringe portrait rights through forgery using information technology) apply. A Beijing Internet Court ruling effective 2026-03 established: identifiability is the core criterion (no exact match needed; if the general public can recognize the person, it constitutes use of that natural person's portrait); burden-of-proof shift — a defendant claiming an "AI accidental look-alike" must reproduce the creation process; if it cannot, it bears the consequences of failure of proof. Here, FLUX's "fully auditable context + fixed snapshot endpoints" features can serve as the technical foundation for reproducibility.
• Industry warning: on 2026-04-28, Jimeng AI was lawfully investigated and punished by the cyberspace administration for failing to effectively implement the labeling requirements for AI-generated synthetic content. This case shows that the regulatory focus is on the export and distribution stages.

Information-Gap Statement

1. Self-hosted commercial license pricing: a third-party single source claims ~$999/month (including 100,000 images/month, $0.01/image beyond), low confidence.
2. [klein]'s content-moderation and prompt-rewriting policy: no official public statement seen, marked [To be filled].
3. Official customer cases and quantified performance data: none found, honestly marked "not found".
4. Specific parameter counts and training data for each FLUX.2 model: not disclosed in the official docs (only [klein] 4B / 9B reveal their size by naming), marked [To be filled].
5. A complete list of capability differences between Playground and API: the official docs only give the multi-reference limits separately (8 vs 10); other differences are not explained, marked [To be filled].
6. Current status of aggregator integrations (Adobe Firefly, Leonardo, LiblibAI): from a third-party review snapshot, may have changed, marked [To be verified].
7. Labeling implementation support for the Measures: not provided officially; the deployer must implement it itself, marked [To be filled].

8. References

1. Black Forest Labs · FLUX.2 Overview (official docs) — BFL, 2026. https://docs.bfl.ai/flux_2/flux2_overview
2. ComfyUI official workflow "Virtual Character Try-On - Four-in-One" — Comfy Org. https://comfy.org/zh/workflows/templates_rob_fashion_shoot_vton-4in1.app/
3. Comfy official website (developer platform / MiniMax license / SDK) — Comfy Org. https://www.comfy.org/zh-cn/
4. Full text of the Measures for the Labeling of AI-Generated Synthetic Content — Cyberspace Administration of China, 2025-03-14. https://www.cac.gov.cn/2025-03/14/c_1743654684782215.htm
5. Interpretation of the Measures for the Labeling of AI-Generated Synthetic Content — Gov.cn / Xinhua News Agency, 2025-03-16. https://www.gov.cn/zhengce/202503/content_7014281.htm
6. "From September 1, AI-generated synthetic content must be labeled" — CCTV.com, 2025-03-15. https://big5.cctv.com/gate/big5/news.cctv.cn/2025/03/15/ARTI36OOL0hP5mpvU5cDgo4L250315.shtml
7. "Technology is not a 'shield' for infringement: how courts determine AI 'face-stealing'" — Xinhua News Agency, Economic Information Daily, 2026-04-17. http://dz.jjckb.cn/www/pages/webpage2009/html/2026-04/17/content_115180.htm
8. "e-Case e-Review: An AI face-swapped short-drama character 'closely resembles' a famous actor — accidental 'look-alike' or intentional infringement?" — contributed by Beijing Internet Court, The Paper. https://www.thepaper.cn/newsDetail_forward_32799628
9. "AI face-swap stealing images for traffic? Infringing portrait rights means liability!" — The Paper. https://m.thepaper.cn/newsDetail_forward_33508010
10. "Hot-spot response: can AI face-swap buy 'genuine emotion'?" — Science and Technology Daily, 2026-04-22. https://www.stdaily.com/web/gdxw/2026-04/22/content_506488.html