Export old video prompts to JSONL, then re-render on Sume resumably

Export your old video prompts to a JSONL file first, one object per clip, and let the re-render script read and rewrite that file. A line carries the prompt, the model and settings, a stable key, and a job_id once submitted, so a crash or a rerun never submits the same clip twice. The Sora API ended on 2026-09-24 (Magic Hour tracker, read 2026-10-06), and the prompts in your database or logs are what you still own.

The two things Sume gives you for this are a durable job id on every submit and the Idempotency-Key header, which makes a replay return the original job instead of billing a new one (Sume video docs, read 2026-10-06).

The manifest line

The script

It reads prompts.jsonl, submits each line without a job_id, and rewrites the file after every submit. Run it again after a crash and it carries on.

import json
import os
import requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
rows = [json.loads(x) for x in open("prompts.jsonl") if x.strip()]

for row in rows:
    if row.get("job_id"):
        continue
    body = {k: row[k] for k in ("model", "prompt", "aspect_ratio",
                                "resolution", "duration") if k in row}
    r = requests.post("https://api.sume.com/v1/videos",
                      headers={**H, "Idempotency-Key": row["key"]},
                      json=body, timeout=30)
    if r.status_code == 402:
        print("balance too low, stopping")
        break
    r.raise_for_status()
    row["job_id"] = r.json()["id"]
    with open("prompts.jsonl", "w") as f:
        f.write("\n".join(json.dumps(x) for x in rows) + "\n")

Why this shape

• A stable key per clip means a timeout on the submit is safe to retry: the replay returns the original job.
• Writing after each submit keeps the file true if the process dies; the cost is rewriting a small file many times, which is fine below a few thousand lines.
• Stopping on 402 follows the docs: Sume reserves the estimated cost at submit and answers 402 insufficient_credits before any provider work starts, so a low balance never leaves a half-run job.
• Large exports are limited by queue capacity per plan, not by the script; submit in waves.

What to change in the prompts

Do not send old text untouched to a different model and expect the same shot. Seed is not accepted on any v1 model, so a rerun is a new take, not a copy. Pick one model per line from the catalog, check that its supported_durations include your length, and keep the old prompt next to the new one so you can compare. The posts on queue capacity by plan and on checking the balance first cover the limits that decide the size of a wave.

When the file is all job_ids, collect the results with GET /v1/videos/{id} or a callback, and write the unsigned_urls entry or your copied file path next to each line.

Getting the prompts out of the old system

The export itself is the part people skip. If your prompts sit in an application database, a single query to JSON Lines is enough. If they sit in logs, parse the request bodies you stored when you called the old API. Either way, capture the prompt text, the length you asked for, any reference image URLs, and the date, plus an id you control.

Do not rewrite prompts while you export. Keep the original text as prompt_original, and add a new prompt field if you edit it for a new model, so you can compare the take with the old intent. Review a sample of fifty lines by eye before the first paid run; a bad export is cheaper to catch in a text editor than on an invoice.

• Make the key from your own stable id, not from a line number that changes when you sort.
• Validate every line against the catalog before submitting: model id, duration range, ratio and resolution.
• Submit a small wave of ten, check the results, then raise the wave size.
• Keep the manifest in version control or a bucket, so the record of what was rendered survives the script.