Dropped connection mid-render: what happens to the Sume job

If your connection drops while a Sume job renders, the job keeps running and keeps billing. Reconnect and call jobs_wait again with the same job ids, or read the status once. Do not submit the paid create a second time.

What the MCP Tasks extension adds

The AAIF post on the 2026-07-28 MCP changes describes a Tasks extension with taskId handles, polling through tasks/get, mid-flight input through tasks/update, and resilience to connection drops. The idea is the same one Sume jobs already follow: the work has an id that outlives the connection.

The Sume rules

Every Sume submit returns a durable job id in its first response. The relevant behavior is documented in the jobs page.

Why waits are sliced

On remote MCP, timeout_seconds defaults to 50 and is capped at 55; larger values are clamped and the response says so in wait_slice_clamped. A wait is one HTTP request held open with nothing transferring, and edges close such requests eventually. For a ten-minute render, repeat the wait rather than asking for a longer one.

jobs_wait accepts one job_id or up to 20 job_ids with wait_for: "all" or "any". With include_results: true each completed id returns its result in results[], so a wave needs no separate read.

Cancel is not the same as disconnect

Cancellation is an explicit call, POST /v1/jobs/{id}/cancel, and it succeeds only before generation work starts. After that the API returns 409 job_generation_already_started and the job runs to completion. Only the member whose key or Agent turn created the job can cancel it.

So the safe recovery loop is: keep the id, wait again, read the result when completed. Details are in Jobs and results.