Hy Image 3.5 Preview at 91.57% availability: retry math for 200 images

The short answer

At the 91.57% availability OpenRouter shows for Hy Image 3.5 Preview over three days, about 8.43% of first attempts fail. In a 200-image batch that is 200 x 0.0843 = 16.86, so plan for roughly 17 failed first tries and about 219 attempts to land 200 images (200 / 0.9157 = 218.4).

This is arithmetic on one listing's three-day window, not a service level from Tencent. Treat it as a planning number and re-read the page before a real run.

What OpenRouter counts

The listing defines two terms. Uptime is the share of the last three days that at least one provider was responding. Availability is the share of time inference was served successfully, and errors and empty responses count against it. The page shows 99.92% uptime and 91.57% availability for the same window (read 2026-10-09).

The gap between the two matters. A model can be reachable almost all the time and still return errors or empty responses on one request in twelve.

Retry math for a batch

With a fixed failure rate p = 1 - 0.9157 = 0.0843, the expected attempts per delivered image are 1 / 0.9157 = 1.092. For 200 images that is 218.4 attempts, so 18 or 19 extra calls. Failures are not independent in practice: an outage tends to hit a run of requests together, so a retry loop needs a delay and a cap rather than an instant replay.

• Cap retries per image (three is a common choice) so one bad prompt cannot loop.
• Back off between tries and spread a batch over time instead of firing 200 calls at once.
• Log each failure with its error code so you can tell a model outage from a bad input.

A simple batch plan

Run the batch in waves. Send 50 images, collect the failures, wait, and send only the failures again. With a failure rate near 8.43%, wave one leaves about 4 failures out of 50 (50 x 0.0843 = 4.2), and a second wave of 4 images leaves under one expected failure (4 x 0.0843 = 0.34). Three waves clear almost every image. The same plan works for any provider with a known error rate, and it keeps a bad hour from burning your whole queue.

Re-read the availability figure before the run. A three-day window can change quickly for a preview model, and a Preview label is a signal that the vendor may still change limits.

How Sume bills a failure

Sume does not list Hy Image 3.5 Preview, so none of this applies to it on Sume. For the models Sume does list, the Image API docs say a failed or cancelled generation is not charged, and a completed one is billed in full. Failed requests return 502 Bad Gateway. That means a retry loop on a Sume model costs you nothing for the failed tries, only for the image you keep.

If you need a batch to finish, add a second model as a fallback. Read the current list with GET /v1/images/models and pick one whose supported_parameters match the request you were already sending.