MOSS-Image in ComfyUI: Files, Settings, Layout JSON and 4-Step LoRAs

OpenMOSS released MOSS-Image on October 16, 2026, and within a day ComfyUI had native support for it, plus two community speed-ups that cut it from 50 steps down to 4 or 8. It is a 5B parameter text-to-image model trained from scratch on about 3.2 billion images, it ships under Apache 2.0, and it has one trick most open image models do not: you can feed it a JSON layout that says exactly where each object, character and line of text should go. This guide covers which MOSS-Image files to download for ComfyUI, which folder each one goes in, the settings that actually matter, how the bounding-box layout workflow works, how to use the 4-step and 8-step LoRAs without wrecking them, and what to expect on a 12 to 16 GB GPU.

What Is MOSS-Image?

MOSS-Image is an open weights text-to-image model family from OpenMOSS, the research group behind the MOSS language models, backed by Fudan University, the Shanghai Innovation Institute and MOSI Intelligence. The team announced two checkpoints on October 16, 2026: MOSS-Image-Base, the raw pre-training checkpoint, and MOSS-Image-SFT, a supervised fine-tune that OpenMOSS recommends for most people.

Under the hood it is a single-stream diffusion transformer with roughly 5 billion parameters. It does not have its own VAE: it generates in the FLUX.2 latent space and decodes with the same flux2-vae.safetensors that FLUX.2 and FLUX 3 Image Klein use. That is good news if you already run either of those, because the VAE is already sitting in your models/vae folder.

The unusual part is the text encoder. MOSS-Image reads prompts with a stock Qwen3.5-9B language model, which is almost twice the size of the image transformer itself. That is why the model handles long prompts well (up to about 4K tokens), why it can render English and Chinese text inside images, and why it can understand a structured JSON layout as a prompt. It is also why memory planning matters more than the “5B” headline suggests.

Three more facts worth knowing before you download anything:

• Training data: about 3.2 billion images, pretrained from scratch with relatively light quality filtering. That broad base is why it takes booru-style tag prompts as comfortably as natural language.
• License: the pipeline code on GitHub is Apache 2.0, and the Comfy-Org repack on Hugging Face is tagged Apache 2.0. Check the original OpenMOSS model cards before commercial use, since a repack tag is not the final word.
• No install needed to try it: OpenMOSS runs a free Hugging Face Space (OpenMOSS-Team/MOSS-Image), so you can test prompts before committing 16 GB of downloads.

Base vs SFT: Which Checkpoint Should You Use?

Both checkpoints come in bf16 and pre-quantized INT8 builds. The choice is about what you want to do, not about quality alone.

My recommendation is simple. If you only want pictures, download the SFT checkpoint. If you plan to train a style or character LoRA, train on Base, then apply the LoRA to SFT for generation. If you want the fast 4-step or 8-step workflow, you need the bf16 SFT file, because the adapters reject INT8, FP8 and GGUF transformers.

Hardware Requirements: VRAM, RAM and Disk

Neither OpenMOSS nor Comfy-Org publish an official VRAM figure, and the one cloud template guide I found simply suggests 24 GB cards like the RTX 3090, RTX 4090 or A5000. You can still work out a realistic picture from the file sizes, because ComfyUI loads the text encoder, encodes your prompt, then offloads it before the transformer runs.

All totals include the 336 MB FLUX.2 VAE. On a 16 GB card like my RTX 5080, the balanced setup is the one to start with: the 5.4 GB transformer leaves plenty of room for activations at 1 to 2 megapixels, and the text encoder only has to fit while it encodes the prompt. The few-step setup also fits on 16 GB because the 10.2 GB bf16 transformer plus the roughly 1.5 GB fp32 adapter overhead stays under the limit, but expect ComfyUI to shuffle the text encoder in and out of VRAM.

Plan for 32 GB of system RAM as a sensible minimum, since offloaded models sit in RAM, and keep at least 20 GB of free SSD space for the files. If you are short on memory, OpenMOSS’s own Gradio app has a “Sequential” offload mode, and ComfyUI’s --lowvram flag does the same job.

Files to Download and Where They Go

Everything you need for the native ComfyUI workflow lives in one repo: Comfy-Org/MOSS-Image on Hugging Face. It is a repack of the OpenMOSS checkpoints into ComfyUI’s standard folders, so you do not need the Diffusers pipeline.

The repo also contains flux2-vae_small.safetensors and the full bf16 Qwen3.5-9B encoder. You only need one text encoder. The color and depth control LoRA comes from a separate community repo (darask0/MOSS-Image-color-depth-control) and is optional.

Install MOSS-Image in ComfyUI Step by Step

1. Update ComfyUI to the latest development build. MOSS-Image support was merged in ComfyUI PR #17095 (written by Kijai) after the most recent release tag. If you use the portable build, run update/update_comfyui.bat. For a git install, run git pull in the ComfyUI folder. In ComfyUI Desktop, wait for the next app update or switch to the nightly channel.
2. Download the three core files from the table above. With the Hugging Face CLI it looks like this:

   hf download Comfy-Org/MOSS-Image diffusion_models/moss_image_sft_int8_convrot.safetensors --local-dir ComfyUI/models
   hf download Comfy-Org/MOSS-Image text_encoders/qwen3.5_9b_int8_convrot.safetensors --local-dir ComfyUI/models
   hf download Comfy-Org/MOSS-Image vae/flux2-vae.safetensors --local-dir ComfyUI/models

   Check the repo’s file browser if a path differs, since repack layouts sometimes change.

3. Restart ComfyUI so it picks up the new model types.
4. Load a workflow. The two community workflows that circulated on day one are moss_image_text2image.json and moss_image_text2image_bbox.json. The core building blocks are: Load Diffusion Model for the transformer, CLIPLoader with type set to moss_image for the Qwen encoder, Load VAE for the FLUX.2 VAE, SkipLayerGuidanceDiTSimple, a sampler and VAE Decode.
5. Run a test prompt at 1024 x 1024 before you try larger sizes or the layout workflow.

There is also an official OpenMOSS plugin called moss-image, installable from ComfyUI Manager. Its MOSS-Image HF Loader node loads a local Diffusers folder instead of the repacked safetensors. Use it only if you already downloaded the original Diffusers weights. For most people the native nodes are the simpler path.

Recommended Settings

These come from the OpenMOSS user guide and the reference workflows. The defaults are good, so change one thing at a time.

Skip layer guidance deserves a short explanation, because it changes the look more than anything else. MOSS-Image is tuned to skip transformer layer 22 on the negative (unconditional) branch. That keeps fine details crisp. If you turn it off completely, images tend to look more photographic but small details can collapse. The reference ComfyUI workflow uses SkipLayerGuidanceDiTSimple with single_layers set to 22 and an end_percent of 0.5 as a compromise between the two. If your renders look waxy, lower the end percent. If hands, text or small objects fall apart, raise it.

Good starting resolutions that keep both sides a multiple of 16 are 1024 x 1024, 1152 x 896, 896 x 1152, 1344 x 768, 768 x 1344 and 1456 x 1456 (about 2.1 MP, the size used in the official Python example).

How to Prompt MOSS-Image

MOSS-Image accepts three kinds of prompt, and you can mix them.

Natural language

English gets the best results because it dominated the training data, but Chinese works too. Long, descriptive prompts are fine thanks to the 9B text encoder. Keep CFG near 3 when your prompt is long.

Booru-style tags

Because of its broad training set, MOSS-Image understands tag prompts well, which makes it attractive for anime and illustration work. OpenMOSS recommends this order: quality tags, score tags, meta tags, year, character, series, artist, then general tags. For example: masterpiece, best quality, highres, 2025, 1girl, solo, silver hair, school uniform, cherry blossoms, wind, looking back.

Text inside images

Put the exact words you want in quotes. The model wraps lines automatically, but if you need precise line breaks, type a real line break or n into the prompt where you want the break. Short headlines render far more reliably than paragraphs, and small text on signs or speech bubbles is still hit and miss.

Layout Control With Bounding Boxes and JSON

This is the feature that makes MOSS-Image worth a look even if you already have FLUX or Qwen-Image set up. Instead of hoping the model puts your title at the top and your product bottom right, you can tell it where things go.

The model was trained on a JSON layout format with these fields:

• summary: the whole scene. It holds meta, canvas and caption fields describing the overall image and style.
• items: a list of elements. Each has a label (text, character or object), a caption describing it, a bbox for its position and, for text items, a text field with the exact words to render.
• bbox_format: "yxyx", meaning each box is [y_min, x_min, y_max, x_max].
• bbox_coord_space: "abs_centralized", meaning pixel offsets from the center of the canvas. On a 1024 x 1024 image both axes run from -512 to +512, x grows to the right and y grows downward.

Here is a simplified example of the item structure for a travel poster with a title at the top and a mountain illustration in the lower half. Copy the exact meta and canvas format from the README example if you write JSON by hand:

{
  "summary": { "caption": "Minimalist flat travel poster, soft blue palette" },
  "items": [
    { "label": "text", "caption": "bold dark blue sans-serif title",
      "text": "EXPLORE", "bbox": [-420, -300, -260, 300] },
    { "label": "object", "caption": "flat blue mountain range illustration",
      "bbox": [0, -400, 420, 400] }
  ],
  "bbox_format": "yxyx",
  "bbox_coord_space": "abs_centralized"
}

The coordinate system trips people up. If you think in normal top-left pixel coordinates, subtract half the width from every x value and half the height from every y value to convert.

The good news is that you rarely need to write this by hand in ComfyUI. The core MOSS-Image Layout Prompt node takes your overall prompt plus boxes drawn with the Create Bounding Boxes node and builds the JSON for you. Two tips from people who have used it since launch:

• Set the width and height inside Create Bounding Boxes to the exact output size.
• Do not wire a Resolution Selector node into those width and height inputs. There is a known bug where that shifts the box coordinates. Type the same numbers in manually instead.

OpenMOSS labels layout support as experimental, so treat boxes as strong suggestions rather than pixel-exact placement.

4-Step and 8-Step LoRAs: rapid-moss and DMD

Fifty steps with CFG means 100 model evaluations per image, which is slow on consumer cards. Within a day of launch the community shipped two distillation adapters.

MOSS-Image: transformer time per 1024px imageOne H100, DiT only (text encoding and VAE decode not included)Standard, 50 steps + CFG16.2 s8-step DMD (lodestones)1.54 srapid-moss 4-step0.81 sSource: rapid-moss / ComfyUI Wiki, Oct 17 2026. Few-step quality is below the 50-step teacher.

Those numbers cover only the transformer on a data-center GPU. End to end in ComfyUI on an RTX PRO 6000, including text encoding and decoding, the 4-step adapter takes about 4.5 to 6.9 seconds per 1024 x 1024 image. Consumer cards will be slower, but the ratio is what matters: roughly 10 to 20 times less transformer work than the standard workflow.

How to set up rapid-moss

1. Download the repo darask0/MOSS-Image_4-step_adapter_lora. It contains lora.safetensors, time_embedding.safetensors and dataspace.safetensors, plus a ComfyUI node.
2. Copy its comfyui/rapid-moss/ folder to ComfyUI/custom_nodes/rapid-moss/.
3. Put the three adapter files in ComfyUI/models/rapid_moss/rapid-moss-4step/. Each subfolder there shows up as an option in the node’s adapter menu, so you can drop the 8-step files into a second subfolder.
4. Load moss_image_sft_bf16.safetensors (not INT8), connect it to the MOSS-Image Few-Step Adapter node, send its MODEL output to BasicGuider, and its SAMPLER and SIGMAS outputs to SamplerCustomAdvanced.
5. Leave strength at 1.0.

Rules that will save you an hour

• No CFG. Use BasicGuider, not a CFG guider.
• Do not add the teacher settings. Leave out ModelSamplingSD3 shift 5, the Euler and sgm_uniform scheduler and skip layer guidance. The node supplies its own sampler and sigmas.
• Do not merge the adapter. The weight changes are smaller than bf16 rounding, so LoraLoaderModelOnly, Diffusers fuse_lora or a pre-merged checkpoint quietly erase most of the speed-up. The node applies it in fp32 at runtime for exactly this reason, which costs about 1.5 GB of extra VRAM.
• Quantized transformers are rejected. INT8, FP8 and GGUF transformers do not work with the adapter. Quantized text encoders are fine.
• 8-step DMD: lodestones’ checkpoint (lodestones/MOSS-Image-SFT-8-steps-dmd) is labeled work in progress. Use lora.safetensors at strength 1.0 or lora_latest.safetensors at 0.7.

Quality is honestly below the 50-step teacher. The rapid-moss author documents some regressions, including stray Latin letters on light-novel style covers, an extra person added to a two-panel manga layout, and small text on shop curtains and speech bubbles that still fails. Use the fast adapters for exploring ideas and compositions, then re-render keepers with the full workflow.

MOSS-Image vs FLUX 3 Image Klein

Both landed in ComfyUI in the same week, both use the FLUX.2 VAE and both are around 5B parameters, so this is the comparison most people are making.

If you need image editing or the fastest out-of-the-box speed, Klein is the better tool. If you want an Apache-licensed base for commercial projects or LoRA training, strong tag-prompt support or structured JSON layouts, MOSS-Image is worth the extra disk space. Since they share a VAE, keeping both installed costs you only the transformer and encoder files.

Troubleshooting

“Unknown model type” or the CLIPLoader has no moss_image option

Your ComfyUI is older than PR #17095. Update to the latest development build, not just the latest release tag, and restart.

Errors about width or height

Both sides must be multiples of 16. 1000 x 1000 fails, 1008 x 1008 works.

Out of memory on 12 GB

Switch to the W4A8 text encoder, stay at about 1 megapixel, and start ComfyUI with --lowvram. The INT8 transformer plus the W4A8 encoder is the leanest supported combination.

Layout boxes land in the wrong place

Remove any Resolution Selector connected to Create Bounding Boxes and type the width and height manually. Also make sure the box canvas size matches the latent size exactly.

The 4-step adapter gives mushy or noisy images

Check that you loaded the bf16 SFT model, that there is no CFG guider, no ModelSamplingSD3 node and no skip layer guidance in the graph, and that you did not apply the adapter through a regular LoRA loader.

Garbled text

Shorten the text, put it in quotes, add a manual line break, and use 50 steps. The few-step adapters are noticeably weaker at small text.

FAQ

Is MOSS-Image free for commercial use?

The ComfyUI repack is tagged Apache 2.0, which allows commercial use, and the OpenMOSS code is Apache 2.0. Confirm the license on the original OpenMOSS model cards before you ship a commercial product.

Can MOSS-Image run on 8 GB of VRAM?

There is no official figure. With the 5.4 GB INT8 transformer, the 7.3 GB W4A8 encoder, low-VRAM mode and around 1 megapixel it may work, but expect heavy offloading. A 12 GB card is a more realistic minimum, and the fast adapters need the 10.2 GB bf16 transformer.

Can MOSS-Image edit images?

Not in the released checkpoints. It is a text-to-image model. OpenMOSS says simple fine-tuning can add reference-based generation, and a community color and depth control LoRA already exists.

Which checkpoint should I train LoRAs on?

Train on MOSS-Image-Base and keep the text encoder frozen, as OpenMOSS advises. Then use the LoRA on SFT.

Do I need a new VAE?

No. MOSS-Image uses the standard flux2-vae.safetensors, the same file used by FLUX.2 and FLUX 3 Image Klein.

Does it render Chinese and Japanese text?

English and Chinese are officially supported. The rapid-moss author reports that Japanese text on signs and sticky notes also stays accurate in their tests.

Final Thoughts

MOSS-Image is a genuinely different open image model: a permissive license, a 9B language model reading your prompt, strong tag support and JSON layout control, all in a 5B transformer that fits on a 16 GB GPU in INT8. Start with the INT8 SFT transformer, the INT8 Qwen3.5-9B encoder and the FLUX.2 VAE, update ComfyUI past PR #17095, and render at 1 megapixel with 25 steps to learn the model. Once you like a prompt, move to 50 steps, or switch to the bf16 model with the rapid-moss adapter when you want speed.

More local AI guides that pair well with MOSS-Image:

• FLUX 3 Image Klein in ComfyUI, the other new 5B-class image model, which shares the same VAE.
• Comfy Agent Guide, if you want an AI agent to build workflows like these for you.
• Best Local AI Video Models in 2026, to animate your MOSS-Image stills.
• MiniMax H3 Out of Memory Fixes for 16 GB GPUs, whose offloading tips apply here too.

Sources

• GitHub: OpenMOSS/MOSS-Image and its user guide
• Hugging Face: Comfy-Org/MOSS-Image repack
• ComfyUI Wiki: MOSS-Image with layout control and ComfyUI support
• ComfyUI Wiki: MOSS-Image few-step LoRAs (rapid-moss and DMD)
• Hugging Face: darask0/MOSS-Image_4-step_adapter_lora
• Hugging Face: lodestones/MOSS-Image-SFT-8-steps-dmd
• AlphaSignal: Comfy-Org brings MOSS-Image 5B to ComfyUI