Scope is Meta only. Identical single-reference edit requests succeed at the same time on openai/gpt-image-2, bfl/flux-2-pro and bytedance/seedream-4.0.

THE SUGGESTED WORKAROUNDS DO NOT RESOLVE IT

Your AI support suggested two remedies. Neither works:

1. "Use JSON with inline base64 data: images." POST /v1/images/edits with Content-Type: application/json and images:[{image_url:"data:image/png;base64,..."}] returns the SAME multipart error. The JSON is definitely parsed — malformed shapes return proper schema errors such as "Each entry in images must provide exactly one of image_url or file_id". So the endpoint that raises this error rejects its own suggested fix.

2. "To pass multiple reference images, use the AI SDK where prompt.images natively accepts an array." That is the failing path. We tested your exact example, with the model as a bare string and via gateway.imageModel(), with one image and with two. All four return the same multipart error. The AI SDK's image-edit path appears to be the multipart path being blocked.

ISSUE 2 — /v1/images/generations returns 200 but does not apply the reference The only unblocked path is POST /v1/images/generations with a single image: "data:image/...;base64,..." field. It returns 200, but it does not behave as an edit: it generates a new subject rather than preserving the one supplied.

Test: a photograph of a specific person, sent alone (no second reference, no scene description), with the instruction "Reproduce this exact photograph... same face, same skin tone, same beard, same haircut, same piercings, same t-shirt. Do not change his appearance in any way."

Result: a different person — different skin tone, different hair, different beard, and a different t-shirt graphic. Only broad attributes were retained. This matters more than Issue 1. Before the block, edits through the standard path preserved the subject correctly. The remaining path silently returns plausible images built from different inputs, which is harder to detect than an error.

Two related observations on that endpoint:

• Unknown parameters are accepted silently with 200. We tested strength, image_strength, input_fidelity, fidelity, mode:'edit' and the invented key {"edit":true} — all returned 200. There is no way to tell which parameters, if any, take effect.
• image: [a, b] returns 200 but only the first reference is used, per your own explanation of the REST schema.

IMPACT We are evaluating models for a production image-compositing feature. Muse Image was our leading candidate on cost. With edits blocked and the only alternative path silently ignoring reference images, we cannot evaluate or ship it through AI Gateway.

WHAT WE ARE ASKING

1. Is the multipart block on Meta image edits intentional or a regression? If intentional, what is the supported route for identity-preserving edits on meta/muse-image-1.0 through AI Gateway?

2. Why does the error cite Zero Data Retention on an account where ZDR is off and unavailable on the plan? (Though ultimately we would want ZDR on for the live project).

3. Is /v1/images/generations expected to apply the image field as an edit? If not, should supplying it on a model that cannot use it that way be an error rather than a silent 200?