Backgrounded MCP tool lost progress: resume with Sume jobs_wait

Claude Code's release notes list a fix for "MCP progress notifications being discarded once a long-running tool call moved to the background" (v2.1.283). Do not build a Sume workflow on progress messages. A Sume jobs_wait call returns in slices of at most 55 seconds, and you call it again with the same job ids until the job is terminal.

Why progress is the wrong signal

Progress notifications are a client feature, and the release note shows they can be lost when a tool is backgrounded. A paid Sume generation keeps running and keeps billing whether or not your client saw any progress. The durable signal is the job status.

How slices work

On remote MCP, timeout_seconds defaults to 50 and is capped at 55. Larger values up to 600 are accepted and clamped, and the response says so in wait_slice_clamped. A wait returns as soon as the job is terminal. When a slice ends first you get wait_slice_expired, and you re-issue jobs_wait with the same ids.

What not to do

Never resubmit the paid create because a wait ended or a tool was backgrounded. Do not report the job blocked on a 524. Re-read the status. If your own client process restarts, the job id you stored from the submit response is all you need to resume.

A resumable pattern

Store the job id at submit. Loop on jobs_wait with the same ids until the status is completed, failed or canceled. Then call jobs_result, or use include_results: true on the wait so a finished wave needs no separate read. With wait_for: "any" the other jobs keep running and keep billing, so decide up front whether you will cancel them. Cancellation works only before generation starts.