context_images[] is how you hand POST /v1/images a set of loose reference images — up to 10 of them — and direct the composition entirely from your prompt. Unlike subjects[], the images carry no structure: there is no identity grouping, no per-subject framing, and no identity-consistency guarantee. The composition model reads your prompt, looks at the images in the order you sent them, and interprets what to take from each one. This guide covers what the field does, when to reach for it instead of subjects[] or the legacy fields, and what’s different about a generation that uses it.
What context_images[] is
A flat, ordered array of image inputs. Each entry is either an opaque file_<ulid> from POST /v1/files or an https:// URL to a public host (max 2048 chars) — the same entry shape reference_image_urls and reference subjects already accept:
context_images entirely, or send [], and the request is a plain generation — both are treated as “no context images.”
When to use it
The rule of thumb: if the output must be someone — same face across renders — use
subjects[] or a saved character. If the images are raw material for the prompt to draw on, use context_images[].
Quickstart
GET /v1/images/{id} (or register a webhook endpoint) until status reaches a terminal value, same as any other generation.
Rules
context_images[] is one of three mutually exclusive input styles — pick exactly one per request:
The 10-image budget
The cap is a flat 10 entries — every entry contributes exactly one input image, so unlikesubjects[] there is no per-entry arithmetic to do. Go over it and the request returns 400 value_out_of_range; the endpoint does not trim on your behalf. Fix the request client-side (drop an entry) and resubmit.
When an image URL can’t be fetched
Entries are validated for shape at request time — bothPOST /v1/images/estimate and POST /v1/images reject an http:// entry or a private-host URL up front. The actual fetch of an https:// entry happens only at create: a URL that is well-formed but unreachable, returns a non-success status, redirects, or doesn’t resolve to a valid image comes back as 400 invalid_format from POST /v1/images. The estimate never fetches, so it won’t catch this — a request that estimates cleanly can still 400 at create if one of its URLs is down.
To stay clear of it, make sure every https:// entry is publicly reachable and points directly at the image bytes — not at an HTML page that displays the image. Or sidestep fetching entirely: upload the image via POST /v1/files and pass the file_<ulid> instead. File entries are fetched and validated at upload time, so they can’t fail this way at create.
The response
EveryGET/POST response for a generation — and every webhook delivery — carries a context_images field:
- The echo is a count only — the number of entries you sent. The image URLs themselves are never echoed back, on any response shape.
subjectsis alwaysnullon a context-image generation — the two projections never appear together.context_imagesisnullon every generation that didn’t use it — plain prompt-only, style, subject, and video generations. It’s a new, always-present, nullable key: existing integrations that don’t read it are unaffected.
What’s different about a context-image generation
A generation that usescontext_images[] always runs on the multi-image composition pipeline. A few things follow:
- Exactly one output image.
countis accepted but ignored — you always get one image back, priced at the standard single-image rate with no per-image surcharge for the references you attach. - Tuning knobs are inert.
steps,guidance_scale,cfg_rescale,denoise_strength,negative_prompt, andseedare accepted without error, but the composition pipeline uses optimized settings and doesn’t apply them. On the response,cfg_rescaleanddenoise_strengthare omitted, andseedandnegative_promptcome backnull, regardless of what you sent. output_format: "png"for transparency. The default isjpeg. Setoutput_format: "png"if you want a transparent background where the composition supports it.
Estimates
POST /v1/images/estimate mirrors all of the above: a context_images[] estimate always quotes exactly one image (count is ignored, matching create) and fires the same 400 combination errors a real POST /v1/images would. The estimate never fetches your inline https:// entries — their shape is validated, but a problem specific to a URL (unreachable host, non-image content) only surfaces at create, as 400 invalid_format — see When an image URL can’t be fetched. file_<ulid> entries are still ownership-checked.
Idempotency
The order ofcontext_images[] is part of the request body, so reusing an Idempotency-Key with the same entries in a different order is a different request — it returns 409 idempotency_key_in_use, not a replay. And as always, only successful responses are cached for replay: a request that 400s on one of the combination rules above is never cached, so you can fix the body and retry under the same key. See Idempotency.
Where to next?
- Subjects — identity-guaranteed composition, when the output must be a consistent someone
- Create an image — full request/response shape
POST /v1/files— mint afile_<ulid>to use as an entry (see the API reference)- Error reference — the combination errors in detail
- Cost transparency — how the credit receipt works

