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.

4 min readSume
All posts

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.

Runway changelog entry (read 2026-10-03)
DateEntryAvailability
Oct 1, 2026OpenAI Dots x Runway: brief a dot, it plans shots, Runway shootsAll 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

All Agents posts

Written by Sume