Six AI Creative Models You Can’t Use as Advertised

An AI creative model audit is the least glamorous hour in a production plan and the one that saves the most time. Six image models currently circulating as production-ready — FLUX 3 Image, Grok Imagine Image 2.0, Midjourney, Imagen 4, Qwen-Image-3.0 and flux-2-dev — each carry a gap between how they read in coverage and what the vendor’s own page says you can call today.

The gaps are not all the same shape. One model is a roadmap item on a line whose shipping product is video. One is a live consumer product with the API explicitly still to come. One has never had a public API at any version. One has a shutdown date eight days after this post publishes. One launched with no weights, no licence and no listed price. And one is genuinely downloadable, genuinely free, and genuinely off-limits for anything you invoice.

None of that is vendor dishonesty. Pre-announcement is normal practice, “coming soon” is a statement not a denial, and a company that never claimed to have an API cannot be accused of overstating one. What went wrong in each case is that coverage outran the vendor page. This post runs all six through the same evidence standard — what the coverage claims, what the vendor’s own page shows, and what actually ships in a pipeline instead.

A model is available when a human can generate an image with it. A model is buildable when your code can call it, under a licence that covers the work you are being paid for, on a surface that will still exist when the campaign ships. Those are three separate tests, and most coverage only clears the first one.

The practical failure looks the same every time. A creative lead reads a launch write-up, picks a model, and the engineer discovers at integration time that there is no endpoint, no licence, or no runway. The cost is not the model — it is the week of plan that gets rebuilt around a substitute nobody evaluated.

We have written up this failure mode once before, on a model that circulated widely with no primary announcement at all — see our Wan 3.0 reality check for the same pattern at a different vendor. Six examples in one place is enough to call it a genre rather than an accident.

Naming is half of it. There is no OpenAI product called ImageGen 2, though the name circulates freely; OpenAI’s image model is GPT Image 2, API ID gpt-image-2, with the default snapshot gpt-image-2-2026-04-21. A wrong product name is a harmless mistake in a blog post and a failed deploy in a configuration file.

Every cell in the table below traces to a vendor-owned page or an official licence file, with one exception worth naming: no Midjourney page states outright that there is no public API, so that cell rests on the continued absence of any API documentation on Midjourney’s own site rather than on a positive vendor statement. The grouping is by failure shape rather than by vendor, because the shape is what determines your workaround: if there is no endpoint you need a different model, and if there is an endpoint with a condition on it you need a migration date in the plan.

Read down the middle column and the fairness point makes itself. Four of the six vendors said exactly what was true on their own page, in plain language, before anyone integrated anything. What was missing was not disclosure — it was the reader’s habit of opening the doc. If you want the price side of the same decision, our image-generation API pricing comparison is the companion table; this one is about whether the endpoint exists at all.

This is the entry most likely to be sitting wrong in someone’s planning doc right now. Black Forest Labs’ FLUX 3 announcement describes a multimodal architecture and then separates it into productized surfaces. Video and audio generation and editing through APIs and private weight access — FLUX 3 Video — is the surface that is live. Image synthesis and editing under the FLUX 3 name, and an open-weight FLUX 3 Dev release, are listed as future items on the same page.

The developer docs corroborate it from the other direction. They document text-to-video up to twenty seconds at FHD, image-to-video with pinned keyframes, video continuation and synchronized audio. There is no FLUX 3 Image endpoint documented anywhere in them. The docs also label the whole FLUX 3 line a preview model, with video editing and combined image-plus-video reference still described as arriving later — so even the shipping surface is short of its own roadmap.

The substitution is painless, which is what makes the error frustrating rather than fatal. FLUX.2 is a complete hosted family with a published price per tier, and it is what BFL has been shipping for image work all along. The only thing you lose by correcting the name is the assumption that you were getting a newer-generation image model than you were.

xAI’s Image 2.0 launch post, published August 7, 2026, is unambiguous about where the model lives. It names grok.com/imagine with a Quality Mode, and the Grok apps on iOS and Android. Then it ends with one sentence about programmatic access.

That is a promise, not a denial, and it will presumably be kept. The problem is the interval. Between the launch post and the endpoint, every write-up that treats Image 2.0 as an API-ready model is describing something you cannot call. The headline capabilities — region-targeted editing with a magic wand, segmentation, background removal with transparent export, multi-reference editing with up to five input images, and smart resize across ten named aspect ratios — are all described as consumer-surface features. Nothing on the page says they are exposed as discrete API parameters.

There is one programmatic route at the time of writing, and it is worth being precise about what it is. The Vercel AI Gateway added a preview model, xai/grok-imagine-image-2.0-preview, on August 8, 2026. That is a gateway offering an ID, not xAI publishing an endpoint — which matters for your contract, your rate limits and your dependency graph. We covered the gateway-key pattern in more depth in our note on reaching new creative models through a single gateway key.

xAI’s own pricing docs do list image model IDs with real rates. The quality tier reads $0.01 per image as a media fee plus $0.05 per image at 1K and $0.07 per image at 2K; the cheaper non-quality sibling reads $0.002 media plus $0.02 per image at both 1K and 2K. What the docs do not do is tell you whether either of those IDs is the model that launched as Image 2.0. The launch post names no API ID. Treat any mapping between the two as a plausible inference and nothing firmer.

Midjourney is the fairest entry on this list, because Midjourney has never claimed otherwise. There is no public API, at any version. Generation happens through the Discord bot and the web app, and that is the position at the time of writing.

The version number is worth getting right, because getting it wrong is itself an example of this post’s thesis. Midjourney’s Help Center currently announces that V8.2 is live, and Midjourney’s own update post opens by saying the company is launching its V8.2 image model. Any planning document still describing an earlier alpha as the current Midjourney is out of date — and our own batch anchor for this post had exactly that stale version in it until the vendor page corrected it.

Pricing is subscription-based rather than metered per image, gated by allocated GPU minutes rather than API credits. We are not printing tier figures here, because the numbers in circulation come from aggregators rather than a Midjourney-owned pricing page. Check the current plans on Midjourney’s site before you budget.

This is the only one of the six you can call from a first-party API right now, and it is the one with the shortest runway. Google’s own Gemini API documentation states plainly that the model is deprecated and will be shut down on August 17, 2026, and directs teams to migrate to Nano Banana for image generation. Counting from this post’s publication date, that is eight days.

The pattern is not a one-off. Veo 3 and Veo 2, Google’s older video line, already passed their shutdown on June 30, 2026. Google retires the previous generation once the successor is established, and it publishes the date well in advance. Treat the deprecation notice as the primary signal it is — the vendor is telling you the runway length before you build.

The named migration path is Google’s current Gemini-family image line: gemini-3.1-flash-image, marketed as Nano Banana 2, and gemini-3-pro-image, marketed as Nano Banana Pro. They are not like-for-like Imagen successors — different family, different pricing shape, with rates that vary by output resolution rather than a single per-image number. Price the resolution you actually ship at, on Google’s current pricing page, rather than assuming parity with your Imagen line item.

Sunset timing is a genre of its own and we keep a running list elsewhere — our model deprecation calendar tracks the dates across vendors. The buildability question here is narrower: a model with a published end date is not a model you start a quarter on.

Alibaba’s primary launch post for Qwen-Image-3.0, published in July 2026, is capability marketing end to end — rich content, authentic details, deep knowledge — with an access link to the Qwen chat surface. Scan the full post text for the words weights, licence, model card or benchmark and you get nothing. There is no download link and no API pricing.

The obvious question is whether that is a documentation gap. It is not. Alibaba Cloud’s Model Studio pricing page lists every other Qwen-Image model ID with a rate attached — qwen-image-max at $0.075 per image, qwen-image-plus at $0.03, qwen-image-edit-max at $0.075, qwen-image-edit-plus at $0.03, qwen-image-edit at $0.045, plus the 2.0 tiers below. There is no qwen-image-3 entry on it. The model is genuinely unlisted on the commercial API surface, not merely undocumented.

That is a reversal of Qwen’s own prior practice, where the earlier Qwen-Image generations shipped with permissive open weights and same-day technical reports — a pattern we are carrying forward from earlier work rather than re-verifying here. The 3.0 post gives no stated reason for the change. It may well be a staged rollout. What it is not, at the time of writing, is a weight drop you can plan around, and nobody should be promising a client open weights for it.

The advice to run FLUX locally and save the per-image fee is everywhere, and for personal or research work it is good advice. For client work it is a licensing violation. BFL’s own pricing table marks flux-2-dev as local only, with the note that it is open weights, non-commercial, and has no hosted API — the only tier in the FLUX.2 table treated that way. Every other tier is hosted and priced per image.

The licence file on the model’s Hugging Face repository names it the FLUX Non-Commercial License v2.1 and defines a Non-Commercial Purpose as any use where you do not receive direct or indirect payment arising from use of the model. Personal research, hobby projects and internal testing sit inside that. Anything connected to an invoice does not.

There is a subtlety here that is easy to get backwards, so state it precisely: the restriction is on running and deploying the model, not on the images it has already produced. The licence text indicates generated outputs may be used for personal, scientific and commercial purposes. That distinction does not rescue an agency workflow — you are still running the model to serve paying work — but it does mean the two questions are separate and should be asked separately.

The honest replacement is a hosted tier, and the cost is smaller than most teams assume. The table below converts each vendor list rate to a per-thousand-image figure using a single formula — total per-image rate × 1,000, where the total sums every per-image component the vendor lists, including any separate media fee — so the comparison is like for like. Where a vendor page says from a rate, the derived figure inherits the same floor.

A thousand production images on the cheapest licensed FLUX.2 tier lands around fourteen dollars. That is the entire cost of doing this correctly, which is a useful number to have in the room the next time somebody proposes local flux-2-dev for a paid deliverable. The broader commercial-risk picture — indemnification, provenance marking, what survives from model to editor to ad platform — is its own subject, covered in our walkthrough of the licensing traps in AI creative pipelines.

Every gap in this post was discoverable in advance on a page the vendor published. The check is short enough to run before a model enters a plan rather than after: find a documented endpoint with a request body, find the model ID on a pricing page, read the licence file rather than the licence badge, and search the model’s doc page for the word deprecated. If any of the four comes back empty, the model is a candidate, not a dependency.

The forward-looking read is that this gets worse before it gets better. Creative model releases are now staged — architecture announcement, consumer surface, API, weights — and coverage compresses those stages into one event because one event is the story. As long as launch posts and endpoints ship weeks apart, the gap between what is announced and what is callable is structural, not accidental. The practical consequence is that model choice should sit behind a routing layer you can swap, not hard-coded into a creative workflow.

One example of the discipline in the other direction: a shutdown date for Sora 2 has been circulating, and we are not repeating it as fact. OpenAI’s own video-generation guide still documents both sora-2 and sora-2-pro normally, and the date could not be confirmed on an OpenAI page. Unconfirmed is a valid answer. It is also a reason not to start a new pipeline on that model until it resolves either way.

Where this bites hardest is budgeting, because a substitute model rarely costs what the original was assumed to cost, and the re-plan usually lands mid-flight. The cheaper habit is to price the draft tier and the final tier separately before committing to either, which we work through in our piece on draft-tier economics. If you would rather not maintain this surveillance yourself, model selection and routing are a standing part of our AI transformation engagements, and the production side sits inside our content engine work.