How many video scenes fit in one Sume script_run? Ten

Ten. The hosted script_run tool takes a max_paid_calls limit with a default of 16 and a ceiling of 32. If each scene needs a voiceover, a still image and a clip, that is three paid calls, so 32 / 3 rounds down to 10 scenes (30 paid calls), leaving two calls unused.

The limits come from the script_run source in the repo. Sume's tools-and-gates docs describe the tool; the numbers below are the ones the code enforces today.

The limits that matter

script_run runs a short JavaScript program on the Sume side. The program calls other tools with await sume.call(name, arguments), in a loop, in parallel or with conditions, and returns one value. Each paid create still needs its own idempotency_key, and the gates and errors are the same as for a direct call.

The scene arithmetic

With the default of 16 paid calls, 16 / 3 is 5.33, so five scenes fit (15 calls). With the maximum of 32, ten scenes fit (30 calls). An eleventh scene would need 33. max_calls counts every call, including free reads, and its maximum of 64 leaves room for 30 paid calls plus up to 34 reads.

If a scene needs only a voiceover and a clip, it is two paid calls, and 32 / 2 gives 16 scenes. Count your own scene recipe before you set the limit.

What the script cannot do

Discovery tools, script_run itself and subagent tools are forbidden inside a script. The whole run has a wall clock, and the hosted HTTP adapter cuts at 60 seconds, which is why timeout_seconds tops out at 55.

That is long enough to submit many jobs, since creates return job ids rather than waiting for media. The response carries the returned value, a calls[] journal and the child jobs[]. Hand those ids to jobs_wait in normal tool calls afterward.

Set the brake lower than the maximum

Set max_paid_calls to exactly what the plan needs. A bug that loops will then stop at your number, not at 32. Add max_spend_usd to each create so the spend has a ceiling too. Sume enforces that value only when it is sent.

For a longer film, run the script again for the next ten scenes. Each run has its own call budget, so the total is a product of your design, not a hidden limit.

A scene recipe you can count

Write the recipe as a list and count the paid entries. A common one is a tts_create for the line, a generate_image for the keyframe and a generate_video for the motion. That is three. A music bed is one extra paid call for the whole film, not for each scene, so subtract it from the budget first: 32 minus 1 leaves 31, which still gives ten scenes.

Reads such as catalog_list do not count as paid, but they count toward max_calls. Keep them out of the loop by calling them once before the script starts.

If one scene call fails, decide in advance whether the script stops or skips. Stopping saves money. Skipping gets you nine scenes and a clear gap. Either way the calls[] journal in the response shows what ran, so you can rerun only the missing scene with the same idempotency_key values for the ones that worked.

Preview the cost first

Use dry_run on one scene to read the voice, image and clip cost, then multiply by the scene count. Rates are on the API pricing page. Do the multiplication in your own notes, because the models you choose change the answer.