Replicate output files deleted after an hour: what Sume's URLs do
On Replicate, files from API predictions are deleted after an hour. Sume's Format run docs call media URLs durable, but check expires_at when a URL is signed.
For predictions created through Replicate's API, output files are automatically deleted after an hour, so you must save a copy of anything you want to keep. For predictions created in its web interface, files are kept indefinitely unless you delete them. Sume's Format run docs say the opposite for their output: media URLs are durable media.sume.com HTTPS URLs that do not expire. The one thing to check on Sume is the expires_at field, because a signed URL can carry an expiry.
Replicate's rule is from its Output files page, read on 2026-10-02. Sume's are from Format runs, Structured output and the core workflow page.
What exactly does Replicate delete?
The Data Retention section says API-created predictions have their output files deleted automatically after an hour. It points to the webhooks docs for how to store prediction data. Files are served from replicate.delivery and its subdomains, and the page tells you to add replicate.delivery and *.replicate.delivery to any allow list of external asset domains, with a Next.js remotePatterns example.
The practical rule is to copy the file to your own storage when the prediction finishes, from the webhook or the first poll that shows completion.
What do Sume URLs do?
The Format run page says media URLs are durable media.sume.com HTTPS URLs that do not expire, and that they are public to anyone holding the URL, so proxy or copy them if your product needs per-customer access control. The structured output page says expires_at is null for durable media.sume.com URLs, which is the normal case, and is populated only when a signed URL is returned.
For generation jobs, the core workflow page says completed jobs can include public artifacts under https://media.sume.com, and that Sume-owned artifact URLs are the public contract, not raw provider URLs. The image generation page describes its result URLs as Sume-hosted and signed, so for images read expires_at instead of assuming.
How do the two compare?
The difference is who has to act, and when.
| Question | Replicate | Sume |
|---|---|---|
| How long do API outputs last? | Deleted after an hour | Format run URLs: do not expire; expires_at is null when durable |
| Who can open the URL? | Not stated on the page | Anyone holding a media.sume.com URL |
| Domain to allow-list | replicate.delivery and *.replicate.delivery | media.sume.com |
| Web-created files | Kept unless you delete them | Not applicable |
| What to do | Copy within the hour | Store the URL; check expires_at; proxy if you need per-customer access |
What should I store?
On Replicate, store the file itself. On Sume, store the job or run id and the artifact URL against your own record, and keep expires_at next to it. If it is null you can render the URL later with no refresh; if it holds a date, fetch the result again before that date.
Sources
Related posts
More in Comparisons
- Replicate Cancel-After header: 5 s to 24 h. Is there a Sume deadline?
Replicate's Cancel-After header sets a prediction deadline from 5 seconds to 24 hours. I found no deadline field in Sume's OpenAPI, so cancel it yourself.
- Replicate predictions time out at 30 minutes: Sume's deadline
Replicate stops a prediction after 30 minutes unless support raises it. Sume documents no such field: the deadline is client-side and a timeout does not cancel.
- Replicate Prefer: wait holds 60 s by default; Sume's sync cap is 30 s
Replicate's Prefer: wait header holds the request up to 60 seconds by default; Sume's sync mode waits at most 30 seconds, then returns a job to poll.
- Replicate private models bill idle time: how Sume bills a job
On Replicate, a private model on dedicated hardware bills setup, idle and active time. Sume bills per job: a reserve at submit, then capture or refund.
Written by Sume