jobs_wait returned operator_stopped: what it means and what to do

When Sume's remote MCP jobs_wait answers outcome: "operator_stopped", it means Sume operations stopped at least one of the job ids you waited on. Those jobs are terminal, produce no output, and their holds were refunded, so the correct next step is to read which ids stopped, not to wait again.

This is a different outcome from a failed generation. Nothing went wrong with your prompt, and nothing is waiting to finish. The sections below show how to recognize it, what the response names, and how to handle a wave where only some ids were stopped.

What does operator_stopped actually mean?

The Jobs and results page defines it in one sentence: Sume operations stopped at least one id. The stopped jobs carry an error_code that starts with ops_ and a public_reason of job_stopped_by_operations.

Three consequences follow from the docs. The stopped jobs are terminal, so there is no later state to wait for. They produce no output, so jobs_result has nothing to return for them. And their holds were refunded, so you are not billed for work that never produced an artifact.

Why does the wait return early?

The wait answers as soon as it sees a stopped id. It does not hold the full slice to see whether the other ids in the batch finish. That is why the response also carries operator_stopped.pending_job_ids: those are the ids from your request that are still running when the answer came back.

The docs add one more rule worth remembering. Re-issuing the wait on the stopped ids cannot change the answer, because a stopped job never becomes anything else. If you loop on jobs_wait until the outcome changes, you will spin on the same result.

How should an agent or script react?

Treat the response as three groups of ids: stopped, still pending, and everything else. Only the pending group needs more waiting.

A simple handling order that matches the documented fields:

• Read the stopped ids off the response and record them as terminal with reason job_stopped_by_operations. Do not call jobs_result expecting an artifact.
• Call jobs_wait again with only the ids in operator_stopped.pending_job_ids, using the same slice rules as any other wait.
• Do not resubmit the paid create just because a job was stopped unless you intend to run that shot again. A resubmit is a new job with a new hold.
• If you pass include_results: true, results come back for ids that completed, so completed siblings are not lost.

Is this the same as failed, canceled or a transport error?

No. The documented job statuses are queued, processing, completed, failed and canceled. operator_stopped is a wait outcome that reports an operations stop, and it names its own error_code and public_reason. It is also not a transport failure: a 524, 522, 523 or 525 on jobs_wait is documented as a transport failure, never a job outcome, and the fix there is to re-issue the wait.

The distinction matters for retries. A transport error means the job is probably still running, so you wait again. An operator stop means the job is over, so you do not.

What does Sume not tell you here?

The docs name the fields above and nothing more. They do not describe why operations stopped a particular job, and they do not promise a reason beyond job_stopped_by_operations. If you need to discuss a specific stop with Sume support, share the request id and job id, the same way you would for any other error, and leave out API keys and signed URLs.

For a broader view of waiting without resubmitting, see MCP jobs_wait for long video jobs, and for cancellation you start yourself, see how to cancel a job or run.