500-image job on a preview model: Hy Image 3.5 availability, plan B

If you batch 500 images on a preview model, plan for retries. OpenRouter's page for Tencent Hy Image 3.5 Preview, read 2026-10-08, shows 83.39% availability over the last 3 days, a single provider and a P50 end-to-end latency of 18.04 seconds. At 83.39%, about 17% of 500 requests, roughly 83, would return an error or empty response.

What the page says

OpenRouter defines availability as the share of time inference was served successfully, with errors and empty responses counting against it. It also notes that the model is hosted by one provider, so there is no second provider to fail over to. The model was released Oct 5, 2026 on OpenRouter and is priced at $1.60 per million tokens.

The retry arithmetic

500 x (1 - 0.8339) = 83.05, so budget for about 83 retries on the first pass, then about 14 on the second (83 x 0.1661). Two retry rounds finish nearly all of it, but only if your client records which items failed. Uptime is a past window, not a promise.

What Sume does instead

Sume does not list Hy Image 3.5 Preview in its image catalog, so there is no Sume row to call for it. For a batch on Sume, submit with mode: "webhook" or poll the job, and send the same Idempotency-Key when you retry a submit so a retry returns the original job and does not bill twice, per the Jobs and results docs. Keep a priced fallback such as google/nano-banana-2.1 for the items that fail.

Decide by test, not by headline

Run 20 of your real prompts on the preview model and on a listed Sume row. If the preview wins on quality, size the batch so that 17% retries still fit your deadline. If not, skip the retry load altogether.

A fallback design

Treat the preview model as the first choice and a listed row as the fallback. In code that means a function that tries the preferred provider, catches errors and empty responses, and then calls Sume. Record which path produced each image so that you can compare quality and cost after the batch.

On the Sume side, a fallback of google/nano-banana-2.1 at 1K costs $0.10, so if all 83 failed items fall back, the extra bill is 83 x $0.10 = $8.30 on top of whatever the preview provider charged for the 417 that worked. A cheaper fallback for text-only items is google/imagen-4-fast at $0.025, or 83 x $0.025 = $2.08.

Watch the window. A 3-day availability number says nothing about next week, and OpenRouter's own page says uptime and availability are different measures. Re-read the page before you size a run.

The 83.39% figure is for a 3-day window that ended when the page was read on 2026-10-08. The same page shows a 99.98% uptime figure, which it defines as at least one provider responding. With one provider those two numbers differ because of errors and empty responses, which count against availability only.

The page lists a P50 of 18.04 seconds end to end. For a batch of 500 at one request at a time, that is about 9,020 seconds, or 2.5 hours, so run requests in parallel and respect the provider's rate limits. This is arithmetic on a median, not a promise about tail latency.