MOSS-Image vs HY-Image 3.5: Both Sell You Rendered Text, and Only One Shows You the Test

Ask either vendor what their image model is actually for and you get the same answer. M​OSS-Image, released by OpenMOSS on October 16, 2026 as the Apache 2.0 checkpoints M​OSS-Image-Base and M​OSS-Image-SFT, leads with text rendering and layout. H​Y-Image 3.5, T​encent's current image model inside the H​unyuan line, leads with improved accuracy on text rendered inside the image — in Chinese and in English both. Two vendors, five thousand miles apart, picking the same capability to advertise, which is a fair signal about where the category's real failure mode has been for the last two years.

The two claims, however, arrive in completely different packaging. One of them comes with a benchmark and a number. The other comes with a sentence. That asymmetry — not image quality, which nobody has measured across these two — is the whole comparison, and it is worth working through carefully because the number that exists is a vendor's own and the sentence that doesn't is from a vendor with more history.

What "text rendering" means on each side

T​encent's claim is a claim about correctness across two scripts. H​Y-Image 3.5 is documented as improving the accuracy of text drawn inside the image, and the material is explicit that this covers Chinese and English. That is a narrower and more practical claim than it sounds. Chinese is the script most Western image models handle worst — glyph density is higher, the character inventory is thousands deep rather than dozens, and a model that renders plausible-looking Latin letterforms can render entirely invented hanzi without anyone noticing until a proofreader does. A vendor whose home market writes Chinese has an obvious reason to attack that first, and T​encent has said so directly.

OpenMOSS's claim is about length rather than script coverage. M​OSS-Image's headline demonstration is paragraphs — literary text at a mean target length of roughly 1,340 characters, held legibly across an image. That is a different problem from getting four characters of Chinese right. It is the difference between rendering a wordmark and rendering a page.

• What the vendor leads with — M​OSS-Image: long-form text rendering, with layout as the control mechanism. H​Y-Image 3.5: text accuracy in Chinese and English, with subject consistency across repeated edits.

• What the interface gives you — M​OSS-Image: a JSON prompt with a summary block and an items array, where each text element carries a bounding box and the literal string to render. H​Y-Image 3.5: a natural-language prompt, plus reference images for the editing direction. No documented per-element string field.

• What the output ceiling is — M​OSS-Image: trained over 576, then 3,072, then 8,192 tokens across three resolutions, with the final stage at roughly 1024². H​Y-Image 3.5: up to 2K, in T​encent's own words.

• What governs the weights — M​OSS-Image: Apache 2.0, no revenue threshold. H​Y-Image 3.5: nothing published. No checkpoint, no local licence, no offline route.

• What you pay — M​OSS-Image: nothing for the licence. H​Y-Image 3.5: $0.024 for a 2K image on the international endpoint, ¥0.15 domestic, billed on delivered output images only.

That fourth bullet deserves a sentence of its own, because it is the one thing about this matchup you can act on today. If text rendering is the reason you are choosing between these models, you can only inspect the behaviour of one of them on your own machine. Testing M​OSS-Image on your own copy means downloading 27.2 GB and running it; testing H​Y-Image 3.5 means sending prompts to T​encent and looking at what comes back.

The one number in this comparison, and what it is worth

M​OSS-Image has a benchmark. LongLongTextBench is 240 literary-text rendering tasks — 120 English, 120 Chinese — at a mean target length of 1,339.8 characters, and OpenMOSS scores M​OSS-Image at 96.3 on Mean-6 text coverage against 64.9 for Q​wen-Image-2512. The same table places GPT Image 2 at 99.0 and N​ano Banana Pro at 96.6, which is worth noting twice: it is a table in which a competitor wins, and it is a table in which M​OSS-Image's margin over the model it beats is larger than its deficit to the models ahead of it.

Now the caveats, which are not small. LongLongTextBench is OpenMOSS's own benchmark, built for this release, run by OpenMOSS, on OpenMOSS's own system. Mean-6 text coverage is OpenMOSS's own metric. Nobody outside the lab has reproduced any of it. It is the first vendor number in this category that attempts to measure long text at all, and it is also exactly the kind of number that a vendor builds when it has something to show.

H​Y-Image 3.5 has no number here at all. Not a published one, and not an independent one — no board scores either of these two models on text rendering, and the independent boards that do carry T​encent's model don't attempt text. So the text question, which is the thing both vendors chose to lead with, is the one question this comparison cannot answer with evidence from both sides. One vendor published a test. The other published a claim. That is the state of play, and any piece that puts a figure next to H​Y-Image 3.5 on this axis has invented it.

Where independent evidence does exist, and it is only half a comparison

T​encent's model is on the Artificial Analysis boards under the designation HunyuanImage 3.5 (Preview), which is itself useful because it corroborates the naming: the preview label is the model's current state, not a historical one. The identifier in circulation is hy-image-v3.5-preview, and no second, stable identifier sits beside it. On the text-to-image board it ranks in the middle of the field at 976.02 Elo. On the image-editing board it lands in the top fifth, at 1,088 Elo across 5,775 blind comparisons — the leaders there are O​penAI's GPT Image 2.5 Sunburst and Flare at 1,198 and 1,177, so T​encent sits about 110 Elo below the frontier on intervals of roughly ±14.

That editing placement is the interesting one for this matchup, and not because of the rank. It is the board that partly covers the capability T​encent actually advertises. Editing a subject repeatedly without it drifting is the second half of T​encent's text-and-consistency pitch, and a top-fifth editing Elo is at least loosely consistent with the consistency claim. It is not a measurement of text, and it is not a measurement of drift across a sequence, but it is independent, which is more than anything on the M​OSS-Image side has.

M​OSS-Image is not on those boards. It is one day old. Its second benchmark, RealLayoutArena, is 61 design tasks judged by blind pairwise comparison and fitted to a Bradley–Terry scale — 20 posters, 20 infographics, 21 interfaces — and it also ships with the release and was also built by the vendor. On the end-to-end arena, M​OSS-Image scores 1698.70 Elo, second to GPT Image 2's 1844.35; restricted to the backbone alone under shared enhanced prompts, it takes first at 1807.34. Same release, same party, same caveat.

Chinese, which is where the two claims actually meet

Here is a structural difference that neither vendor will point out and that matters more than either benchmark row.

OpenMOSS built a bilingual text benchmark deliberately balanced — 120 English tasks and 120 Chinese tasks, an even split. That is a design choice, and it says the model was evaluated as a bilingual product rather than an English one with Chinese as a bonus. M​OSS-Image's training corpus came out of ReLAION-derived data trimmed from roughly 5B samples to 3B with no further filtering, and the layout format's items array takes a label of text, character or object — a taxonomy that reads as script-agnostic on purpose.

T​encent's position is the mirror image. Chinese is the home market; the product material describes the model as offering strong Chinese comprehension; the international endpoint is a second surface behind the domestic one, priced separately. T​encent did not have to build a balanced English/Chinese benchmark because Chinese was never the risk. What it has not done is publish how the English half performs.

So a team shipping Chinese-language assets has, on one side, a vendor with a Chinese-first product and an unpublishable English number, and on the other, a vendor with a deliberately balanced bilingual evaluation and no Chinese-market track record. Two different kinds of confidence and neither one is transferable to the other's market. The only way to settle it is a head-to-head on your own copy, and only one of these two models lets you do that. Run the Chinese strings you actually ship — product names, legal lines, hanzi that are easy to invent — through M​OSS-Image-SFT locally, and put the same strings against hy-image-v3.5-preview by API. That experiment costs an afternoon and settles more than both venders' material combined.

Cost, access, and the route question

The cost comparison is lopsided in one direction and the access comparison is lopsided in the other, which is why the decision rarely comes down to the invoice.

H​Y-Image 3.5 is $0.024 for a 2K image internationally — $24 per 1,000, which is the same figure restated per thousand that appears on the independent board, so the vendor's rate and the board's price column agree. Domestic it is ¥0.15 for a 2K image, and billing is on delivered output images only, so a filtered or failed request is not charged. At a hundred thousand images a month that is $2,400, with a documented failure mode that does not bill.

M​OSS-Image has no rate card. The licence is Apache 2.0 and the download is about 27.2 GB, of which roughly 16.8 GB across four shards is the frozen Qwen3.5-9B text encoder and about 10.2 GB across three is the transformer. The 5B badge describes the diffusion generator alone, and the encoder is the larger half of the download. Sampling defaults are flow-matching Euler at 50 steps with CFG 3.0 and shift 5.0; the default guidance path needs two transformer forwards per step, so the step count is not the cheap setting it looks like. Your hundred thousand images cost whatever your GPU time costs, and nothing else.

Where those two routes converge is that neither of them is a routing problem. M​OSS-Image is not on the OrcaRouter catalogue — we serve more than 200 models and it is not one of them — so the weights half of this comparison is your own infrastructure. H​Y-Image 3.5 is not on it either, and its documented route is T​encent's own API or T​encent's own products; T​encent has no checkpoint, no local licence and no offline path, and the ComfyUI nodes that exist for it call the API rather than running behind it. The honest description of both is the generic one: through the vendor's own API and, in T​encent's case, its first-party tools.

What the router is actually useful for here is the third thing, which is the experiment above. If you want to test how M​OSS-Image's local text rendering stacks up against hosted models rather than against a leaderboard, the hosted side is where the comparison bites, and putting a self-hosted checkpoint up against several hosted image models on identical prompts is the kind of job a single endpoint with automatic failover and provider list prices passed through unchanged is built for: one key instead of four integrations, and a run that finishes even when one provider has a bad hour. GPT Image 2 and G​oogle's image models are on that endpoint; M​OSS-Image is not.

Choosing between a shipped evaluation and a shipped product

Take M​OSS-Image if the specific thing you need is structured control over where text lands and how long it runs. The layout JSON names each text element's string and position explicitly, Apache 2.0 makes commercial review short, and the Base checkpoint was deliberately left undistilled — the model card says no post-training or distillation of inference parameters such as CFG was applied — which is a deliberate choice to leave something for LoRA training to work on. Go in knowing that both benchmarks carrying its name are the vendor's own, that the strongest end-to-end layout figure comes from a pipeline whose prompt-specification half is a third-party model rather than a small OpenMOSS module, and that the encoder dominates the download.

Take H​Y-Image 3.5 if you need a callable endpoint this week, if your assets are Chinese-language, or if you would rather buy a model with an independent editing placement than one with a vendor benchmark. Go in knowing that the identifier is a preview designation with no dated replacement, that the text claim is a sentence and not a score, and that the only independently measured thing about the model is a blind-preference average that says nothing about whether the untouched part of your frame stayed untouched.

The gap that would change this most is not a new model. It is a second party running LongLongTextBench on something that isn't M​OSS-Image, or T​encent publishing a text-rendering score for the preview. Neither exists, and until one does, the practical version of this comparison is a download against an API call and an afternoon spent on your own strings — which is a better use of the time than reading either vendor's table.

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.