Multi-turn image edits over Agent Completions: pass the last output

POST /v1/agent/completions has no memory between calls. Every completion runs in a new thread, and a messages[] array with an assistant turn is rejected with a 400. To do a multi-turn edit, you chain it yourself: take the URL from output.images of turn one and attach it as the input of turn two.

Why this matters this week

Ideogram's launch post for 4.5 says the model "eliminates artifact buildup, making multi-turn editing possible" (Ideogram on X, read 2026-10-05). On Sume that kind of chain is a client pattern: the API stores no hidden edit state, so the pixels you send are the pixels that get edited.

The pattern

Each turn is one run with its own generation_spend_cap_usd:

• Turn 1: attach the original, ask for one change, poll to completed.
• Read the first URL in output.images and save it with the prompt.
• Turn 2: attach that URL as input_image, ask for the next single change.
• Repeat. Never attach the original again unless you want to restart from it.

Why one change per turn

The agent has no record of earlier instructions, so the prompt must say what to keep each time: "Keep the label, the shadow and the framing unchanged." Repeating this preserve list is the same guard that works for single-model edit chains. Check each result against the previous one before you go on, because an error in turn two is carried into turn three.

Cost control

Set the cap per turn, not once for the chain. A chain of five turns with a cap of $1 each can spend up to $5, and a failed run is a clean stop where you decide whether to retry. If the steps are fixed and known, the Image API is cheaper to reason about, because the price of each image is shown by quality and not decided by an agent.

Limits

Media URLs are durable, but a long chain loses nothing only if you keep your own list of them. Store them as you go. And do not expect turn six to match turn one in fine detail: each pass is a fresh render, and no API setting can promise otherwise.