Claude Opus 5.5 and paid MCP tools: preview and cap spend with dry_run

When Claude Opus 5.5 calls a paid Sume MCP tool, three arguments keep the spend predictable: dry_run=true previews admission and cost without submitting, max_spend_usd caps the call when you pass it, and idempotency_key makes a retry safe. None of them is on by default except the key, which paid tools require.

Anthropic released Opus 5.5 on 2026-09-22 (model id claude-opus-5-5, $4 input and $20 output per million tokens), and Claude Code v2.1.280 made it the default Opus. Both facts are from Anthropic's pages, read 2026-09-29. Anthropic's Opus page does not mention MCP, so everything about tools below is Sume's documented behavior.

What does each spend argument do?

The arguments live on the tool call, not in the model, so they behave the same under Opus 5.5 or any other client.

What does a preview call look like?

Ask the model to send the same arguments twice: first with dry_run true, then, after you read the preview, with it omitted. The tool id is generate_video; leaving out payload.model routes to sume/auto.

{
  "idempotency_key": "promo-clip-2026-09-29-001",
  "dry_run": true,
  "max_spend_usd": 2,
  "payload": {
    "prompt": "A paper boat drifts down a rain gutter, macro shot"
  }
}

Is there a ceiling that does not depend on the model?

Wallet balance and queue admission still apply to every submit. generation_admission_preview is its own tool for the admission preview, useful before a burst of clips. When max_spend_usd is provided, it is enforced against the admission estimate.

An OAuth session needs Write turned on at consent to submit paid tools at all; an API-key session gets the full tool set. In both cases the paid submit still needs the idempotency key.

How should I brief the model?

Put the rule in the system prompt or project instructions, not in a hope: preview every paid call, pass max_spend_usd, reuse the same idempotency_key when retrying a failed transport, and when jobs_wait reports wait_slice_expired, wait again on the same job ids instead of creating a new job.

jobs_status and jobs_wait are read tools, so checking progress does not create a new paid job.