Replicate predictions source=web filter vs Sume jobs list

Replicate's predictions list takes a source query parameter whose documented value is web, so you can show web-created predictions apart from API-created ones, and results are limited to the last 14 days. Sume has no source filter: GET /v1/jobs returns the jobs the calling API key's member created in that workspace, and a thread_id filter can only narrow that set.

Replicate's side is from its changelog entry of January 14, 2026, read on 2026-10-03. Sume's side is from Jobs and results.

What does Replicate's filter do, exactly?

The changelog says the predictions API now supports filtering by source, with web as the value, and that when you filter by source=web the results are limited to predictions from the last 14 days. The page we fetched does not describe a filter for API-created predictions, so do not assume source=api exists.

How does Sume scope a job list?

Sume scopes by who created the job, not by where it was created. The docs set three rules for reads including GET /v1/jobs: an API key reads the jobs its own member created in the key's workspace; a Studio Agent turn reads every job in the thread it runs on; everything else is 404 not_found. A thread_id filter narrows a list and never widens what a key can read.

What does that mean for a team that shares one workspace?

Two people with two keys do not see each other's API jobs. If you want a shared view of what the team generated, you need either one shared key owner, a shared thread, or your own log keyed by job id. Do not expect a workspace-wide list from a personal key.

That is stricter than a list you can widen with a flag, and it is the right default for billing review because usage is recorded against the member who created the job.

How do you list your own jobs?

Call the list endpoint with your key. The request is a plain GET:

curl "https://api.sume.com/v1/jobs" \
  -H "Authorization: Bearer $SUME_API_KEY"

# narrow to one thread; this never returns more than the key could read
curl "https://api.sume.com/v1/jobs?thread_id=$THREAD_ID" \
  -H "Authorization: Bearer $SUME_API_KEY"

What does Sume not offer?

There is no source parameter and no documented 14-day cap in the pages we read, so build your own retention. If you need to separate dashboard-made jobs from API-made jobs, record that when you submit, for example in your own database next to the job id and idempotency key. Poll status with backoff and stop on completed, failed, or canceled, as the docs advise.

How do you keep a history longer than Replicate's window?

The Replicate changelog ties the 14-day limit to the source=web filter. That is a reason to export what you need rather than rely on the list as your archive. The same habit works on Sume, where the docs tell you to store the job id from every submit response so an integration can recover work after a process restart.

A simple record per job is enough: job id, your own label for where it came from (web, script, scheduler), the model id, the idempotency key, and the final status. With that, you can rebuild the 'web versus API' view that Replicate's filter gives you, on either platform.

What about teammates and shared dashboards?

Because an API key reads only the jobs its member created, a shared reporting job cannot enumerate everyone's work with a personal key. Plan for that before the first audit: decide which key owns scheduled work, and have people submit shared work through that one key or a shared thread. Sume's docs add that a Studio Agent turn reads every job in the thread it runs on, which is the supported way for a teammate to continue another person's work and read its results.

Reads outside those rules return 404 not_found, so a missing job is often a scoping question rather than a deletion.

• Pick one owner key for scheduled or batch jobs.
• Log the label and idempotency key at submit time.
• Use thread_id to narrow, never to widen.
• Poll status, and stop on completed, failed, or canceled.