jobs_wait says status unknown, poll_count 0: is the job lost?

No, the job is not lost. When Sume's MCP server is saturated, jobs_wait can return HTTP 200 with timed_out: true, an outcome of wait_slice_expired, a status of unknown and a poll_count of zero. That means the server never got to read the job. The job was submitted, may be running, and still bills as normal.

How to read the answer

The difference is only in whether the server managed to take one snapshot. The answer keeps all the ids you asked about, so you can send the same request again without rebuilding the list. For a single-id wait, the value is null in the busy case.

What to do next

Issue jobs_wait again on the same ids. The jobs and results page is clear that a wait which ends without a terminal state is not a job failure and that you must not submit the paid create again. If you want a second opinion, one jobs_status read gives you a snapshot of the same ids.

Waits and reads are answered at once when the server is saturated, instead of queuing, which is why this answer arrives fast. Other tools behave differently: they return a retryable wait_busy error with HTTP status 429, and you retry only that call.

• Treat unknown as 'not observed', not as 'failed' or 'stuck'.
• Keep the same idempotency_key on any retried submit, so a retry returns the original job.
• Back off a second or two between retries; the server's own retry hint on a busy rejection is one second.

The tradeoff

Sume could have queued waits until a slot opened, but a queued wait is just another request held open at the edge, which is the failure the 55-second cap exists to avoid. Answering at once keeps the server responsive and puts the retry in your loop. The cost is that your loop must tell 'not observed' apart from 'observed and running', so check poll_count or the status rather than only timed_out.