MOSS-Image Edit LoRA Adds Instruction Editing to ComfyUI

MOSS-Image is the 5B text-and-layout model from OpenMOSS that the site covered at release: legible text, JSON layout boxes, and a ComfyUI core implementation that shipped in the same week. What it did not have was a way to take an existing image and change it. Editing meant layout edits or a control adapter, not "give this person a different jacket".

The new adapter fills that gap. It is a community release, not an OpenMOSS one, but it is the implementation ComfyUI maintainers wired the core support around.

What the LoRA changes

The model card describes the scope plainly: color, outfits, lighting, seasons, and visual style, driven by a text instruction and up to four reference images. The instruction says what to change; the references carry what should stay.

Case grid published with the LoRA. Source: chinoll/Moss-Image-Edit

With more than one reference, each image has to be named in the instruction, since the adapter itself does not assign roles. The node pack's example prompt is Dress the person in image 1 in the outfit from image 2.

Mechanically the adapter is small and conventional. Inspecting the safetensors header gives 504 tensors across all 42 DiT layers, six projections per layer (q, k, v, o, ffn_up_gate, ffn_down), at rank 64 with alpha 64. Its adapter_config.json declares a moss-edit-lora format version 1 and records its training contract as ref-prefix-only-t0__target-text-original-moss-v1, which is the layout ComfyUI now implements under the name Moss-Image-Edit.

The same weights work with either MOSS-Image-Base or MOSS-Image-SFT; Base preserves more of the training signal, SFT is the tidier starting point. The reference card's examples were trained and sampled against SFT.

Editing showcase from the project repository: each group starts with the source image and continues with its edits.

Core ComfyUI path

PR #17296 by Kijai adds a Text Encode MOSS-Image Edit node, still flagged experimental, under model/conditioning/moss_image. It takes a clip, a prompt, a vae, an edit_format choice, and an autogrowing set of images. The edit_format selector is the interesting part, because it encodes the fact that edit LoRAs are not interchangeable:

For the Moss-Image-Edit layout the vision tower never receives the reference images, so the instruction has to describe the edit on its own; appearance comes entirely from the reference latents injected into the DiT. For ai-toolkit-trained adapters the references are downscaled to at most 384×384 and prepended to the prompt as Picture N: tokens.

The adapter loads through the standard LoRA loader, because the PR added aliases for the bare layers.N.proj.q key style these files use. That means the native route is the ordinary MOSS-Image graph with the single-file weights from Comfy-Org/MOSS-Image, plus a LoRA loader and the new text encode node; the reference images connect to the node as images, not as a separate latent input.

The PR also reports a speed fix rather than a feature: for isolated layouts the references' per-block K/V are computed once in extra_conds instead of on every step, which takes 1024² with a 1 MP reference from 826 ms to 457 ms per step. The support merged after the v0.42.1 tag, so a released install needs to update past that tag to use it.

Node pack path

The same author ships a self-contained node pack, Chenkin-x/ComfyUI-Moss-Image-Edit, which appeared on October 22 and adds both a loader and an editing node under a MOSS Image Edit category. It runs its own copy of the MOSS runtime instead of the core nodes, and it expects a full Diffusers snapshot rather than the single-file repack:

ComfyUI/models/moss_image/
├── MOSS-Image-SFT/          # pipeline_moss_image.py, transformer/, text_encoder/, tokenizer/, vae/, scheduler/
└── Moss-Image-Edit/         # adapter_config.json, adapter_model.safetensors

The loader's snapshot_dir points at the base model and adapter_dir at the adapter. Two workflows ship with it, one for a single reference and one for two, and reaching three or four means adding Load Image nodes to the spare reference_3 and reference_4 inputs. The documented defaults are 512×512 output, 30 steps, CFG 4.0, inference_shift 5.0, and a reference long edge of 512 with no cropping.

How the references reach the DiT

Both paths rest on the same trick. The reference images are VAE-encoded into latent tokens and appended to the image sequence at their own RoPE index, at timestep zero, attending only to each other. Because those tokens never change across the sampling loop, their per-block K/V can be cached once and reused, which is what makes a rank-64 adapter with no text-encoder training enough to hold an identity while the instruction rewrites the rest.

Reference KV cache diagram from the training repository, showing the cached reference blocks next to the generated tokens.

The training repository publishes the whole recipe rather than only the weights: data preparation, configs, and an inference script. Training data is NOOB2 pairs plus the ConceptEdit-12M set, with instructions taken from instruction.detailed_en, source and edited images encoded together by the VAE, and both images scaled so the long edge stays under max_edge with no crop or pad. The guide launches with a four-process torchrun, DeepSpeed Muon on ZeRO-2 through a patched adjust_lr_fn, Flash Attention 4 with varlen packing, and the text encoder quantized to int8 during training. Validation samples are written per step alongside generated/source/target triples, so the checkpoints in the repository can be reproduced or extended.

Limits worth knowing

The LoRA is a 297 MB bf16 adapter, small next to the base model, but it is not a general-purpose editor. The published scope is attribute and scene edits: color, outfit, lighting, season and style, plus expressions. The card documents no object insertion, publishes no benchmark, and makes no claim about composing two subjects into one scene. Multi-reference edits depend on the prompt assigning roles, as noted above. Nor is this an official OpenMOSS release: the weights, the node pack and the training code all come from one author, and the core PR is the only part reviewed by ComfyUI maintainers.

Availability

• LoRA: chinoll/Moss-Image-Edit, about 21 likes at the time of writing, one day after upload.
• ComfyUI core: PR #17296, merged October 22, 2026, after the v0.42.1 release.
• Node pack: Chenkin-x/ComfyUI-Moss-Image-Edit with single and multi-reference workflows.
• Training and inference code: Chenkin-x/Moss-Image-Edit, including prepare_data.py, configs/train.json and infer.py.
• Base models: MOSS-Image-Base and MOSS-Image-SFT, with single-file ComfyUI weights in Comfy-Org/MOSS-Image.