jobs_wait outcomes: wait_slice_expired, operator_stopped, omitted

What each jobs_wait answer means on Sume's hosted MCP and what your agent should do next: call again, stop waiting on stopped ids, or read omitted results.

5 min readSume
All posts

A jobs_wait answer on the Sume hosted MCP tells you one of three things. outcome: "wait_slice_expired" means the slice ended and the jobs are still running, so call it again with the same job_ids. outcome: "operator_stopped" means Sume operations stopped at least one id; those jobs are terminal with no output, their holds are refunded, and operator_stopped.pending_job_ids lists the ids still running. results_omitted.job_ids names completed jobs whose results did not fit in the answer; read them with one batch jobs_result. All three are described in Jobs and results, read 2026-10-06.

Why a slice ends before the job does

On remote MCP the default timeout_seconds is 50 and the cap is 55. The REST API accepts larger values and clamps them. A wait that returns at the slice boundary has not failed; the transcription is still running and still billing normally. Starting a new paid job instead is the mistake the docs warn about.

jobs_wait outcomes and the next call, from Jobs and results (docs.sume.com), read 2026-10-06.
AnswerMeaningNext call
wait_slice_expiredTime slice ended, jobs still runningjobs_wait with the same ids
operator_stoppedAt least one id stopped by operations; holds refundedStop waiting on the stopped ids; wait on pending_job_ids
results_omitted.job_idsResults too large for one answerOne batch jobs_result for those ids
Unknown or foreign idThe whole call failsFix the id list

A handler for the answer

If your agent wraps the tool in code, branch on the answer instead of letting a model improvise. The sample below ran against three hand-written answers.

def next_action(answer):
    outcome = answer.get("outcome")
    omitted = (answer.get("results_omitted") or {}).get("job_ids", [])
    if outcome == "wait_slice_expired":
        return "wait again with the same job_ids"
    if outcome == "operator_stopped":
        stopped = answer.get("operator_stopped") or {}
        return f"stopped ids are final; keep waiting on {stopped.get('pending_job_ids', [])}"
    if omitted:
        return f"read {omitted} with one batch jobs_result"
    return "done"


print(next_action({"outcome": "wait_slice_expired"}))
print(next_action({"outcome": "operator_stopped", "operator_stopped": {"pending_job_ids": ["j2"]}}))
print(next_action({"results_omitted": {"job_ids": ["j3"]}}))

Do not ask again about a stopped id

The docs state that waiting again on stopped ids cannot change the answer. Remove them from the list, record them as stopped, and carry on with the rest. Check the ledger with a usage lookup if you need to confirm that nothing was debited.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume