Cowork scheduled task and paid Sume tools: use dry_run, max_spend_usd

Cowork asks for an approval mode when you schedule a task, and tasks run while your computer is asleep. Put dry_run and max_spend_usd on every paid Sume call.

5 min readSume
All posts

When you schedule a task in Claude Cowork, you choose an approval mode as part of setup, and the task then runs remotely even when your computer is asleep. The help page does not detail what each mode asks for, so I will not guess. What you can control regardless of the mode is what the Sume call itself will accept: dry_run=true previews a paid create without submitting it, and max_spend_usd caps it when sent.

Scheduling behavior is from Claude's Cowork scheduled tasks article, read on 2026-10-03; the paid-tool parameters are in Sume's MCP tools and gates.

What does the schedule page promise?

Tasks run on a schedule you set and, per the article, run remotely, so a closed laptop does not stop them. Because nobody is watching, whatever approval mode you pick is the only human check in the loop. Choose it knowing which tools the task will touch.

What do Sume's paid tools require?

Paid and write tools need an idempotency_key. dry_run and max_spend_usd are optional, and max_spend_usd is enforced only when you provide it. generation_admission_preview shows what admission would say before a burst. If the connection was authorized with mcp:read only, none of the paid tools are callable.

Paid-call parameters on hosted MCP (read 2026-10-03)
ParameterRequired?What it does
idempotency_keyYes, paid and writeMakes a retry safe
dry_runNoPreviews without submitting
max_spend_usdNoCaps spend, only when sent

What should the task prompt say?

  • First call with dry_run=true and report the estimate.
  • Proceed only if the estimate is under a number written in the prompt.
  • Send max_spend_usd set to that number and a fresh idempotency_key.
  • Do not retry a failed paid call with a new key; reuse the old one.

Where does this leave the approval mode?

The mode decides whether a person sees each step; the parameters decide what a step can cost. Use both. A strict mode with no cap still depends on someone reading carefully, and a cap with no approval still lets a task do work you did not intend, only cheaper.

If you only need a read, authorize the connection with mcp:read and skip the issue. That scope is required on every session, write is opt-in, and the consent screen has Write off by default. A task that only looks up job status or results does not need more, and a paid call from it would return insufficient_scope instead of spending.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume