Unattended agent on Sume MCP: API key or OAuth consent?

For an agent that runs on a schedule or in CI with nobody present, use API-key remote MCP. Sume's docs make OAuth the preferred path for interactive clients such as Cursor and Claude, and call API-key remote MCP the path for current automation. The OAuth flow needs a browser and a person to sign in and press Continue on the consent page. A cron job has neither.

What each mode gives a headless run

The key difference is what the session can see and who has to be present.

A key is full power, so cap each call

Because an API-key session sees the paid tools straight away, put the limits in the call, not in the hope that the agent behaves. Sume documents these gates:

• idempotency_key is required on every write and paid call, and is for dedup, not human approval.
• dry_run=true returns an admission and cost preview without submitting a job.
• max_spend_usd is enforced only when you provide it, so provide it.
• Before a burst, use generation_admission_preview; a single normal create does not need it.

Give an unattended run a bounded job

Design the run so that a mistake costs at most one capped call. Read first: account_me, then balance_get, then catalog_list. Submit with a stable key derived from the work item, such as a date plus a row id, so a retry after a crash reuses the same key and does not create a second job. If you reuse a key for a different payload, Sume answers 409 idempotency_conflict.

Then wait with jobs_wait slices of at most 55 seconds, repeating on wait_slice_expired. Keep a deadline in your own code, and write the job id down before you wait, so a restart can pick the job up again with jobs_status rather than paying twice.

Key hygiene

Keep the key in the CI secret store, never in the repo or the prompt. Create a new key for each automation so you can revoke one without touching the others, and remember that scopes are fixed when a key is created. The Authentication page says to give agents read-only commands first and to require explicit confirmation before write or paid commands; for a run with no human, that confirmation is your own preflight code. If the key ever shows up in logs, rotate it.

A concrete nightly shape

Here is one way to lay out a nightly job that makes three vertical clips. Each step is a documented call, in order: account_me, balance_get, generation_admission_preview, three generate_video calls each with dry_run=true first and then with max_spend_usd, one batch jobs_wait on the three ids with include_results: true, and a final usage_get.

If the balance is below your threshold, the run stops before any paid call. If the batch wait returns wait_slice_expired, the job repeats the wait on the same ids. The run never creates a job twice, because every create carries a key built from the date and the clip number.