Veo 3.1 deletes clips after 2 days: archive them, and the Sume path
Google keeps Veo 3.1 videos on its server for 2 days, and extending a clip resets the timer. Download on completion. Veo 3.1 is not in the Sume catalog.

Veo 3.1 deletes generated videos 2 days after they are made. Google's Veo guide says: "Generated videos are stored on the server for 2 days, after which they are removed." A pipeline that stores only the Google file reference will lose clips on day 3, so download each clip when the job completes and keep your own copy.
Sume does not carry Veo 3.1. The Sume video catalog has one Google video model, gemini-omni-flash-1.1, and it follows a different download path (below).
What Google documents for Veo 3.1
The 2-day window is the only retention figure in the Veo guide. Extension is the one feature that moves it.
| Item | Documented value | Source |
|---|---|---|
| Server-side storage | 2 days, then removed | Veo guide |
| Extended videos | Timer resets on the extended video | Veo guide |
| Extension limits | Veo 3.1 and 3.1 Fast only; adds 7 seconds per call, up to 20 times; 720p only | Veo guide |
| Preview ids end | veo-3.1-generate-preview, veo-3.1-fast-generate-preview and veo-3.1-lite-generate-preview shut down October 22, 2026 | Deprecations page |
The archive pattern
Treat the Google file as a handoff, not storage. When the job finishes, copy the bytes to your own bucket in the same worker, and save your own object key in your database. Do not save only the Google reference.
If you extend a clip, Google resets the timer on the extended video. Still archive every clip you want to keep, including the intermediate ones, as you make them.
The same step on Sume
Sume video jobs are asynchronous. You submit to POST /v1/videos, poll GET /v1/videos/{id}, and read unsigned_urls when the status is completed. Each URL is the content endpoint, GET /v1/videos/{id}/content?index=0. The Sume docs send the API key as a Bearer header on that call, and the script below does the same.
import asyncio, os, requests
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
async def main():
job_id = "job_01HXYZ" # the id from POST /v1/videos
url = f"https://api.sume.com/v1/videos/{job_id}"
while True:
r = await asyncio.to_thread(requests.get, url, headers=H)
job = r.json()
if job["status"] == "completed":
break
if job["status"] in ("failed", "cancelled"):
raise SystemExit(job.get("error", job["status"]))
await asyncio.sleep(30)
clip = await asyncio.to_thread(requests.get, job["unsigned_urls"][0], headers=H)
with open(f"{job_id}.mp4", "wb") as f:
f.write(clip.content)
asyncio.run(main())What differs between the two
The Sume docs do not state how long a generated clip stays available. The docs do say that expired is a status in the enum for wire compatibility, but Sume does not expire jobs now, so the API never emits it. Treat the retention window as unspecified and copy the file to your own storage in either case.
| Question | Veo 3.1 on the Gemini API | Sume /v1/videos |
|---|---|---|
| Is the model available? | Yes, three preview ids until October 22, 2026 | No. Use gemini-omni-flash-1.1 |
| Where do the bytes come from? | Google server, 2-day window | GET /v1/videos/{id}/content?index=0 |
| Documented retention | 2 days | Not stated in the docs |
expired status | Not applicable | In the enum, never emitted |
Sources
Related posts
More in Developers
- Verify a Sume Avatar Video Webhook in Ruby (HMAC-SHA256)
A Ruby verifier for Sume job webhooks: sign timestamp.raw_body with HMAC-SHA256, accept a rotation header, refuse an empty secret, and dedupe on job_id.
- Vertical 9:16 text-to-video API: a 12-second Wan 3.0 clip, priced
A 12-second 9:16 text-to-video request on Sume with Wan 3.0 costs $0.75 at 480p, $1.50 at 720p and $3.00 at 1080p. Full body and the other models that fit.
- OpenRouter video lists 4-8 second clips; Sume model ranges run 2-30s
OpenRouter's video guide shows typical 4-8 second durations. Sume validates duration per model, from 2-30s on Wan 3.0 to 3-10s on Omni 1.1. See the table.
- Video edit on Sume: video_url cannot ride with image fields
For gemini-omni-flash-1.1 video-to-video edit, video_url is the source, not a reference. Mixing it with image_url or reference lists fails. Fix and examples.
Written by Sume