Hy Image 3.5 multi-turn editing with assembled_history vs Sume edits
How Tencent's Hy Image 3.5 Preview chains edits with assembled_history, and what the same loop looks like on Sume's stateless images route.

Hy Image 3.5 Preview edits across turns by having you append the previous response's assembled_history, typically three messages, to the next request. Hy Image 3.5 Preview is not listed in the Sume image catalog (read 2026-10-09). On Sume each image call is independent, so an edit loop feeds the last result back in as an input reference.
How does the history flow work at Tencent?
The messages in request N+1 are the messages from round N, plus the assembled_history from the round N response, plus your new user message. Keep the same session value throughout so requests land on one instance. Tencent adds that the server prepared the object, so you do not aggregate the SSE deltas.
| Item | Fact |
|---|---|
| assembled_history | typically assistant, tool, assistant messages |
| Final image | choices[0].delta.image.url |
| finish_reason | often null; check the URL, not finish_reason |
| URL lifetime | 12 hours, signed |
| References | up to 20 images, 20 MB each, oldest rounds truncated first |
What is the loop on Sume?
Send the edit, take the image URL from the response, and pass it as the reference of the next call with a short prompt. Reference URLs must be public HTTPS, and aspect_ratio: "auto" keeps the frame. Sume holds no conversation, so anything that must persist, such as a style note, goes in every prompt.
{
"model": "google/nano-banana-2.1",
"prompt": "Same room, now with the sofa in dark green. Keep everything else.",
"input_references": [
{
"type": "image_url",
"image_url": {
"url": "https://example.com/previous-result.png"
}
}
],
"aspect_ratio": "auto",
"resolution": "1K"
}What do I give up?
The model's own memory of the earlier turns and, in Hy's case, the reasoning text. What you gain is that every step is a plain request you can log, retry and bill on its own. Each completed image bills in full at the endpoint line ($0.10 per 1K image on Nano Banana 2.1) and failed ones are not billed. See the image models docs.
Keep a small record per edit round on your side: the prompt, the reference URL used, the output file and the billed amount. With that record, any step can be replayed or branched, which a hidden chat history makes harder. Save each output file as soon as it arrives, since signed URLs are not a place to keep work.
Sources
Related posts
More in Developers
- Idempotency key from the order id, not a fresh UUID per attempt
A random UUID generated inside the retry loop gives every attempt a new key and a new paid job. Derive the Sume Idempotency-Key from the order instead.
- Inspect transcript words without start or end: skip them in cuts
Inspect transcript words can omit start or end. Treat an untimed word as unknown, and never cut across a gap that contains one: 0 of its time is safe to remove.
- IVR phone menu prompts with TTS: 8 kHz mu-law WAV and cost per prompt
Make phone-menu prompts as 8 kHz mu-law or A-law WAV with Sume TTS. A 20-prompt menu bills 20 cents because each short job hits the 1-cent minimum.
- Sume job webhook retries: 370 s worst case, then poll or redeliver
Sume retries a job webhook 10 times, 30 s apart, with a 10 s timeout each: 270 s of gaps and up to 370 s in total. What to do when the window closes.
Written by Sume