Hy Image 3.5 Preview: 17.44 s median latency vs Sume's 30 s wait

The short answer

OpenRouter's page for Tencent's Hy Image 3.5 Preview shows a median end-to-end latency of 17.44 s for its one provider, Tencent Cloud (read 2026-10-09). That is under the 30 seconds that a Sume image request waits. But a median is the middle request, not the slowest one, so any client that calls an image API should be written for the slow case too.

Sume does not list Hy Image 3.5 Preview in its image catalog, so you cannot call it through Sume today. The numbers below are for planning: they show how a 17 s typical call sits against Sume's own wait window, and what to do when a call runs long.

What the two pages say

The table keeps the vendor figures and the Sume rules side by side. The OpenRouter figures are a one-week latency and a three-day availability window as shown on the listing; they will move.

Why a median is not a budget

If the median is 17.44 s and the wait is 30 s, the gap is 12.56 s. That is room for many requests, not for all of them. Sume's docs say the slow configurations (4K, high quality, large n) are the most likely to degrade to a 202. A 202 is not an error: the generation continues and you read it from the job endpoints.

So check the status code, not the body shape. A 200 carries the image response. A 202 carries a job envelope with a status URL and a result URL. The docs describe the polling flow in Jobs and results.

A client that handles both

This sketch sends one request to a model Sume does list and hands a 202 to your own poller. It does not parse the job result, because the result shape is documented on the jobs page.

import os
import requests

URL = "https://api.sume.com/v1/images"
HEADERS = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}

def generate(prompt: str) -> dict:
    r = requests.post(
        URL,
        headers=HEADERS,
        timeout=45,
        json={"model": "openai/gpt-image-2.5", "prompt": prompt, "quality": "medium"},
    )
    if r.status_code == 200:
        return {"done": True, "urls": [d["url"] for d in r.json()["data"]]}
    if r.status_code == 202:
        env = r.json()["data"]
        return {"done": False, "status_url": env["status_url"], "result_url": env["result_url"]}
    r.raise_for_status()
    raise RuntimeError(f"unexpected status {r.status_code}")

print(generate("a ceramic mug on a wooden desk, soft window light"))

Choosing a mode

Sume's image route takes a mode field: sync is the default, async returns the job envelope at once, and webhook with a webhook_url delivers the terminal event to your server. A median of 17.44 s is 58% of the 30 s wait (17.44 / 30 = 0.58), so a sync call is a fair default for a single interactive image. For a batch, or for 4K and high-quality renders, async or webhook avoids holding a connection open at all.

Whichever mode you pick, give your HTTP client a timeout a little above 30 s so that it never cuts a request that Sume would still have answered. The docs add that mode: "subscribe" is only an alias of sync and is not a progress stream.

If Hy Image 3.5 Preview matters to you, test it where it is sold and keep your Sume calls on a model Sume lists. Read the live list with GET /v1/images/models before you pin a model id. Use a client timeout above 30 s, since Sume itself may hold the connection that long.