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.

4 min readSume
All posts

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.

Hy Image 3.5 Preview multi-turn facts (Tencent Cloud docs, read 2026-10-09)
ItemFact
assembled_historytypically assistant, tool, assistant messages
Final imagechoices[0].delta.image.url
finish_reasonoften null; check the URL, not finish_reason
URL lifetime12 hours, signed
Referencesup 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

All Developers posts

Written by Sume