- The problem
- A 48-minute video is too much for an AI to plan in one go, and every cut it makes moves the timestamps after it. A plan that was right when it was made can be wrong by the time it is applied.
- What I did
- The video is split into four-minute stretches that are views of one document, not separate copies. The AI decides the film-wide choices first, then edits one stretch at a time, re-reading the current timeline before each step.
- What happened
- On a 48-minute recording the AI applied 98 edits, up from 44 in the earlier version, and none was refused for referring to a part of the timeline that had moved.
I set the limit on how much the AI sees at once and chose the order: film-wide decisions first, then local edits against the current document.
I designed HYVIRAL’s editing of long videos around two constraints: an AI call needs a task it can hold in view, and its plan must refer to the timeline as it is now. A cut moves later timestamps and a split creates new clip IDs, so a sensible plan can be invalid before it reaches the document.
neighbor context10 sec
neighbor context
Use current clip IDs and timing.
Keep the film-wide choices fixed.
The next plan sees this change.
Bound the agent’s task. Keep the film’s state shared.
Give the AI four minutes at a time, from one shared document
I kept one editable project document; the segments are views of it, not separate documents to merge later. Each local planning call receives its segment, ten seconds of context on either side, the film-wide outline and decisions, and what the pass has done so far.
Segments target four minutes, within two to five. They prefer a nearby sentence ending or scene change, fall back to a clock boundary and allow a short final segment, so the work stays bounded even when the footage does not divide neatly.
Separate documents would have needed merge logic and undo across segments; sending the whole transcript on every call kept the overload I was removing. The tradeoff is more planning calls and repeated shared context, in exchange for a smaller task per call that still serves one film.
How the video is split into four-minute segments, from the architecture spec and the planner code: a four-minute target, a clock fallback when no sentence or scene boundary fits, and a deliberately short final segment.
Read the sourcePlan each segment against the video as it is now
I chose a server-controlled sequence: film-wide choices first, then local edits planned and applied in order, with the document re-read before each call for its current clip IDs and timing. Caption style, look, fades and music travel with each local prompt, and a film-wide operation proposed locally is removed and recorded.
Planning all segments at once from one copy of the timeline offered speed, but earlier edits could invalidate later plans. The model proposes edits while the server decides which step runs next, which keeps the workflow quotable, resumable and inspectable.
The cost is doing the steps one after another, which buys current references and a predictable order. Targeted segment tools let a small follow-up revision skip another full pass.
The locked decision to edit in order, and the planner’s input: the document is re-read before every segment, and the film-wide choices travel with each call.
Read the sourceResults
In a September 2026 evaluation driven by an outside assistant, the revised workflow applied 98 edits across 12 segments of a 48-minute, 20-second recording, against 44 in the previous pass.
A dry run removed nine proposed edits before application. The remaining 98 applied with zero refusals from the editor and zero removals by the scope filter, the two checks that reject an edit pointing at a stale or out-of-bounds part of the timeline. Applied edits reached 2.03 per minute, above the comparison threshold of 1.57.
That measures applied work, not artistic quality: the cut still went through its own export and human review (see trusting the quality checks).