The capability did not disappear — it became automatic. Reference edits enable high-fidelity handling on their own, with better identity, detail, and text retention than the manual setting produced. But a request carrying the parameter fails outright rather than quietly ignoring it.

Strip it from every call before you switch the model string.

Sizes Stopped Being a Menu

The largest functional change in this release.

Earlier models offered three fixed sizes: square, portrait, landscape, at fixed resolutions. Anything else meant generating at a preset and post-processing.

This model takes WIDTHxHEIGHT and generates it directly. Each edge may be up to 3,840 pixels.

Both width and height must be divisible by 16. A request for 1920x1080 is rejected:

1080 is not a multiple of 16; 1088 is. That single adjustment is the difference between a working 16:9 request and an error.

A cinematic 16:9 frame, a desktop banner, a tall vertical crop — one call each, no upscaling stage, no cropping.

Additional constraints on aspect ratio and total pixel count are reported in secondary documentation rather than OpenAI's model page. Validate unusual dimensions against the current official reference before building a pipeline that assumes them.

Above 2K is experimental

OpenAI flags resolutions above 2K as experimental with mixed results. 4K is supported in the sense that the request succeeds; it is not supported in the sense that the output is reliably good.

For anything above 2K, test your specific use case rather than assuming. Generating at 2K or below and upscaling separately remains the more predictable route for large final assets.

Quality: Start Low

Three tiers — low, medium, high — and OpenAI's own guidance is to test low first.

That advice is worth following literally rather than treating as a cost disclaimer. Low quality preserves composition, framing, lighting direction, subject placement, and layout. What it costs you is fine detail. While you are still deciding whether the image is right, detail is the part you are not evaluating.

A working pattern:

Explore composition at low across several prompt variants. Pick the one that works. Render that one at medium or high.

The gap between tiers is significant enough that iterating at high wastes most of what you spend — and the composition you were choosing between was visible at low all along.

Note that cost scales with dimensions as well as quality on this model. A 3840×2160 image at high and a 1024×1024 image at high are not comparable requests. Both dials matter.

What Improved

Three areas, per OpenAI's release material.

Text rendered inside images. The long-standing weak point of image generation, and the one that rules models out of signage, packaging, labels, mockups, and diagrams. This generation renders legible text more reliably than its predecessor.

Photorealistic surface detail. Materials read as materials — fabric weave, brushed metal, skin texture, condensation on glass.

Adherence to long multi-clause prompts. A brief with eight specific constraints produces an image satisfying eight specific constraints, rather than the three the model found most salient. This is what makes detailed briefing worth the effort here.

Editing

The model handles reference-based editing and multi-image work alongside generation, through the edits endpoint.

Reference edits take an existing image plus an instruction in plain language. High-fidelity handling engages automatically — do not pass input_fidelity.

Mask support enables regional editing: supply a mask marking the area to change, and only that region is regenerated. This is what separates precise inpainting from "describe the whole image again and hope the rest survives."

Outpainting extends an image beyond its original frame, which is how you turn a square asset into a banner without cropping the subject.

The same size rule applies to edit output: both dimensions divisible by 16.

Specifications

Nothing is published about the model's construction — no parameter count, no architecture, no training method, no weights.

Capabilities

Using It on DEVUP AI

Endpoints: POST https://api.devupai.com/v1/images/generations and POST https://api.devupai.com/v1/images/edits

The response returns a signed URL in data[0].url, alongside a _devup object reporting the cost of the request and your remaining balance.

The URL is valid for five minutes. Fetch the image within that window.

Allow a generous timeout. Generation takes considerably longer than a typical API call, and larger dimensions take longer still. A default HTTP client timeout will abort work the server is still doing.

Generate at a custom size — cURL

1920x1088 rather than 1920x1080 — both edges divisible by 16.

Generate and persist — Python

The divisibility check runs before the request. Catching an invalid size locally costs nothing; discovering it from an error response costs a round trip and an unclear failure in a batch.

One image, many formats — Python

The workflow flexible sizing makes possible. Every dimension below is divisible by 16.

One brief, four native renders, no cropping and no upscaling. On earlier models this required generating at a preset and post-processing every variant, which introduced its own artefacts.

Note that each render is an independent generation — the four images will differ in detail, not only in framing. Where you need the same image at several sizes, generate once and resize, or use reference editing to hold the subject constant.

Editing with a mask — Python

The mask confines regeneration to the marked region. Everything outside it survives untouched, which is the difference between changing a sign and regenerating a storefront that happens to have a different sign.

No input_fidelity here — passing it returns an error.

Iterate cheap, finish expensive — Python

Both dials move together here. A draft at 1024 square and low is a fraction of the cost of the same prompt at 2560×1440 and high, and it answers the only question a draft needs to answer.

Node.js

Writing for a Model That Follows Long Briefs

Prompt adherence improved specifically on long, multi-clause instructions — which changes what a good prompt looks like.

Write a scene description, not a style stack. "Premium, minimal, 8k, professional" describes a mood board. "A matte black bottle on pale grey seamless, lit softly from above, faint reflection beneath" describes a photograph the model can construct.

State the camera. Overhead, eye level, three-quarter, close crop, wide. Omit it and the framing varies run to run for no reason you can control.

State the light. Direction, quality, time of day. This contributes more to perceived realism than any adjective, and this generation renders surfaces well enough that lighting choices show.

Use exclusions. "Nothing else in frame", "no text", "no people", "plain background". Negative constraints are instructions this model actually follows.

Quote any text you want rendered and say it should appear exactly. Keep it short, place it explicitly, and proofread every character — text rendering improved, but long strings still accumulate errors.

Change one clause at a time when iterating. Rewriting the whole brief between attempts tells you nothing about which change mattered.

Practical Notes

Validate dimensions before sending. Both edges divisible by 16, neither above 3,840.

Fetch the image within five minutes of receiving the response.

Set a long client timeout. Generation is slow relative to text endpoints, and scales with output size.

Log _devup on every request. With cost scaling on two axes, the per-request figure is the number worth tracking rather than assuming.

Strip input_fidelity from migrated code. It errors here.

Route transparency requirements elsewhere. No background control exists on this model.

Treat above-2K as unproven for your case until you have tested it on your own prompts.

Output is not reproducible. The same prompt run twice produces different images. Keep the file, not the prompt.

Rate-limit public paths in your own layer. Image generation is expensive per call and trivial to trigger repeatedly; a queue and a per-user cap cost nothing to add.

Moderate both directions. Filter prompts arriving from users, and review output before it reaches an audience.

Limitations

• No transparent background support. A capability present in earlier GPT Image models and absent here.
• input_fidelity is rejected, not ignored. Remove it when migrating.
• Both dimensions must be divisible by 16. Common video resolutions such as 1920×1080 are rejected outright.
• Above 2K is flagged experimental by OpenAI with mixed results. Test before relying on it.
• Not deterministic. Identical prompts produce different images.
• Text rendering improved but is not guaranteed. Short strings are reliable; long ones are not. Proofread.
• Constraints on aspect ratio and total pixel count are reported rather than confirmed in OpenAI's model documentation. Validate unusual dimensions first.
• Generation is slow relative to text endpoints, scaling with output size. Plan timeouts and user experience accordingly.
• Signed URLs are valid for five minutes.
• Nothing is published about the model internals — no parameter count, architecture, or weights.
• Moderation is your responsibility. Filter inputs on public paths and review output before publishing.