Workflows keeps state 7 days now: store your Sume job ids
Cloudflare Workflows on Workers Paid now keeps finished instance state 7 days by default. Save the Sume job id and result URL in your own store.

If a Cloudflare Workflow submits a Sume job, copy the job_id and the final media.sume.com URL into a store you control, because instance state is no longer a long-term record. Cloudflare's changelog says Workflows created on or after September 10, 2026 on Workers Paid keep completed and errored instance state for seven days by default, down from 30.
Sume behavior is from the Jobs and results docs; the Cloudflare entry was read 2026-09-30.
What did Cloudflare change?
The entry reads: “Workflows created on or after September 10, 2026, on the Workers Paid plan retain completed and errored instance state for seven days by default (previously 30 days).” The same page keeps the maximum retention at 30 days and the Free plan default at three days.
| Item | Value | Source |
|---|---|---|
| Paid default, workflows created on or after Sep 10 | 7 days | Cloudflare |
| Paid default before | 30 days | Cloudflare |
| Maximum retention | 30 days | Cloudflare |
| Free default | 3 days | Cloudflare |
| What Sume tells you to store | The job id from submit | Sume docs |
What should I keep from a Sume job?
The Sume docs say to store the job id from the submit response so an integration can recover work after a process restart. Also keep status_url and result_url when present, and once the job completes, the artifact URLs from the result. Use Sume media URLs from the result; raw provider URLs are not public outputs.
Can I still look a job up after the instance is gone?
With the job id, yes: GET /v1/jobs/{job_id} returns the job record and GET /v1/jobs/{job_id}/result returns the result once it is completed. That is why the id, not the Workflow instance, is the handle worth saving. The docs do not state how long Sume keeps a finished job readable, so copy the media you need to your own storage.
curl https://api.sume.com/v1/jobs/job_123 \
-H "Authorization: Bearer $SUME_API_KEY"
curl https://api.sume.com/v1/jobs/job_123/result \
-H "Authorization: Bearer $SUME_API_KEY"What happens if a step retries and submits twice?
Give every submit an Idempotency-Key derived from your own record, not from a random value per attempt. Reusing the same key for the exact same request returns the original job instead of billing a second one; reusing it for a different operation or payload is a 409 idempotency_conflict.
Sources
Related posts
More in Developers
- Workflows instance limits vs Sume queue headroom: which binds?
Cloudflare lists 50,000 concurrent Workflow instances (Paid, April entry). Sume reports your own generation headroom; size fan-out by that formula.
- Workflows .subscribe() vs Sume job events: push or pull?
Cloudflare Workflows can stream instance events with subscribe(). Sume has no SSE stream for jobs: use a signed webhook, or poll status and the events snapshot.
- Codex disabled_tools: block Sume's paid MCP tools
List Sume's paid tool ids under disabled_tools in the Codex config.toml so the agent cannot call them, even on an API-key session that sees every tool.
- Codex instant_interrupt mid jobs_wait: Sume jobs keep running
Codex's opt-in instant_interrupt lets new input steer a running turn. A Sume job submitted earlier keeps running and billing; re-read it with jobs_wait.
Written by Sume