MOSS-Image vs Ideogram 4.5: How Much Text Can You Actually Put in a Picture

Both of these models were built by people who noticed that image generators are bad at words. I​deogram 4.5, live since 30 September 2026, is the fourth generation of a model whose entire reputation rests on typography, and its documentation treats text as a first-class element with its own field in a structured prompt. 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, takes the same structural approach — each text element gets a literal string and a bounding box — and then points the whole thing at a much longer target: literary passages at a mean length of roughly 1,340 characters.

That difference in ambition is the axis this comparison actually turns on, and the two vendors' own documentation is unusually candid about it. I​deogram tells you where its ceiling is. OpenMOSS claims to have raised it. One of those two statements you can check against a published number; the other you can check against a published warning label. Reading them together tells you more about the state of text rendering in image models than either one alone.

The two JSON schemas, and why they are not interchangeable

Both models accept a structured prompt in which text is not described but declared. The similarity is close enough to be misleading, so it is worth being precise about what each one actually carries.

I​deogram 4.5's JSON prompt — shared with 4.0 — gives each text element its own text field holding the literal string, a desc field describing how it should look, a color_palette, and a bbox for exact placement. The palette budget is documented: up to 16 hex colours for the whole image, and up to five per element.

M​OSS-Image's layout format takes a JSON object as the prompt: a summary block carrying the scene and style, and an items array where each element has a label of text, character or object, a caption, a bounding box, and — for text elements — the literal string to render. Boxes are bbox_format: "yxyx" in bbox_coord_space: "abs_centralized", meaning pixels measured from the centre of the canvas.

• Where the string lives — I​deogram 4.5: a text field per element. M​OSS-Image: the literal string on the text item, alongside a separate caption for how it should look.

• Colour control — I​deogram 4.5: up to 16 hex colours per image, five per element, as a documented palette budget. M​OSS-Image: no documented per-element palette field; style is carried in the summary block.

• Colour of the box — I​deogram 4.5: a bbox field with no coordinate convention published in the material we could read. M​OSS-Image: yxyx order in absolute centre-relative pixels, so a 1024² canvas runs −512 to +512 on each axis.

• Element taxonomy — I​deogram 4.5: text elements with a description. M​OSS-Image: a three-way label distinguishing text, character and object, which is what a recurring subject needs.

Two schemas, both JSON, neither one a superset of the other, and no converter published by anybody. If you have a pipeline that emits either format, the cost of supporting the other is a real piece of work — and the missing coordinate convention on I​deogram's side is a detail you would have to derive empirically.

What the vendors say about their own limits

This is the most interesting part of the matchup, and it is not a benchmark comparison. It is a comparison of two companies' willingness to describe where their model stops working.

I​deogram's documentation says it plainly: the model handles titles and short blocks well, and you should add body copy or full documents later in a design tool. It also says text comes out most accurately in English, and that non-Latin scripts and accented letters can come out wrong or not at all. On fonts, the guidance is that you cannot name one — the model has learned what text styles look like, not a font library — so the documented approach is to describe weight, shape and mood instead. And the JSON path has its own published failure mode: very long structured prompts can lose their trailing elements, so the most important things go first.

That is a vendor telling its customers the shape of the tool. Read as a specification, it describes a model for headlines, labels, packaging copy and short blocks — precision typography, not publishing.

OpenMOSS's published position is the opposite kind of claim. Its headline benchmark, LongLongTextBench, is 240 literary-text rendering tasks at a mean target length of 1,339.8 characters, split evenly between English and Chinese. The problem being attacked is not four words on a poster; it is a wall of prose rendered legibly inside an image. The vendor's own number for that on Mean-6 text coverage is 96.3, against 64.9 for Q​wen-Image-2512, with GPT Image 2 at 99.0 and N​ano Banana Pro at 96.6 in the same table.

So: one vendor has published a ceiling, and the other has published a score that implies a much higher one. Neither has been checked by a third party. If you are choosing between them for a specific job, this is the dividing line — and the honest way to read it is that I​deogram's limitation is documented and reproducible today by anyone who tries, while OpenMOSS's improvement is a single vendor's unreproduced measurement. The documented limitation is worth more to your planning than the unreproduced score, at least until somebody outside the lab runs the test.

What each is actually for

The text question is where they overlap. Almost everything else about them points in different directions.

I​deogram 4.5 is positioned as an editor, not a generator. Its precise-edit behaviour returns the result at the source image's own width and height, with pixels the edit did not meaningfully change copied exactly rather than re-synthesised, and it has been demonstrated on a 4,016 × 6,016 pixel source without downscaling the file first. Masked edits take a black-and-white mask — black marks what to change, white what to keep, in-between values round to the nearer of the two. The edit endpoint takes up to four reference images, three of those when a mask is also supplied; the generation endpoint takes up to five source images, the first of which is treated as the one being edited. Prompts run to 10,000 characters in the app, and quality is a four-rung ladder from very_low through low, medium and high.

M​OSS-Image is generation-first. The vendor describes editing an element's caption or moving its box as adjusting that part of the composition, and labels the behaviour experimental. Its control surface is the layout JSON above; its published demonstration is composition — posters, infographics, interfaces — rather than in-place editing of an existing photograph. Its training ran 256px for 2.1M steps, then 512px for 2.1M, then roughly 1024² for 0.31M, with the token budget moving 576 → 3,072 → 8,192 across those stages.

• Editing an existing image — I​deogram 4.5: core capability, output locked to source dimensions, untouched pixels copied. M​OSS-Image: experimental, described as adjusting elements of a composition you generated.

• Long text in a fresh image — M​OSS-Image: the headline claim, with a vendor benchmark at 1,339.8-character mean targets. I​deogram 4.5: documented as titles and short blocks, with body copy directed to a design tool.

• Weights — M​OSS-Image: Apache 2.0, no revenue threshold, about 27.2 GB including a frozen Qwen3.5-9B text encoder. I​deogram 4.5: none. The vendor's open-weights programme covers I​deogram 4.0 only, at $300 a month for 10,000 self-hosted images on quantised weights, explicitly not full precision.

• Price — I​deogram 4.5: a five-rung ladder from $0.008 at Very Low to $0.22 at High with a source image. M​OSS-Image: no rate card; the cost is your GPU time.

The number on one side and the blank on the other

I​deogram published no benchmark for 4.5. The scored figures come from Artificial Analysis, which carries the model on both image boards under the High configuration. Read on 16 October 2026: 1,063 Elo on image editing from 2,728 votes at $220 per 1,000 images, and 1,019 Elo on text to image from 2,421 samples at $100 per 1,000. The editing board's leaders are O​penAI's GPT Image 2.5 Sunburst and Flare at 1,198 and 1,177, so the top rung sits about 135 Elo above I​deogram 4.5, on an interval of 1,046 to 1,080 that overlaps several models around it.

There is a caution that applies to using that number for this comparison at all, and it is not about sampling error. Both boards ask voters to prefer one image over another. Neither asks a voter to read the text in the image and judge whether it is spelled correctly, in the right script, or in the right place. An Elo that measures preference is not a measurement of typography, and I​deogram's own reputation for text is not something the board has ever scored. So the independent number, real as it is, does not cover the property that matters most in this matchup.

M​OSS-Image has no independent number of any kind. It is one day old, and both of its benchmarks ship with the release and were built by the vendor. Its second one, RealLayoutArena, is 61 design tasks — 20 posters, 20 infographics, 21 interfaces — judged pairwise and fitted to a Bradley–Terry scale; M​OSS-Image scores 1698.70 Elo end-to-end, behind GPT Image 2 at 1844.35, and 1807.34 restricted to the backbone under shared enhanced prompts, which is first. The pipeline that produced the end-to-end figure uses G​PT-6 for prompt specification at inference time, according to the technical report, which means the strongest end-to-end layout result carries a dependency on somebody else's model.

How you would choose, and what a router has to do with it

I​deogram 4.5 is closed and hosted from I​deogram's own API, its apps and an MCP integration. M​OSS-Image is a download. Neither is on the OrcaRouter catalogue — we serve more than 200 models and neither of these is among them — so both mean going to the vendor: in I​deogram's case through its own API and several third-party platforms, in OpenMOSS's case to the repositories and whatever hardware you can point at them.

The place a router earns its keep in a text-heavy image pipeline is the cost side, and the reason is specific to how these vendors price. I​deogram's ladder is documented as billing by resolved output pixels — up to 1024×1024 counts as 1K, above that as 2K — which means the same nominal tier can cost different amounts depending on what you asked for. When a vendor's pricing is a function of the request rather than a flat rate, the arithmetic of a hundred-image batch is not something you want to hold in your head, and a catalogue that passes provider list prices through with nothing added is what keeps the number moving with the vendor rather than lagging behind it. That applies to the hosted models you would benchmark an open checkpoint against, not to either of the two models in this piece.

The part neither vendor will say out loud

Put the two positions next to each other and a pattern shows up. I​deogram, which has been the typography model for years, tells you to put your body copy in a design tool. OpenMOSS, which is one day old, claims to have solved the body copy and scores itself on it.

One of those is a company describing a limit it has hit, and the other is a company describing a limit it believes it has passed. The first statement is verifiable by anyone with a free plan and an afternoon. The second is verifiable only by the people who built the benchmark, until somebody downloads the weights and tries. The weights are Apache 2.0, so that check is available to anyone — which is the strongest argument for M​OSS-Image in this comparison and has nothing to do with its score. You cannot audit a claim about I​deogram 4.5's long-text behaviour by inspecting the model. You can audit M​OSS-Image's by running it.

What neither side has published is a drift measurement. I​deogram 4.5's whole selling proposition is that edits do not corrupt the untouched parts of a frame, demonstrated on a 24.2-megapixel source without downscaling; no third party has scored that, and no benchmark asks the tenth edit in a sequence to be compared against the first. M​OSS-Image's editing behaviour is labelled experimental by its own vendor and unmeasured by anyone. Two models built around text fidelity, neither with a published fidelity score from anyone who is not selling them.

So the choice reduces to which uncertainty you can live with. If your job is headlines, packaging, product copy and short blocks, and it is coupled to editing an existing photograph in place, I​deogram 4.5 is the model with the documented behaviour, the published size rules and an independent, if non-typographic, score — and a vendor explicitly telling you when to reach for a design tool instead. If your job is composed pages with long passages and you want to own the stack, M​OSS-Image gives you the weights, the schema and the only benchmark that attempts long-form text at all, on condition that you accept it as a claim until you reproduce it. The first is a safer purchase and the second is a testable one, and which of those you want is not something either vendor's page can tell you.

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.