# FLUX 3 Klein and MOSS-Image in ComfyUI: How Big the Download Is

> The real file sizes for the new FLUX 3 Klein and MOSS-Image ComfyUI packages, what a working setup costs you, and where a layout JSON fits in.

Source: https://toolpantry.app/blog/flux-3-klein-moss-image-comfyui-sizes

Both landed in the same week, and both ship ComfyUI packages with a diffusion model, a text encoder and a VAE. The weights are between 10 and 30 gigabytes each depending on the precision you pick, and the published file sizes make the choice easy to reason about.

## Quick answer

**Short answer:** a quantized FLUX 3 Klein setup is **12.34 GB** against **30.26 GB** in full precision, and a quantized MOSS-Image setup is **13.09 GB** against **29.81 GB**. The nvfp4 Klein diffusion model is **5.28 GB** instead of 11.10 GB, and the w4a8 text encoder **6.72 GB** instead of 18.82 GB. Every number here is a published file size, and every file is an alternative to another one, not something you need on top of it.

## What arrived, and when

Two model families landed in the same week, and both ship ComfyUI packages:

- **FLUX 3 Klein** — published by black-forest-labs on **14 October 2026**, listed as an image-to-image model. The ComfyUI repackage shows **490,447 downloads** and 1,203 likes already, which is a lot of traffic for a week-old model.
- **MOSS-Image** — the OpenMOSS-Team checkpoints were published around 11 October, and the **Comfy-Org repackage followed on 16 October** with 342 likes. It is Apache-2.0 licensed, and the model card lists the original Base and SFT repositories plus a colour-depth-control LoRA.

Both are the kind of release that makes people download twenty gigabytes on a Friday night, so the sizes are worth looking at before you start.

## The actual file sizes

These are the published file sizes in each repository, not estimates. Decimal GB, one million bytes to the gigabyte:

| File | bf16 | Quantized | Saving |
|---|---|---|---|
| diffusion model | 11.10 GB | 5.28 GB (nvfp4) / 5.83 GB (int8) | 52 % |
| prompt upsampler (Qwen3.5 9B) | 18.82 GB | 6.72 GB (w4a8) / 9.75 GB (int8) | 64 % |
| vision encoder (Qwen3-VL 4B) | 8.88 GB | 4.86 GB (int8) | 45 % |
| VAE (FLUX 2) | 0.34 GB | — | — |

| File | bf16 | Quantized | Saving |
|---|---|---|---|
| diffusion model (Base or SFT) | 10.16 GB | 5.41 GB (int8 convrot) | 47 % |
| text encoder (Qwen3.5 9B) | 19.31 GB | 7.34 GB (w4a8 gptq) / 9.75 GB (int8) | 62 % |
| colour-depth-control LoRA | 0.31 GB | — | — |
| VAE | 0.34 GB | 0.25 GB (small) | 26 % |

Take every file in the MOSS repository and it is **68.45 GB**. Nobody needs all of it: the Base and SFT diffusion models are alternatives, not a pair.

## What a working setup actually costs

For Klein, the diffusion model is not the biggest file — the text encoder is. Two routes, and the choice is about what you are feeding it:

| Setup | Files | Total |
|---|---|---|
| Full precision | diffusion bf16 + prompt upsampler bf16 + VAE | **30.26 GB** |
| Quantized | diffusion nvfp4 + prompt upsampler w4a8 + VAE | **12.34 GB** — 59 % less |
| Quantized, smaller encoder | diffusion nvfp4 + Qwen3-VL 4B int8 + VAE | **10.48 GB** |

For MOSS-Image, the same arithmetic: diffusion bf16 plus the Qwen3.5 9B text encoder plus the VAE is **29.81 GB**, and the quantized set — 5.41 GB diffusion, 7.34 GB text encoder, 0.34 GB VAE — is **13.09 GB**, a 56 % cut.

So the useful question is not "which model" but "which of these three files do I actually need, and can it be the smaller one". The repository layout tells you the rest:

```
ComfyUI/
├── models/
│   ├── diffusion_models/    moss_image_sft_int8_convrot.safetensors
│   ├── loras/               moss_image_color_depth_control.safetensors
│   ├── text_encoders/       qwen3.5_9b_w4a8_gptq.safetensors
│   └── vae/                 flux2-vae_small.safetensors
```

Note the MOSS package uses the **FLUX 2 VAE**, not a MOSS-specific one, and a **Qwen3.5 9B** text encoder. Both models are built on the same FLUX-style pipeline, which is why the same kind of layout description works for each.

## Where a layout JSON comes in

Both of these models take a scene described with the position of each element written down, and that description is the part that is tedious to write by hand. It is also the part a browser can do for you.

Our [FLUX bounding box generator](https://toolpantry.app/flux-bounding-box-generator) draws boxes on a canvas and exports two things: a prompt where each element is tagged with its id, and a JSON array of elements like this:

```
[{"id": "subject", "bbox": [120, 340, 880, 660], "desc": "a red kite"}]
```

The coordinates are whole numbers from 0 to 1000, measured from the top-left, and the tool refuses to export a box that is inverted, a duplicate id, or a caption that mentions an element you never placed. The [MOSS layout editor](https://toolpantry.app/moss-image-layout-editor) works the same way with percentage boxes and keeps a draft JSON you can reopen.

The **layout** is the part that travels; the node graph is what differs per workflow. In ComfyUI that graph is a set of nodes, and which nodes you use depends on whether you are doing text-to-image with MOSS or image-to-image with Klein. We have not run either model here — there is no GPU on this machine and the FLUX 3 Klein weights are behind an access request — so we are not going to claim a workflow graph we have not executed.

## What we checked, and what we did not

Verified, from the public repositories on 22 October 2026: every file name and byte size listed above, the licence on the MOSS repackage, the creation dates, the download and like counts, the tag lists, and the folder layout the model card specifies. The ComfyUI repackages for FLUX 3 Klein and MOSS-Image are the official ones, published by Comfy-Org.

Not verified: we did not download or run any of these weights, so we have no quality comparison between the bf16, int8 and nvfp4 checkpoints, and we have not tested whether our layout JSON is consumed the same way by the Klein and MOSS pipelines. The token counts in the API are the published ones. Anyone with a GPU and the access can settle the rest in an afternoon, and the model cards are the place to check for the current node names.

## Notes

Written by the Tool Pantry team on 22 October 2026 from the public model repositories: black-forest-labs/flux-3-image-klein-comfy and Comfy-Org/MOSS-Image, with file sizes read from the repository API the same day. We did not download or run any of these weights — there is no GPU here, and the FLUX 3 Klein weights are behind an access request — so we make no claim about output quality between the checkpoints, and we have not tested whether a layout JSON is consumed identically by the two pipelines.

## FAQ

**How much disk do I need for FLUX 3 Klein?**

Between 10.48 GB and 30.26 GB, depending on the precision. A quantized setup — the nvfp4 diffusion model, the w4a8 prompt upsampler and the VAE — is 12.34 GB, and swapping the upsampler for the smaller Qwen3-VL 4B encoder brings it to 10.48 GB. The full-precision set is 30.26 GB.

**And for MOSS-Image?**

13.09 GB for a quantized setup, or 29.81 GB in full precision. The whole repository is 68.45 GB, but that includes both the Base and SFT diffusion models, which are alternatives, and all three text encoders, which are alternatives too.

**Is the smaller checkpoint as good?**

We do not know, and we are not going to guess. We did not run any of these weights. The int8 and 4-bit formats trade some fidelity for the disk saving, and the usual pattern is that the smaller file is the one people notice least — but that is a general impression, not a measurement from these checkpoints.

**Which text encoder do I need?**

For MOSS-Image, the repository ships Qwen3.5 9B in three sizes, and the model card expects that family. For FLUX 3 Klein there are two families: a Qwen3.5 9B prompt upsampler, and a Qwen3-VL 4B vision encoder. The workflows folder in the Klein package includes reference images, which is where the difference shows up in practice.

**Can I skip the layout JSON and just write a prompt?**

You can, and for a simple scene that is usually enough. The layout matters when the position of an element is part of the request — a poster where the headline goes at the top, a product shot with the label in a specific corner. Our generators exist to save the tedium of describing that in words, not because the description has to be exhaustive.

**Do my files get uploaded?**

No. The layout editors run in your browser, and the JSON never leaves your machine. That matters here more than usual, because a layout is a description of a picture you may not have made yet.