August 16, 2026
Every provider takes reference images differently
Attaching a reference image and having it silently ignored is worse than an error. We found it happening across an entire provider.
"Use this photograph as a reference" is one sentence to you and a completely different API call to each provider. Get it wrong and nothing fails. The generation succeeds. It just quietly ignores your reference.
The silent failure
Someone attaches a product photo, asks for the product on a different background, and gets a perfectly plausible image of a different product. No error, no warning. The request had gone to a text-to-image endpoint that never accepts images at all, and the attachment was dropped on the way.
This is the worst kind of bug in generative tooling. The output is confident and wrong, so you conclude the model is bad at your product, when really your reference never arrived.
Three different fixes for one feature
| Family | What it actually needs |
|---|---|
| OpenAI image models | The edits endpoint, with images sent as a multipart array |
| Fal-hosted models | A different model id altogether, the /edit variant, taking image URLs |
| Everything else | Reference images on the standard call, with per-model count caps |
The generation endpoint and the edit endpoint are often different model identifiers, not just different parameters on the same call. Sending references to the plain identifier does nothing at all, which is exactly why this went unnoticed for as long as it did.
What we changed
- Routing that picks the reference-capable endpoint whenever a request carries reference images.
- Per-model caps, so a request gets trimmed to what the model accepts instead of being rejected or cut arbitrarily.
- A warning in the interface when the model you've chosen can't take references at all.
- Model selection on Auto that won't pick a reference-blind model for a request that has references attached.
What we took from it
Any capability that can be silently dropped eventually will be. If a feature can degrade invisibly, the interface owes you a visible signal, and the routing owes you a correct endpoint before that.