Sume MCP wait_busy 429: a retryable isError, paid creates queue 20 s
A busy Sume MCP server returns an isError result with http_status 429, retryable. The paid-create limits behind it and how to back off without double billing.
When Sume's hosted MCP server is busy, a tool call comes back as a normal result with isError set and an http_status of 429, marked retryable, under the reason wait_busy. It is not a protocol failure, and it does not mean the work was lost. The limits come from Sume's operations note on API and MCP work bounds on origin/main, read on 2026-10-04. Back off and retry with the same idempotency_key.
What are the bounds?
| Bound | Value |
|---|---|
| Paid creates in flight per process | 64 |
| Paid creates per principal | 20 |
| Queue wait for a paid create | up to 20 seconds |
jobs_wait ids per call | 20 |
jobs_wait hold per slice | 55 seconds |
script_run calls in flight | 4, with 8 call starts per second |
How should a client back off?
Treat a 429 inside an isError result like an HTTP 429. Wait, then send the same call again. Because a paid or write call requires an idempotency_key, described on the MCP tools and gates page as a stable key for transport and de-duplication, a retry after a busy answer cannot register a second job if the first one was accepted. Use a key built from the work, such as a shot id, so the retry sends the same one.
Queueing is the first line of defense. A paid create waits up to 20 seconds for a slot so a busy answer means the queue was already full when your call arrived. Add jitter on top of your own wait, and cap the retries; a burst of 50 creates from one principal will hit the 20 per principal bound quickly.
Should I switch to script_run?
It helps with shape, not with the bounds. A script limits itself to 4 calls in flight and 8 call starts per second, so a loop of 40 creates cannot flood the server, and each create needs its own distinct idempotency_key. A busy answer inside a script arrives as a SumeToolError that you can catch and retry. Uncaught, it fails the run, but calls[] and jobs[] still report what registered.
Do not wait inside the script. Submit creates and return ids, then call jobs_wait outside it, up to 20 ids per call. See Jobs and results.
What should I avoid?
Do not retry with a fresh key. That turns a safe retry into a second paid job. Do not poll jobs_status in a tight loop either; jobs_wait does the holding for you. And preview a large burst with dry_run=true or generation_admission_preview, as the docs recommend before expensive bursts. A normal single create does not need that step.
If the same call keeps coming back busy, read the MCP overview and cut the number of creates in flight from your side.
Sources
Related posts
More in Developers
- Sume MCP token lasts 3600 s with no refresh grant: plan for it
Sume's hosted MCP OAuth issues one-hour access tokens and only the authorization code grant. What a long agent run should do at minute 61.
- Sume MCP rate limit: one write per run created, none per status poll
Over Sume's hosted MCP, a tool call spends one write for the run it creates, and a jobs_status poll spends none. The numbers per plan and a Python budget check.
- Sume SDK: try/catch misses a 402, generated calls return { error }
Generated @sume-com/sdk operations return { data, error, response } instead of throwing, so a 402 or 429 slips past try/catch. Check error on every call.
- Sume SDK error.retryable: server flag first, status only as fallback
SumeApiError.retryable uses the error envelope's retryable flag when present and falls back to 408, 429 or 5xx otherwise. A 409 is never retried by status.
Written by Sume