run_timeline_batch
Run MULTIPLE timeline-tool calls in ONE request, where a LATER step can reference a value produced by an EARLIER step in the SAME batch — the fix for 'split this clip, then move just the second half': you don't know the new second-half clip's id until AFTER the split has actually run, so normally that needs two separate turns. In a batch, give the split step a step_id (e.g. "step1"), and reference its result in a later step's args as a string like "$step1.timeline.tracks.0.clips.-1.id" (dotted path into that step's own JSON result; a numeric segment like -1 indexes into a list, -1 = the last item — the newest clip on a track after a split/add is always last). tracks.N here is ordered by (video/overlay tracks first, then audio; ascending index within each) — NOT by when the track was created — so tracks.0 reliably means 'the lowest-index video track' even if an empty leftover track exists elsewhere. Still, prefer referencing a clip/track by its literal id once you have one (e.g. from an earlier step's own clip_ids or a job//timeline.txt call) over a tracks.N/clips.N positional path when you're not certain which position you mean — positional indexing is a convenience for the common 'the track/clip I just touched' case, not a stable general-purpose address. Every step's tool must be a real timeline tool name (job//timeline.txt first if you need to see a tool's exact result shape before referencing it). All-or-nothing: the first step that fails stops the whole batch immediately and later steps never run — check each entry in the response's step_results for where it stopped. Use this whenever a plan has TRUE ordering dependencies (step 2 needs data step 1 just created); for independent clips with no cross-references, add_clips_to_timeline is simpler.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | ||
| fields | No | ||
| job_id | Yes | ||
| response_detail | No |