script_run budget stop: split the batch and wait outside the script
A Sume script_run budget stop (timeout, call or paid budget) means the script asked for more than allowed. Split it, or return job ids and wait outside.

When a Sume script_run ends with script_timeout, script_call_budget_exceeded or script_paid_budget_exceeded, the script asked for more than the run allows. The remedy is to split the batch, raise the matching limit within its ceiling, or return job ids and wait outside the script.
The limits behind the codes
The tool description lists the budgets. max_calls defaults to 32 with a ceiling of 64. max_paid_calls defaults to 16 with a ceiling of 32. The runner allows four calls in flight and eight call starts per second, and guest memory is 64 MB. timeout_seconds is bounded as well. Whichever stop fires, the result still reports tools[] (calls per tool and model), calls[] and jobs[] in full, so you can see what ran.
| Budget | Default | Ceiling |
|---|---|---|
| max_calls | 32 | 64 |
| max_paid_calls | 16 | 32 |
| calls in flight | 4 | fixed |
| call starts per second | 8 | fixed |
A wave plan
Suppose you need 40 paid image creates. The default max_paid_calls is 16, so one script will stop on script_paid_budget_exceeded partway. Plan three scripts of at most 16, or raise max_paid_calls to 32 and run two. Return the job ids from each, then wait on them in batches of up to 20 ids with jobs_wait. The budget limits post has the exact knobs.
Chunking helper
This splits any list into runs that fit a paid-call budget.
def chunks(items: list, size: int):
if size < 1:
raise ValueError('size must be >= 1')
for i in range(0, len(items), size):
yield items[i:i + size]
prompts = [f'scene {n}' for n in range(40)]
plan = list(chunks(prompts, 16))
print([len(c) for c in plan])Limits
Splitting does not make the jobs cheaper, and each chunk is a separate script run with its own budget. Your overall spend control is still max_spend_usd on the paid creates and a balance check before the wave.
Why waits do not belong in the script
A script has a time limit, and a wait inside it spends that limit on a job that is not yours to speed up. If the script returns the job ids as soon as the creates are accepted, the turn can hold waits in 45 to 55 second slices, report progress, and survive a slow render without tripping script_timeout.
Checklist before you ship
- Return job ids from the script and wait on them in the turn.
- Count paid creates in a wave against max_paid_calls before you start.
- Raise a limit only up to its ceiling, and only for a reason.
- Give each paid create inside a script its own stable idempotency_key.
Sources
Related posts
More in Agents
- script_run on Sume MCP: what the sandbox cannot call, and its budgets
Sume's script_run tool runs JavaScript that calls other tools with await sume.call. It has 5 to 55 second timeouts, call budgets, and no discovery tools.
- Seedance video agent in ChatGPT and Claude: Sume MCP compared
InfoseekAI put a Seedance video agent into ChatGPT and Claude over MCP on Oct 1, 2026. What a hosted MCP server like Sume's gives you instead, and when.
- Sume skipped run with previous_run_active: what it means, what to do
A scheduled Sume run is skipped with skip_reason previous_run_active when the last one is still going. It is not billed work. How to detect it and avoid it.
- Sonnet 5.5 vs GPT-6.1 Sol for video scripts: both $2 in, $10 out
Claude Sonnet 5.5 and GPT-6.1 Sol list the same $2 input and $10 output per million tokens (read 2026-10-05), so pick on fit, not price.
Written by Sume