Log the exact video model id per shot after Runway model removals

When a vendor retires a video model, a logged model id turns the audit into a query. Record it on every shot, and know what Sume echoes.

4 min readSume
All posts

Log the model id, resolution, duration and job id for every shot you generate. When a vendor removes a model, you then find affected shots with one query instead of re-reading prompts. Sume's poll response echoes model, with one trap: if you send sume/auto, the response says sume/auto and the family that ran is never disclosed, so pin a model id when you need a record.

Vendors such as Runway retire model ids from their APIs from time to time. Sume details here come from the Video Generation docs.

What should one shot row hold?

Keep it boring. Everything below is a field Sume returns or accepts, so nothing needs to be inferred later.

Fields in the Sume Video Generation docs, read 2026-10-01.
ColumnSource
job_idid in the submit response
modelEchoed in the submit and poll responses
resolution, duration, aspect_ratioYour request
usage_costusage.cost in the completed poll response
idempotency_keyThe header you sent
statuspending, in_progress, completed, failed, cancelled

What does a removal look like on Sume?

Sume uses bare catalog ids and says an unknown id is a model-not-found case, to be checked against the Video Models API. If a model is retired, a request that names it fails instead of switching silently. That is a reason to log pinned ids: your history shows which shots used the retired model, and your next call can be pointed at a listed replacement after you check GET /v1/videos/models.

A minimal query when a model is retired

With the table above in any SQL store, the audit is one query: select the rows where model equals the retired id and status is completed, then regenerate or flag each shot. Keep the original prompt and the Idempotency-Key in the row, because replaying a key returns the original job; use a new key for the regenerated shot so it is billed as a new job. Failed jobs are described by Sume as releasing the reservation, so they do not need follow-up.

Why not leave it on auto?

sume/auto is convenient for tests, and Sume says resolution is a pure function of the request and the catalog version, so a replay prices and routes the same. It still hides the family, so a log full of sume/auto cannot answer which model made a shot. Use auto for exploration and a pinned id for anything you will ship or have to redo.

Limits: this post does not claim how Sume announces retirements, because the docs I read do not describe a notice process. Watch the changelog and the model list.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume