Backgrounded MCP tool lost progress: resume with Sume jobs_wait
A Claude Code fix covers MCP progress dropped when a tool moves to the background. Do not rely on progress for Sume jobs: re-issue jobs_wait in slices.
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.
| Situation | What to do |
|---|---|
wait_slice_expired | Call jobs_wait again with the same ids |
A 524, 522, 523 or 525 on jobs_wait | Transport failure, not a job outcome; re-issue the wait or read jobs_status once |
| Many jobs in parallel | Pass job_ids (1 to 20) with wait_for: "all" or "any" |
| Want results in the same call | Pass include_results: true |
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.
Sources
Related posts
More in Developers
- Basin Pipelines: log Sume webhook deliveries and dedupe by job_id
Cloudflare Basin Pipelines streams ingest up to 1 GB/s. Log each signed Sume webhook delivery as one record and dedupe on job_id; Python sketch included.
- Blind-test Sonic 3.6 against 3.5 on your own script
A vendor's blind-test percentage is not yours. Render the same lines with two catalog versions through the TTS Router, shuffle them, and let listeners vote.
- Browser voice app that starts Sume jobs: keep the key on your server
Voice apps run in the browser over WebRTC, but Sume keys belong on a server. A route handler that holds the key, allowlists models, reuses idempotency keys.
- Sume bulk queue 404 format_run_queue_not_found: three causes
A Sume bulk queue poll returned 404 format_run_queue_not_found. The id is wrong or the queue is another owner's. How to tell which, and what to do next.
Written by Sume