MOSS-Image Edit HQ v5 lands with two ComfyUI LoRA formats

MOSS-Image is OpenMOSS's 5B text-and-layout model, covered at release, which gained instruction editing two weeks later through a rank-64 community adapter. That adapter was chinoll/Moss-Image-Edit, and the question it left open was how much of the editing behaviour comes from that single training set. MOSS-Image-Edit-HQ answers it by rebuilding the capability from other data and measuring itself against the original.

What v5 actually changes

The repository is a log of five training arms, not one release. Each arm continued from the previous checkout, and each one is kept on disk with its samples, so the differences are inspectable rather than asserted.

The v5 change that matters most is the reference budget. Base MOSS-Image gives the reference image 144 tokens; this arm raises it to 256, which is where the gain in identity and fine detail is claimed to come from. The rest of v5 is data work: pixel-diff masks so unedited regions stay close to the source, and full scene captions folded from ConceptEdit metadata so the instruction describes the whole frame instead of only the edit.

Each row starts at the source image and continues with v5 output. Source: akhaliq/MOSS-Image-Edit-HQ

The checkpoints are 495 MB each in peft format, final plus steps 250, 500, 750 and 1000. Training ran on ai-toolkit at commit 14f8f95, single GPU per arm, with the text encoder frozen and gradient checkpointing required at 1024px. The training data is published too: 6,000 filtered ConceptEdit-12M rows as TAR shards, and the arm configs are in the repository.

Two ComfyUI paths, two LoRA layouts

The reason this release needs a little reading is that the same weights ship in two layouts that load through different ComfyUI mechanisms.

The native route uses weights/armV5/armV5.safetensors as an ordinary LoRA: put it in models/loras/, add a LoRA loader after Load Diffusion Model, and encode with the experimental Text Encode MOSS-Image Edit node with edit_format set to ai-toolkit. References are downscaled to at most 384x384 before the text encoder sees them.

The plugin route uses armV5-moss-edit-lora.safetensors, which goes in models/model_patches/ instead and loads through Chenkin-x/ComfyUI-Moss-Image-Edit, the same node pack that the earlier adapter uses. That pack asks for ComfyUI 0.42.3 or newer.

The native path is only available in a current master build. PR #17296 by Kijai merged on October 22 and added the edit node, but the newest tagged release, v0.42.5 from October 23, still ships the older comfy_extras/nodes_moss_image.py without it, so a released install has to update to a nightly to use edit_format = ai-toolkit. Both workflows ship with the filenames and settings filled in, for one reference and for up to four.

The ai-toolkit layout is not the same as the Moss-Image-Edit layout used by the earlier adapter, and the model card is explicit about it: chinoll's adapter uses split q, k and v keys while ai-toolkit fuses them, so warm-starting one from the other needs an exact rank-192 block-diagonal fusion. The repository ships the converter, and reports 336 of 336 tensors matching after conversion.

Where it is faster, and where it is not

Stacking the edit LoRA with the 8-step DMD speed LoRA cuts sampling to 8 steps and CFG 1 for roughly six times faster edits. The card's own verdict is that the 50-step pass still wins: at 8 steps object additions weaken and colour containment degrades, so the fast path is for drafts.

Input, then 50 steps, then the 8-step DMD stack. Source: akhaliq/MOSS-Image-Edit-HQ

The v5 showcase, one instruction per edit, rendered with the demo's settings of 50 steps and CFG 3.

The same honesty applies to the comparisons. The project's stated target is to beat chinoll/Moss-Image-Edit on quality, and the v1 arm openly failed that gate on identity preservation before the later arms moved to masked loss. The published grids set v5 against both the earlier adapter and Krea 2, but they are the author's own eval sets and a demo Space, not a third-party benchmark.

v5 edits of Krea 2 showcase prompts next to the Krea 2 reference renders. Source: akhaliq/MOSS-Image-Edit-HQ

Object removal cases from the repository. Source: akhaliq/MOSS-Image-Edit-HQ

For speed of use, the card also links a Gradio demo Space that runs both the quality and the 8-step modes so the trade can be checked before downloading 495 MB.

Limits worth knowing

• VRAM: the pipeline needs about 20 GB in bf16. The card answers the obvious question directly: no, it does not run on 6 GB, even with int8 community builds of the base model.
• Base model: it is trained on MOSS-Image-SFT. Base and Kromoss compatibility is listed as unverified, and the native path is described as the reliable one.
• Single-reference training: the architecture accepts up to four references, but the adapter was trained on single-reference edit pairs. Compositing a person or object from one photo into another is explicitly not what it was trained for.
• Colour: a known v3 trait of pushing saturation past the source was reported by a user on the model card and targeted by the v4 masked loss.
• Scope: attribute, removal, lighting, facial and text edits. The release says nothing about pose changes, which is what the first comment on the announcement asked for.

None of this is an OpenMOSS release. The weights, the data, the eval grids and the demo all come from one author, and the card says so plainly.

Availability

• LoRA: akhaliq/MOSS-Image-Edit-HQ, v5 published October 25, 2026.
• Workflows: armV5_workflow_single.json and armV5_workflow_multi.json.
• Demo: moss-image-edit-hq-demo on Hugging Face Spaces.
• ComfyUI core: PR #17296, merged October 22, 2026, master and nightly only.
• Node pack: Chenkin-x/ComfyUI-Moss-Image-Edit, with ComfyUI 0.42.3 or newer.
• Training data and code: moss-image-edit-conceptedit-packed plus the training/ directory of the repository.