Claude Code routine run is green: did the Sume video get made?
A green routine status means the session exited cleanly, not that the task worked. Read Sume's run receipt: status, outcome, output_error and billed amount.
No. In the Claude Code routines list, a green status means the session started and exited without an infrastructure error; it does not mean the task in your prompt succeeded. For a routine that starts Sume work, confirm the outcome from Sume's run receipt: status, then output, output_error and usage.billable_amount_usd_micros. A routine can finish green with a blocked request, a missing tool or a Sume run that failed.
The routine behavior is quoted from Anthropic's routines page read on 2026-10-03; the receipt fields come from Sume's Runs and results and Run webhooks pages.
Why can a green run hide a failure?
The routines page says blocked network requests, missing connector tools and task-level failures all surface in the transcript, not in the status indicator. Open the run and read what Claude did. That is slow for a nightly job, so give the routine one explicit last step: fetch the Sume receipt and state the result in a fixed form.
Which receipt fields decide success?
Sume run receipts return a status of queued, processing, completed, failed, canceled or skipped. A run webhook adds outcome, which the docs tell you to branch on when the question is whether you got usable output. A run can complete, bill you and produce real media while failing to project that media into your output_schema; that is degraded, with output null and output_error saying why.
| Field | Where | What it tells the routine |
|---|---|---|
status | Receipt, poll or webhook | Terminal state of the run |
outcome | Run webhook envelope | ok, degraded or error |
output_error | Receipt | Why structured output was not produced |
usage.billable_amount_usd_micros | Receipt | Generation spend attributed to the run |
skip_reason | Receipt | previous_run_active on a skipped run |
What should the routine's prompt say?
- Poll
status_urlfrom the receipt untilnext_actionstops beingpoll_status, with backoff. - Report one line:
status,outcomeif present, the primary output URL, and the billed amount in USD. - Treat
degradedandfailedas a failure of the routine, even though the session will end green. - Do not retry a paid create without the same
Idempotency-Key; a replay returns the original receipt withidempotency_hit: trueand no second charge.
What does a bad night look like?
A skipped run never starts work and never delivers a webhook, so a routine that waits for a POST will wait forever; read status on the response you already have. A canceled run does not deliver one either. When both outcomes are possible, polling the receipt is the one path that always answers.
A short check at the end of each routine is cheaper than reading transcripts later, and it turns the green dot from a guess into an assertion.
Sources
Related posts
More in Agents
- Claude Sonnet 4.5 retires Nov 30: what to move to on Sume
Anthropic deprecated claude-sonnet-4-5-20250929 on Sep 30, retiring it Nov 30, 2026 in favor of Sonnet 5.5. Sume's catalog has no Sonnet 4.5 row.
- Claude thinking blocks are model-bound: one model per thread
Sonnet 5.5 and Fable 5.1 thinking blocks only work for the model (and account) that made them. Why an agent thread should keep one model, and how to log it.
- Codex 0.160 Guardian review reads prior instructions: Sume args
Codex CLI 0.160 adds opt-in Guardian review that can fetch earlier user instructions. Write Sume calls so a reviewer can approve them from the arguments alone.
- Codex config.toml enabled_tools and required for Sume's read tools
Codex's MCP config can allowlist tools with enabled_tools and fail startup with required. Give a task only Sume's read and wait tools and a longer timeout.
Written by Sume