Spend guard layers for an unattended Sume video agent, in order

Five layers cap a Sume agent that runs unattended: key scope, per-run cap, max_spend_usd and dry_run, generation admission, and the wallet. What each one stops.

4 min readSume
All posts

An agent that runs overnight has no human to click Allow. The guardrails have to be in the request and the account. Sume's docs describe several, spread over different pages; this lists them in the order a request meets them.

Assembled from docs.sume.com pages, read 2026-10-05
LayerWhat it stopsWhere it is set
Key scopeA key that was never meant to start agents (403 insufficient_scope)API key creation
Per-run capOne run spending beyond its ceilinggeneration_spend_cap_usd, required on Agent Completions
max_spend_usd and dry_runOne MCP call spending more than you named, or running at allTool arguments
Generation admissionMore paid jobs than concurrency and queue allow (429 queue_full)Plan
BalanceAnything without funds (402 insufficient_credits)Wallet

Notes on each

Agent Completions require the cap because a backend caller gets no interactive spend prompt; the docs say the cap replaces it. Schedules default to $1.00 per run, and an override can only lower it (Create a schedule). On hosted MCP, max_spend_usd is enforced only when you provide it, and dry_run=true previews without submitting (tools and gates).

Admission has four separate controls, concurrency, queue capacity, submit rate limits and balance, that are easy to confuse (Generation admission).

What none of them cover

The run cap bounds generation, not the agent's own LLM turn, which bills a separate Agent wallet. And a cap says nothing about whether the output is good. Add a reviewer step or a webhook that flags failures, and keep logs free of keys and signed URLs, as Safe automation advises.

Start with the smallest cap that fits one run, watch the receipts for a week, then raise it by hand.

Sources

Related posts

More in Agents

All Agents posts

Written by Sume