Instruction Image Editing in 2026: Kontext, Qwen, Step1X

Instruction based editing has largely replaced masked inpainting as the default way to change one thing in a photo: you hand the model an image and a sentence, and it returns the image with that thing changed. This is a working comparison of the open-weight editors that matter as of July 2026, covering FLUX.1 Kontext, Qwen-Image-Edit, Step1X-Edit, MagicQuill and SUPIR, judged on instruction fidelity, identity drift, VRAM, speed, and whether the license actually lets you sell the output. It assumes you run these locally rather than through a hosted API.

The field in July 2026

Three lineages dominate, and they diverged mostly on licensing rather than architecture.

Black Forest Labs shipped FLUX.1 Kontext [dev] in June 2025 as a 12B open-weights editor, then FLUX.2 on 25 November 2025 as a 32B rectified flow transformer that folds text-to-image, single-reference editing and multi-reference composition into one checkpoint. FLUX.2 [klein] followed on 15 January 2026 as a size-distilled pair: a 4B variant under Apache 2.0 and a 9B variant under a non-commercial license.

Alibaba's Qwen team went the other way. Qwen-Image-Edit opened on 18 August 2025 and has shipped roughly monthly since: 2509 on 22 September 2025, Qwen-Image-Layered on 19 December 2025, Qwen-Image-Edit-2511 on 23 December 2025, and Qwen-Image-2.0 on 10 February 2026 with a lighter architecture, native 2K output and stronger semantic adherence. Every one of those is Apache 2.0.

StepFun's Step1X-Edit landed 25 April 2025 with a different structure: a multimodal LLM parses the editing instruction into editing tokens, and a DiT decoder turns those tokens into pixels. It is also Apache 2.0, and StepFun released GEdit-Bench alongside it under MIT, which is now the most widely cited open evaluation for this task. The other benchmark you will see quoted is KontextBench, which is BFL's own.

Two unified multimodal models sit slightly outside this comparison but are worth knowing: OmniGen2, an Apache 2.0 system with two unshared decoding pathways for text and image plus a decoupled image tokenizer, weights released 16 June 2025, and ByteDance's BAGEL, 7B active and 14B total in a mixture-of-transformers layout, also Apache 2.0. Both edit competently and neither is currently the tool you reach for first. Z-Image from Tongyi is the interesting wildcard: 6B, Apache 2.0, Turbo released 26 November 2025 at 8 NFEs and the base model on 27 January 2026, with Z-Image-Edit still marked "to be released" in the official model zoo.

FLUX.1 Kontext and FLUX.2: fidelity with a license tax

Kontext is still the model that behaves best when you ask it to change exactly one thing. It was trained for editing only, and the thing it is genuinely good at is iterative editing: run five successive instructions on the same image and the subject drifts less than with anything else in its weight class. BFL's own human preference evaluation on KontextBench puts it ahead of several competing editors, which is a vendor benchmark and should be read as such. On StepFun's independent GEdit-Bench-EN, FLUX.1 Kontext [dev] scores 7.16 semantic consistency, 7.37 perceptual quality, 6.51 overall. That is behind both Qwen-Image-Edit-2509 and Step1X-Edit v1.1 on the overall metric. It edges Step1X-Edit v1.1 on perceptual quality by 0.02, and loses that column to Qwen-Image-Edit-2509 by roughly half a point.

Hardware is the easy part. NVIDIA and BFL published quantized checkpoints that take the model from 24GB at BF16 down to 12GB at FP8 for RTX 40 series cards and 7GB at FP4 for RTX 50 series, with TensorRT giving over 2x acceleration compared with the original BF16 model in PyTorch.

The hard part is the license. Kontext [dev] ships under the FLUX.1 [dev] Non-Commercial License, and FLUX.2 [dev] under the FLUX Non-Commercial License. Outputs from a non-commercial checkpoint are not something you can put in a client deliverable without buying a self-hosted commercial license from BFL. The FLUX.2 VAE is Apache 2.0, which does not help you, and FLUX.2 [klein] 4B is Apache 2.0, which does. If you want BFL quality with clean commercial terms and you can live with 4B, klein 4B is the only door.

FLUX.2 [dev] itself is a real step up in capability: image editing at resolutions up to 4 megapixels, and up to 10 reference images for holding a character, product or style consistent across a set. It does not fit a consumer card at full precision. BFL's own local deployment guidance for a 4090 or 5090 runs the text encoder and DiT in 4 bits with the VAE in BF16, or offloads the text encoder entirely.

import torch
from diffusers import FluxKontextPipeline
from diffusers.utils import load_image

pipe = FluxKontextPipeline.from_pretrained(
    "black-forest-labs/FLUX.1-Kontext-dev", torch_dtype=torch.bfloat16
).to("cuda")

out = pipe(
    image=load_image("input.png"),
    prompt="Add a hat to the cat",
    guidance_scale=2.5,
).images[0]
out.save("output.png")

Qwen-Image-Edit: the Apache 2.0 default

If you are shipping anything commercial, this is where you start. The architecture is a 20B MMDiT with a Qwen2.5-VL text encoder doing the instruction parsing, and the whole line is Apache 2.0 with no asterisk.

The 2509 release added multi-image editing through image concatenation, with best results at one to three input images and explicit support for person plus person, person plus product, and person plus scene compositions. It also added native support for ControlNet-style conditions, keypoint control and sketches, without a separate ControlNet model. 2511 is the one to actually use: it targets image drift directly, improves character consistency in group and multi-person shots, adds built-in support for community LoRAs, and strengthens geometric reasoning and lighting control.

On GEdit-Bench-EN, Qwen-Image-Edit-2509 scores 8.00 semantic consistency, 7.86 perceptual quality, 7.56 overall, the best of the pre-reasoning generation. It is also the best of these models at text rendering inside an edit, which matters more than it sounds: swapping a sign, a label or a UI string is a large fraction of real editing work, and Kontext will happily produce plausible-looking gibberish where Qwen produces the string you asked for.

ComfyUI has had native Qwen-Image-Edit support since v0.3.51 on 20 August 2025, with Diffsynth canny and depth ControlNets plus the InstantX Qwen ControlNet following three days later in v0.3.52.

import torch
from diffusers import QwenImageEditPlusPipeline

pipe = QwenImageEditPlusPipeline.from_pretrained(
    "Qwen/Qwen-Image-Edit-2511", torch_dtype=torch.bfloat16
).to("cuda")

out = pipe(
    image=[img1, img2],
    prompt="Put the person from image 1 in the room from image 2",
    negative_prompt=" ",
    true_cfg_scale=4.0,
    num_inference_steps=40,
).images[0]

Step1X-Edit and the reasoning-edit branch

Step1X-Edit v1.2, released 26 November 2025 and referred to as ReasonEdit-S in the paper, is a native reasoning editor: it thinks about the instruction before it edits, and optionally reflects on the result. The version progression on GEdit-Bench-EN is the clearest evidence in this space that reasoning helps for editing, not just for text.

v1.0 scored 6.44 overall and v1.1 scored 6.97. Within v1.2 the ablation is the interesting part: the base configuration scores 7.24 overall, turning on thinking takes it to 7.36, and thinking plus reflection reaches 8.18 semantic consistency, 7.85 perceptual quality, 7.58 overall. Same weights, roughly a third of a point of overall score bought purely with inference-time reasoning.

The bill comes due in memory. StepFun publishes a GPU memory table for batch size 1 at 28 steps across 512, 786 and 1024 pixel inputs, and it is not friendly: 42.5 to 49.8GB in the default configuration, 31 to 34GB with FP8 weight quantization, 25.9 to 29.1GB with CPU offload, and 18GB with both. Inference runs 5 to 22 seconds at standard precision and 6.8 to 25 seconds with FP8, so quantization here buys memory at almost no speed cost. Offloading is the expensive lever: the same runs take 49.6 to 63.2 seconds with CPU offload alone, and 35 to 51 seconds with FP8 plus offload.

python inference.py --input_dir ./examples --model_path /path/to/model \
    --output_dir ./output --quantized --offload

--quantized enables FP8 weight quantization and --offload moves modules to CPU. Community FP8 conversions exist on Hugging Face if you do not want to quantize locally.

Side by side: license, VRAM, speed

The license column is the one most people get wrong, so read it first.

Model	Size	License	Commercial output	Practical VRAM	Strongest at
FLUX.1 Kontext [dev]	12B	FLUX.1 [dev] Non-Commercial	Paid BFL license required	24GB BF16, 12GB FP8 (RTX 40), 7GB FP4 (RTX 50)	Low drift across iterative edits
FLUX.2 [dev]	32B	FLUX Non-Commercial	Paid BFL license required	4-bit text encoder and DiT on a 4090 or 5090	Multi-reference, up to 10 refs, 4MP
FLUX.2 [klein] 4B	4B	Apache 2.0	Yes	4-bit builds run on 6 to 8GB	Speed with clean terms
FLUX.2 [klein] 9B	9B	Non-commercial	No	4-bit builds run on 6 to 8GB	Quality at small size
Qwen-Image-Edit-2511	20B MMDiT	Apache 2.0	Yes	Q4_K_M GGUF fits a 16GB card	Text rendering, multi-image compositing
Step1X-Edit v1.2	MLLM plus DiT	Apache 2.0	Yes	49.8GB default, 34GB FP8, 18GB FP8 plus offload	Reasoning-heavy instructions
MagicQuill	SD1.5 based	CC BY-NC 4.0	No	8GB, tested on a 4070 laptop	Brush-driven local edits
MagicQuillV2	Layered cue system	Non-commercial in practice	No	Heavier than v1, not published	Layered visual cues
SUPIR	SDXL plus LLaVA	Non-commercial	No, written permission required	12GB diffusion plus 16GB LLaVA	Photorealistic restoration
Z-Image	6B	Apache 2.0	Yes	16GB for Turbo	Edit variant not yet released

Identity preservation is mostly a workflow problem

Every one of these models degrades a face a little on each pass. The difference between models is how fast, not whether. Kontext was explicitly built to minimize drift across successive edits, Qwen-Image-Edit-2511 lists drift mitigation as its headline change, and neither of them makes the problem go away over ten iterations.

The fix is structural, not a better prompt. Mask the region you intend to change, edit, then composite the untouched pixels back. SAM 3, released in November 2025, is the right masking model now because it does promptable concept segmentation: give it a short noun phrase or exemplars and it exhaustively segments every instance of that open-vocabulary concept in one pass, rather than one object per prompt as in SAM 1 and 2. The SAM License permits commercial use, with explicit carve-outs for ITAR-controlled activity, military or warfare purposes, nuclear applications, espionage, and guns or illegal weapons. SAM 3.1 Object Multiplex followed on 27 March 2026 with shared-memory joint multi-object tracking, which matters if you extend the pipeline to video.

For faces specifically, an identity conditioner is worth the extra latency. IP-Adapter remains the general-purpose reference injector and composes cleanly with most of these pipelines. The more important habit is measuring instead of eyeballing: run the source and the edit through InsightFace and gate on cosine similarity of the face embedding. Pick a threshold once, then let the pipeline reject and retry automatically. This single change catches more bad edits than any amount of prompt tuning.

When the subject is one you will edit repeatedly, train a LoRA. diffusion-pipe is the practical trainer here: GPL-3.0, and its supported model list covers Qwen-Image-Edit, Flux Kontext, Chroma, Z-Image and Wan2.2, with documented low-VRAM levers including block swapping, the AdamW8BitKahan optimizer, and expandable CUDA segments. Qwen-Image-Edit-2511 having built-in LoRA support means a subject LoRA drops into the editing pipeline without an adapter shim.

Quantization: what 4-bit actually costs

There are three viable routes and they are not equivalent.

GGUF is the low-friction one. ComfyUI-GGUF adds quantized UNet loading to native ComfyUI models, and community conversions exist for essentially everything. A Q4_K_M conversion of the 20B Qwen-Image-Edit lands in the low teens of gigabytes, which is what makes that model tractable on a 16GB card.

# drop the quantized transformer here, then use the Unet Loader (GGUF) node
ComfyUI/models/unet/qwen-image-edit-2511-Q4_K_M.gguf

Native ComfyUI precision support has caught up fast. Initial NVFP4 checkpoint support arrived in v0.8.0 on 7 January 2026, along with the guard that skips fp4 matrix multiplication on devices that cannot do it. int8 model support landed in v0.27.0 on 30 June 2026, including int8 on Turing GPUs and faster int8 LoRA application, and v0.28.0 on 15 July 2026 extended the same treatment to int4 with convrot int4 models and Turing fixes. The current release is v0.29.0 from 29 July 2026.

Nunchaku is the one that actually changes what hardware you need. It implements SVDQuant, an ICLR 2025 spotlight technique that quantizes both weights and activations to 4 bits (W4A4) while migrating outliers into a 16-bit low-rank branch derived by SVD. On 12B FLUX.1-dev that is a 3.6x reduction in model size versus BF16 and about 3.5x lower memory use, plus a 3.0x speedup over an NF4 W4A16 baseline on RTX 4090 hardware. On a 16GB laptop 4090 the end-to-end gain reaches 8.7x versus the 16-bit model, because eliminating CPU offloading matters more than the arithmetic. Nunchaku added FLUX.1-Kontext support on 29 June 2025, 4-bit Qwen-Image-Edit-2509 on 24 September 2025 with 4-step and 8-step lightning variants the following day, and INT4 support for 20-series cards in v1.2.0 on 12 January 2026.

Stack that with step distillation and the step counts collapse. The lightx2v Qwen-Image-Edit-2511-Lightning LoRAs ship in bf16 and fp32 at 4 steps, with an fp8 e4m3fn scaled checkpoint for lower memory, and the model card puts the result at roughly an order of magnitude fewer steps than the standard 40-step path.

What you actually lose at 4 bits, in rough order: fine typography and small text degrade first, then material texture, then subtle color grading, then identity. If your edits involve rendering text, benchmark FP8 against 4-bit on your own prompts before committing, because that is where the gap is widest.

On Apple Silicon the picture is different. mflux is an MIT-licensed set of MLX-native reimplementations covering FLUX.1 including the Kontext editing path, FLUX.2 in 4B distilled and 9B base variants, Qwen Image at 20B, and Z-Image at 6B in both distilled and base form. A native MLX path is worth the setup cost on a Mac rather than fighting the general CUDA-first stack.

Brush driven editing and restoration

MagicQuill

MagicQuill is the answer to a category of edit that instructions handle badly. When the change is spatial rather than semantic, "make this edge sharper", "move this 40 pixels left", "add a strap right here", a sentence is a lossy way to express intent. MagicQuill, a CVPR 2025 system, gives you add, subtract and color brushes plus a multimodal model that guesses the prompt from your scribble. The project states it runs on GPUs with 8GB of VRAM, tested on a 4070 laptop, and recommends disabling the automatic prompt prediction if that step is slow on your hardware. The license is CC BY-NC 4.0, so it is a research and personal tool.

MagicQuillV2 arrived in December 2025 with a layered composition paradigm: four visual cue layers covering content (what to create), spatial (where to place it), structure (how it is shaped) and color (its palette), a local edit brush, a visual cue manager for dragging elements onto the canvas, and a SAM-backed segmentation panel. It is heavier than v1 and the project does not publish a VRAM figure or a per-image time, so budget for a workstation card rather than a laptop. Treat it as non-commercial unless the authors say otherwise.

If you want the same interaction model in something you can actually work in daily, Krita AI Diffusion is the better bet. It covers FLUX.2, Z-Image and the SD1.5, SDXL and Illustrious line, and it exposes edit models as a first-class mode where you describe the change in text instead of tuning inpaint parameters, with a separate custom generate path when you want plain inpainting.

SUPIR

SUPIR is still the reference for photorealistic restoration in the wild. It builds on SDXL with LLaVA generating the restoration caption, and ships two checkpoints: v0Q with the paper's default training settings, which generalizes well and handles heavier degradation, and v0F trained on light degradation, whose stage-1 encoder retains more detail on nearly clean inputs. With --loading_half_params, --use_tile_vae and --load_8bit_llava it fits in roughly 12GB for the diffusion side plus 16GB for LLaVA.

The license is the problem again. SUPIR is made available strictly for non-commercial purposes and commercial use requires prior written permission from the author. The widely used ComfyUI-SUPIR wrapper inherits that restriction. For commercial restoration work the honest stack is Real-ESRGAN for background and general upscaling plus GFPGAN, which is Apache 2.0, for faces. CodeFormer is often suggested as the better face restorer, and it is, but it ships under the NTU S-Lab License 1.0, which is a research and non-commercial license. A Qwen-Image-Edit pass with a restoration instruction is a genuine third option now, and it is the only one in this paragraph with a clean license end to end.

Wiring it together in ComfyUI

The pipeline shape that works is not model-specific. Caption, mask, edit, composite, verify, restore.

git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
pip install -r requirements.txt
git clone https://github.com/ltdrdata/ComfyUI-Manager custom_nodes/ComfyUI-Manager
git clone https://github.com/city96/ComfyUI-GGUF custom_nodes/ComfyUI-GGUF
python main.py --listen 127.0.0.1

From there, install the rest through the manager rather than by hand. The concrete graph:

1. Caption the source with a small VLM (Florence-2 is fast enough to run per image) and build the instruction from the caption plus your change, rather than writing the instruction blind. Instruction fidelity improves measurably when the model is told what is already there.
2. Mask the target region with SAM 3 driven by a noun phrase from that caption.
3. Run the editor. Keep the editor node in a subgraph so you can swap Kontext for Qwen-Image-Edit without rewiring, which is the main practical reason subgraphs are worth adopting.
4. Composite the original pixels back outside the mask, feathered. This is the step most people skip and it is the single largest source of global drift.
5. Gate on an identity or structural similarity check before the image leaves the graph.
6. Restore and upscale last, never first.

If a node graph is the wrong interface for your work, InvokeAI has caught up substantially. v6.11.0, released 27 January 2026, added the FLUX.2 Klein family for both generation and editing, including standalone 4-bit quantized builds that Invoke says run on cards with 6 to 8GB of VRAM, and Klein editing accepts multiple reference images so you can transfer visual elements between them. Separate Qwen3 4B and 8B text encoders ship alongside the two Klein sizes.

How to choose

If you are shipping commercial output, the decision is made for you: Qwen-Image-Edit-2511 for general editing and text-heavy work, Step1X-Edit v1.2 when the instruction requires reasoning and you have 18GB or more to spend, both Apache 2.0. FLUX.2 [klein] 4B is the Apache 2.0 option when latency matters more than fidelity.

If output is for research, personal work, or you have already bought a BFL license, Kontext still wins on iterative stability and FLUX.2 [dev] wins on multi-reference composition. Do not use FLUX weights for client work on the assumption that "open weights" implies permission, because it does not.

On 8 to 12GB, run 4-bit Qwen-Image-Edit through Nunchaku with a lightning LoRA, or Q4_K_M GGUF with offload if Nunchaku does not have your combination quantized yet. On Apple Silicon, use mflux.

The thing to watch is Z-Image-Edit. A 6B Apache 2.0 editor that runs in 16GB, from a family whose Turbo variant already produces competitive output at 8 NFEs, would compress the entire low-VRAM tier of this comparison into one row. The official model zoo still lists it as to be released. Until it lands, the 20B Apache 2.0 model quantized to 4 bits is the pragmatic floor.