Sume MCP read_busy 503: four concurrent reads per owner
read_busy is a retryable 503 from Sume's MCP host. Reads inside tools, including jobs_wait polls, are capped at 4 at once per owner, 512 across the host.

read_busy means Sume's MCP host is already running its limit of hosted reads, and the message is "MCP reads are busy; retry shortly." The error is retryable, carries HTTP status 503, and is not a failed job. The limit applies to GET reads that happen inside tools, including the polls that jobs_wait makes. Each owner may have 4 in flight at once, and the host holds 512 in total.
The budgets side by side
The per-owner figure is keyed by workspace and owner, so two terminals using the same key share it. Studio agent turns use a separate per-turn cap, which is not what an outside client sees.
| Budget | Total | Per owner | Busy error |
|---|---|---|---|
| Hosted reads inside tools | 512 | 4 | read_busy, 503 |
| jobs_wait holds | 1,024 | 8 | wait_busy, 429 |
| Tool calls | 1,024 | 4 | wait_busy, 429 after queuing |
| Create calls | 1,024 | 20 | wait_busy, 429 after queuing |
What to do on read_busy
Retry only the call that failed, after a short wait, and do not fan out more reads in response. Reads are safe to repeat. A write or paid call that was rejected before it ran can be retried with the same idempotency_key, so nothing is billed twice.
The more useful fix is to send fewer reads. One jobs_wait covers up to 20 job ids, so a loop that polls 20 jobs one by one uses up to 20 times the read budget of a single wait. Keep one jobs_wait for all pending ids and re-issue it in 45 to 55 second slices instead of polling each id.
- Use jobs_wait with several job_ids rather than one status call per job.
- Back off for a second or more before retrying a read_busy.
- Do not open a second jobs_wait for the same ids; it spends the wait budget too.
Telling the busy errors apart
read_busy is 503 and about reads. wait_busy is 429 and about waits and tool calls. Both are transient, and neither means a job failed or that your credential is wrong. A 401 or insufficient_scope is a different category and retrying will not help.
A retry helper
A small wrapper keeps this contained: catch read_busy, wait one to two seconds with a little jitter, and try the same read again up to three times before surfacing the error to the user. Do not wrap write or paid calls in the same loop unless they carry a stable idempotency_key, because a fresh key on every attempt turns a retry into a second job.
Sources
Related posts
More in Integrations
- Voice files from Gemini or ElevenLabs in a Sume timeline: 31 cents
Make the voice elsewhere, import the files into Sume media, join up to 20 parts for $0.01, render 3 minutes for $0.30. Total $0.31 plus your clips.
- VS Code MCP: Reset Trust after you grant Sume the Write scope
Write on Sume's consent page changes the server's abilities, not VS Code's trust decision. MCP: Reset Trust makes VS Code ask again; mcp_health shows scopes.
- VS Code Settings Sync and MCP servers: keep the Sume key out
VS Code can sync MCP config when the MCP Servers sync option is on. Keep the Sume API key out of the file with an input variable, or use OAuth instead.
- VS Code user MCP config: a read-only and a Write Sume profile
VS Code's MCP: Open User Configuration edits per-user servers. Keep OAuth read-only Sume in your everyday setup and an API key entry only where paid jobs run.
Written by Sume