Claude Desktop catch-up run after wake: idempotency key for Sume

When a Claude Code Desktop scheduled task wakes after a sleep, it does not replay every missed run. The docs say Desktop starts exactly one catch-up run for the most recently missed time and discards anything older (Claude Code docs, read 2026-10-04). A 9am task can therefore run at 11pm.

If that task spends money on Sume, give each paid call a key built from the calendar day, not from the run time. Then a catch-up and a normal run for the same day carry the same idempotency_key.

What the catch-up rule means for a paid call

Desktop checks for missed runs in the last seven days when the app starts or the computer wakes. A daily task that missed six days runs once on wake. Desktop shows a notification when the catch-up starts.

The docs recommend guardrails in the prompt itself, for example skipping the work after a cut-off hour. That advice matters more for a task that generates media, because a late run still spends.

Three Sume gates to put in the prompt

On the hosted MCP at https://mcp.sume.com/mcp, idempotency_key is required on write and paid tools. It is a stable key for transport and dedup, not human approval. dry_run=true previews admission and cost without submitting, and max_spend_usd is enforced only when you send it (MCP tools and gates).

A prompt that survives a late wake-up

Put the day and the cut-off in the instructions. The key below names the day the run is for, so a repeat for the same day reuses it.

Each weekday, make one teaser clip with Sume.
1. Work out today's date as YYYY-MM-DD in local time.
2. If local time is after 17:00, do not generate anything.
   Write one line saying the run was missed, then stop.
3. Call generation_admission_preview, then the paid tool with
   dry_run=true and max_spend_usd=3.
4. If the estimate fits, repeat the call without dry_run, using
   idempotency_key "teaser-<that date>".
5. Wait with jobs_wait and report the media.sume.com URL.

What a repeat does on the REST side

On the REST run endpoints the same idea applies. Replaying an Idempotency-Key returns the original receipt with idempotency_hit: true, and reusing a key with a different payload returns 409 idempotency_conflict (Agent Completions). For the MCP tools, treat the key as dedup for the same intent and keep it stable per day.

Why the key must name the intent, not the clock

A key built from the current timestamp is new on every run, so it can never dedupe anything. A key built from the thing you mean to produce, the day, the product and the format, is the same on a catch-up and on a normal run. On REST endpoints the key can be 1 to 255 characters.

• Good: teaser-2026-10-04, or teaser-2026-10-04-product-42.
• Bad: a random UUID per run, or the wake-up time.
• Keep the key out of anything shared that you would not paste into a ticket.