How to choose a text-to-image model (without a Twitter thread)
"What's the best text-to-image model?" is a question with no answer and a thriving economy of threads pretending otherwise. The answerable question is narrower and more useful: best at what job, under what latency, at what price? Sorted that way, the crowded 2026 model landscape collapses into about four classes — and most products need at least two of them.
The four axes that actually differentiate models
- Prompt fidelity. Does it render what you asked — compositional details, counts, spatial relations, negations — or a handsome approximation of the vibe? This is the axis where model generations genuinely improved year over year.
- Text and typography. Legible words inside the image remain a separator. If your use case involves signage, packaging, UI mockups, or memes, test this first; it eliminates half the field immediately.
- Latency class. Interactive (a user is watching a spinner) versus batch (a pipeline fills a queue). Models cluster strongly here — distilled "schnell-class" models answer in a second or two; large flagship models take tens of seconds.
- Cost per kept image. Not cost per generation — users iterate, so a cheap model you regenerate six times can cost more than a precise one you accept twice. Prices differ by an order of magnitude across this landscape; check live, dated prices rather than screenshots of pricing pages past.
A working taxonomy, with names
| Class | Examples | Reach for it when |
|---|---|---|
| Draft | FLUX.1 [schnell] · Z-Image Turbo | Interactive previews, thumbnails, high-volume iteration |
| Workhorse | FLUX.1 [dev] · FLUX 1.1 [pro] | Production default: strong fidelity at sane cost |
| Art direction | FLUX 1.1 [pro] ultra · FLUX 2 [pro] | Hero assets, campaign imagery, resolution and control |
| Instruction | gpt-image-1 | Layout-following, in-image text, edit-style requests |
The classes matter more than the names, because the names rotate. Whatever replaces this year's draft-class leader will still be a draft-class model: the role is stable even though its occupant retires on a twelve-to-eighteen-month cycle.
Evaluate like you'll be wrong
Public leaderboards measure averages over other people's prompts; you ship on your own distribution. The cheapest credible eval we know:
- Fix a prompt set from production. Twenty to fifty real prompts, deliberately including your known hard cases — hands, embedded text, brand colors, negations ("no people"), multi-object scenes.
- Run every candidate through one API shape. If each model requires its own integration, you'll evaluate two and give up; capability-based routing makes the N-model bake-off one loop over a model parameter.
- Judge blind, count keeps. Shuffle outputs, hide model names, have the people who'll actually use the images pick. The metric is keeps-per-dollar, not prettiness-per-image.
- Keep the receipts. Record which model produced which output with parameters and timestamps — both to make the eval reproducible and because "which model made this?" becomes a compliance question the moment a winner ships.
Then stop choosing — route
The end state isn't one winner. It's a routing policy: draft-class for the interactive preview loop, a workhorse for final renders, an instruction-class model when in-image text appears in the request, art-direction class behind the "high quality" toggle. Users see one feature; the router sees four jobs with different economics.