OpenAI Dots x Runway: brief a dot, it plans shots. The Sume loop
Runway's Oct 1 changelog lists OpenAI Dots x Runway for all plans: brief a dot, it plans shots, Runway shoots. The same loop with Sume MCP tools.

Runway's changelog entry for October 1, read 2026-10-03, announces "OpenAI Dots x Runway" for all plans: you brief a dot, it plans the shots, and Runway shoots them. The same plan-then-render loop works with Sume's hosted MCP tools, where an agent calls generate_video for each shot and waits with jobs_wait.
What Runway announced
The changelog line is short, so only the stated behavior is repeated here.
| Date | Entry | Availability |
|---|---|---|
| Oct 1, 2026 | OpenAI Dots x Runway: brief a dot, it plans shots, Runway shoots | All plans |
The loop on Sume
The hosted MCP inventory in the tools doc lists paid creation tools including generate_image, generate_video, music_create, tts_create and stt_create. Paid submits need an idempotency_key, and omitting payload.model routes to sume/auto unless the user named a family.
A typical agent turn plans N shots, submits N generate_video calls, then waits once with a batch jobs_wait. The jobs guide says jobs_wait accepts 1-20 job ids with wait_for set to all or any, and advises one batch wait after a parallel fan-out instead of N single waits.
Waiting without losing work
A remote MCP call holds at most 55 seconds, with 50 as the default. When a wait returns wait_slice_expired, call jobs_wait again with the same ids. Do not resubmit the paid create, because the jobs keep running and keep billing. A 524 on jobs_wait is a transport failure, never a job outcome.
Programmatic fan-out
For three or more independent calls of the same shape, script_run runs a short JavaScript program on the Sume side that calls tools in a loop or in parallel, bounded by timeout_seconds (5-55), max_calls and max_paid_calls. Each paid create inside the script still needs its own idempotency_key.
Use it for a shot list: one call per shot, one returned value, and the child jobs listed for one batch wait afterwards.
Keeping control of spend
An agent that plans shots can also overspend. On Sume, the script bounds help: max_calls and max_paid_calls cap how many tool calls a script may make, and paid creates need an idempotency_key, so a retried step does not bill twice.
Set a shot budget before the plan runs, ask the agent to list the shots with durations first, and approve the list. Then render.
What stays the same
Whatever drives the plan, each shot is a job with an id, a model, a duration and a cost. Save those with the shot list so a re-render of shot 4 does not mean regenerating shots 1 to 3.
Sources
Related posts
More in Agents
- Qwen3.8-Omni-Flash for audio agents: tool access
Qwen3.8-Omni-Flash is an omnimodal model for agents. Whatever model you pick, give it Sume's hosted MCP tools and check tools_list before any paid call.
- script_run or Agent Completion: which for a GPT-6.1 Sol agent?
A GPT-6.1 Sol coding agent can call Sume via MCP script_run or Agent Completions. Which fits fan-out of known calls, and which fits open-ended tasks.
- TikTok trend search then import over Sume MCP: $0.10 + $0.15
Searching TikTok trend metadata costs about $0.10 and importing one video about $0.15 over Sume MCP, so a find-and-mirror step is about $0.25 before generation.
- What did my seller agent spend? Read Sume usage by thread
Amazon's Seller Assistant plugin logs its actions with audit trails. For the media your agent made through Sume, read the cost by thread_id and run_id.
Written by Sume