Cursor /goal with paid Sume calls: what actually caps spend

Cursor's /goal keeps an agent working toward a long-lived objective until it is complete, and nothing in the goal text limits what a paid tool call costs. With Sume, the limits are separate settings: generation_spend_cap_usd on an Agent Completion run, max_calls and max_paid_calls on a script_run, an idempotency_key on every paid call, and dry_run=true before the first submit.

/goal described per the Cursor changelog; Sume limits from Agent Completions and MCP tools and gates, read 2026-10-01.

What does /goal do?

The changelog entry (2026-08-19) says to use /goal to give the agent a long-lived objective to work towards until it is fully complete, and suggests pairing it with a custom mode to follow a playbook, or /loop for recurring check-ins. A goal such as "make all the product videos" can therefore trigger many tool calls with no human prompt between them.

Which Sume limits bound a goal loop?

Why is the goal text not a budget?

The Agent Completions docs call the spend cap the substitute for the interactive approval prompt a backend caller does not have, and say to set it to the most you will spend on a single run. A goal loop has no such per-run notion unless you create one: bound each Sume run, not the objective. See agent loop budgets.

What should the goal prompt say?

Tell the agent to call a paid tool with dry_run=true first and to stop when the preview exceeds your number, to reuse one idempotency_key when retrying the same create, and to check jobs_status before submitting again. For a hard ceiling, do not rely on the prompt: put the work behind an Agent Completion with its cap.