MOSS-Image vs FLUX 3: Two Ways to Put a Bounding Box in a Prompt

The most interesting thing about comparing M​OSS-Image with FLUX 3 is that both of them, within the last month, arrived at the same conclusion — that the way to control an image model is to write coordinates into the prompt — and then disagreed about the coordinate system. On October 16, 2026, OpenMOSS released M​OSS-Image-Base and M​OSS-Image-SFT under Apache 2.0: a 5B diffusion transformer, downloadable, with a JSON layout format that positions elements by absolute pixel offsets measured from the centre of the canvas. Black Forest Labs got there first with F​lux 3 Image, live since October 1 with a published rate card, which takes every box as [top, left, bottom, right] in integers from 0 to 1000, relative to a fixed grid. Same idea, incompatible grammar, and only one of the two gives you a file you can keep.

That difference — not image quality — is what decides this matchup for most teams, and it decides it faster than any benchmark. So the comparison below is organised around it. Every M​OSS-Image figure is OpenMOSS's own, taken from the release and its technical report, and none of it has been reproduced by anyone. Every F​lux 3 figure is Black Forest Labs' own published rate card and release material. There is no independent head-to-head between these two models, and there will not be one for a while.

What each side actually shipped

M​OSS-Image is a pair of checkpoints, M​OSS-Image-Base and M​OSS-Image-SFT, with weights and inference code under Apache 2.0, a ModelScope mirror, a Gradio Space, a Diffusers custom pipeline, and a native ComfyUI plugin. ComfyUI core support landed the same day the weights did. There is no hosted endpoint from OpenMOSS and no published price, because there is nothing to price — you run it or you do not.

F​lux 3 is the opposite shape. Black Forest Labs announced it in July 2026 as a single architecture trained across video, image and audio, and the still-image tier — F​lux 3 Image — opened with public pay-as-you-go pricing on October 1. The open-weight counterpart, FLUX 3 Image Klein, followed on October 15 under the FLUX Kommunity License, which permits free commercial use only below a revenue ceiling. So B​FL does now offer both a rented path and a downloadable one, but they are different models with different licences, and the download is the smaller sibling rather than the flagship.

Neither model is on our own catalogue. OrcaRouter serves more than 200 models and M​OSS-Image is not one of them, so nothing here should be read as us offering it — the same is true of F​lux 3. What the router is useful for in this comparison is the other half of the loop: when you want to put a self-hosted checkpoint up against hosted image models on the same prompts, the hosted side is reachable through one API key, at provider list price with no markup added on our side, with automatic failover between providers if one of them degrades mid-run.

The box grammars, side by side

This is where the two diverge in a way that a config file will notice.

• Coordinate space — M​OSS-Image: absolute pixels measured from the canvas centre, using bbox_coord_space: "abs_centralized", so on a 1024×1024 canvas each axis runs from −512 to +512. F​lux 3 Image: normalised integers 0 to 1000 measured from the top-left corner.

• Coordinate order — M​OSS-Image: bbox_format: "yxyx", meaning [y_min, x_min, y_max, x_max]. F​lux 3 Image: [top, left, bottom, right], which is the same four numbers in the same order under a different name.

• How it reaches the model — M​OSS-Image: one JSON object passed as the prompt string, with a summary block for scene and style plus an items array where each element carries a label, a caption, and for text elements the literal string to render. F​lux 3 Image: a JSON array of boxes written into a normal prompt, with no extra parameter required.

• Resolution coupling — M​OSS-Image's coordinates are pixels, so they are only correct for the width and height you asked for; change the output size and you re-derive every box. F​lux 3's 0–1000 grid is resolution-independent by construction: [0, 0, 500, 500] is the top-left quarter of whatever canvas you request.

• What the box is for — M​OSS-Image is presented as generation control first, with the vendor noting that editing an element's caption or moving its box adjusts that part of the composition, described as experimental. F​lux 3 Image pairs layout with box-scoped multi-turn editing as a headline capability.

That last bullet is the practical split. F​lux 3's grid survives a change of output resolution; M​OSS-Image's does not, but M​OSS-Image lets you name the exact string you want rendered inside a text element rather than describing it. If your pipeline re-renders at different sizes, the grid is a real advantage. If your pipeline renders posters with fixed dimensions and specific copy, absolute pixels are not a burden.

Text rendering, where the only numbers are the vendor's

M​OSS-Image's headline capability is legible text, and the vendor built two benchmarks to measure it. On LongLongTextBench — 240 literary-text rendering tasks at a mean target length of about 1,340 characters — M​OSS-Image scores 96.3 on Mean-6 text coverage, against 64.9 for Q​wen-Image-2512. The row above it in the same table is GPT Image 2 at 99.0 and N​ano Banana Pro at 96.6, which is worth noting: OpenMOSS published a table in which competitors still win.

Black Forest Labs published no text-rendering benchmark for F​lux 3 Image at all. There is no number to put next to 96.3, from either side, and inventing a comparison from sample images would be the kind of thing this blog should not do. What can be said is that FLUX.2's VAE is the one M​OSS-Image uses — M​OSS-Image's own model card notes it loads the FLUX.2 small decoder — so the two families are not strangers at the pixel level even though the generators are unrelated.

Cost: one number versus five

• M​OSS-Image — free to download, Apache 2.0, no revenue threshold and no commercial tier. The cost is hardware: the SFT repository totals roughly 27.2 GB, of which about 16.8 GB across four shards is the frozen Qwen3.5-9B text encoder and about 10.2 GB across three is the transformer. Budget for the encoder, not the badge.

• F​lux 3 Image — $0.041 at 768×768, $0.048 at about 1 megapixel, $0.07 at 1.5K, $0.10 at 2K and $0.607 at 4K, per image, from Black Forest Labs' own rate card. A 50% launch discount ran from October 1 to October 8 and has expired, so any cost model built on it needs a second line at full rate.

• FLUX 3 Image Klein — $0.008 at 768×768 rising to $0.036 at 4K, and text-to-image and editing cost the same. It is dramatically cheaper than the 5B download it competes with in labour, if not in licence.

The honest framing is that these are not the same purchase. M​OSS-Image trades money for GPU hours and engineering; F​lux 3 Image trades money for someone else running the stack and is priced per delivered image at a rate that rises steeply with resolution.

What neither side has published

There is no independent benchmark of M​OSS-Image. There is no independent benchmark of F​lux 3 Image either — B​FL shipped the image tier with no comparison numbers against any other image model, vendor-run or otherwise. Neither model has a row on a neutral leaderboard that anyone can point at. When both sides of a comparison are unevidenced, the correct conclusion is not that they are equally good; it is that you cannot currently tell, and that the tiebreaker has to be something you can actually measure — licence, format, latency on your own hardware, and whether the box grammar matches the code you already have.

Two things would change that. An independent run of LongLongTextBench or RealLayoutArena by anyone other than OpenMOSS would be the first real evidence for M​OSS-Image's central claim. A third-party layout-control comparison on the B​FL grid would do the same for F​lux 3 Image. Neither exists yet.

Which one you would actually pick

Take M​OSS-Image if the deliverable is a composed page — poster, infographic, product mockup — where specific text has to land in specific places and where you want the weights in your own infrastructure. The Apache 2.0 licence makes commercial review short, the Base checkpoint was deliberately left undistilled so LoRA training has something to bite on, and the JSON layout is the part of the model the vendor measured most carefully. Budget the encoder and expect to supply structured JSON rather than prose: the vendor's own ablation put JSON layout prompts at 1622.87 Elo against 1506.20 for natural language on the same system, which is a large gap and the clearest signal in the release.

Take F​lux 3 Image if you need a callable endpoint today, if your outputs vary in resolution, or if you want box-scoped edits across multiple turns as a supported feature rather than an experimental one. The 0–1000 grid is resolution-independent, the rate card is public, and there is a cheap open-weight variant beside it if the licence ceiling is acceptable.

The thing to watch is the box grammar. Whichever convention your tooling adopts first is the one you will keep, and right now the two conventions are incompatible — absolute centre-relative pixels in yxyx order on one side, normalised top-left integers on the other. A small adapter function converts between them. The reason it matters is that it is the only part of this comparison that is fully knowable today.

The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.