Before a 20-clip MCP burst: dry_run, admission preview, max_spend_usd

The Sume MCP docs recommend generation_admission_preview or dry_run=true before expensive bursts, and say a normal single create does not need these admission steps. A burst of 20 paid clips is the case where they pay for themselves. dry_run is an admission and cost preview only and does not submit the job.

Two other gates complete the picture. idempotency_key is required on every write and paid tool and is transport dedup, not human approval. max_spend_usd is optional and Sume enforces it only when you provide it.

A burst in four calls

First, call generation_admission_preview or send one paid call with dry_run and read the estimate, balance and queue behavior. Second, submit each create with its own idempotency_key, such as burst-0612-clip-01, and a max_spend_usd you accept. Third, collect the job ids and call jobs_wait once with up to 20 job_ids. Fourth, read them back with one jobs_result that takes job_ids.

If you need three or more independent calls of one shape, script_run runs a short program on the Sume side. It has timeout_seconds (5-55), max_calls and max_paid_calls, so you can bound the loop, and paid creates inside it still need their own idempotency_key.

Wait behavior to expect

jobs_wait holds at most 55 seconds per call (default 50). When it returns wait_slice_expired, call again with the same ids; a 524 or 522 is a transport failure, not a job outcome. wait_for: "any" returns early but the other jobs keep running and billing. Unknown or foreign-workspace ids fail the whole call.

• Use include_results: true to read finished answers in the wait; results_omitted.job_ids names those that did not fit.
• If outcome is operator_stopped, those jobs are terminal, produce no output, and Sume refunded their holds.
• Remember workspace limits: a Pro workspace holds 24 accepted jobs, so 20 fits and 25 does not.
• Never re-run the paid create because a wait expired.

Reading the preview

The preview is only useful if you act on it. Compare the estimate with the balance returned by balance_get, and compare the number of jobs with the queue capacity for the plan. If the estimate for 20 clips is above what you accept, lower the count or the resolution before you submit anything.

Keep the sequence repeatable. The same instructions every time (preview, submit with keys, one wait, one batch read) make a burst easy to audit afterwards, and they keep an agent from improvising a second paid create when a wait expires.

Treat this as a habit, not a one-time fix. Write the rule down next to the code that calls the API, add a test that exercises it, and review it whenever the docs change. Check the linked documentation pages in the sources list for the current wording before you rely on any number here, because limits and field names can be revised, and a short test run costs far less than debugging a production incident.

When something does not match what you read here, capture the x-sume-request-id response header and the job or run id, and send those to support. Do not paste API keys, signing secrets or full request bodies into a ticket or a chat; the ids are enough for the team to find the request.