Gemini Omni previous_interaction_id vs a Sume job per request

In Google's Gemini API, previous_interaction_id links a new client.interactions.create call to an earlier video interaction so the model continues that scene. Sume's published video contract has no equivalent field: every request is a separate job with its own id, and you carry state yourself by passing media back in.

The Google side is from its Omni 1.1 Flash developer post; the Sume side is from Video generation and Video Router, both read 2026-10-01.

What does previous_interaction_id do in the Gemini API?

Google's example calls client.interactions.create with previous_interaction_id set to an earlier video interaction and a text input of "Continue the scene." Google says Omni 1.1 can analyze up to 10 seconds of prior context, where earlier models referenced only the final second, and that you extend in 10-second increments up to 40 seconds in total.

The state, in other words, lives on Google's side and is addressed by an interaction id.

How does Sume handle the same job?

Sume does not chain by id. A request to the Video Router with gemini-omni-flash-1.1 returns a job; poll it and read the result when it completes. To build on a result, you send the next request yourself, using the clip as input. The docs list Omni Flash 1.1 at 3–10 seconds at 360p/720p/1080p/4K in 16:9 or 9:16 with native synced audio, and it exposes video edit mode through the Video Router video_url field.

That edit mode is the closest Sume analogue to "take this clip and change it". For longer sequences, see the 40-second extension comparison.

curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: omni-edit-001" \
  -d '{
    "model": "gemini-omni-flash-1.1",
    "prompt": "Replace the bottle with an apple. Keep everything else the same.",
    "video_url": "https://example.com/clip.mp4",
    "resolution": "720p",
    "mode": "async"
  }'

What changes in my code?

Why does the Idempotency-Key matter here?

Because each step is its own paid job, a retried network call could otherwise create a second one. The docs say to send Idempotency-Key so retries are safe. Store one key per logical step, and see idempotency keys for AI video APIs.