Timeline edits or conversational edits

"Trim the first second off every clip and drop the music under the captions" is a sentence. Executing it on a timeline is about forty interactions. "Move that cut eleven frames later" is also a sentence, and executing it on a timeline is one drag. Both instructions are valid English and both describe a real edit, but only one of them is faster said than done.

The choice between describing an edit and building it is not a preference about interfaces. It is a question about which representation of the edit is smaller: the words, or the operations.

The two things are the same thing underneath

This is the part that surprises people. On Versely there is one editor and it stores one thing: an EDL, the project state containing timeline clips, trims, texts, music and captions. Both routes write to it.

The editor gives you the timeline surface. The agent's edit_video is an agent-driven EDL render through the same pipeline: one call that can stitch, trim, speed-change, caption, overlay and mix clips into a single final video. Describing a speed change in plain English does not bypass the edit list, it just means the agent constructs the entry instead of you dragging a keyframe.

Project state is separate from rendering. save_editor_project persists a draft, get_editor_project loads one back with the complete EDL, and list_editor_projects returns metadata only, id, title, duration, clip count, thumbnail and updated timestamp, newest first. The create-versus-update rule is the one worth memorising: omit the id and you create a new draft, pass an id and you update that one in place.

That single fact does most of the work in this comparison. Because both routes converge on the same artefact, you are not choosing a workflow you are locked into. You can describe an edit, load the resulting EDL, and adjust it on the timeline. The two are interchangeable per-change, not per-project.

Where each one wins

	Conversational	Timeline
Precision	Semantic. "Shorter", "punchier", "under the VO"	Numeric. Exact in/out points, exact frames
Reproducibility	Depends on the phrasing and the state it was applied to	The EDL is the record, byte for byte
Speed on broad changes	One sentence covers N clips	Linear in the number of clips
Speed on narrow changes	Slower than pointing at it	Immediate
Review flow	The instruction is the diff	The rendered output is the diff
Rollback	Requires an explicit snapshot first	Requires an explicit snapshot first

The pattern in that table is that conversational edits scale with breadth and timeline edits scale with specificity. An instruction that applies uniformly to everything compresses beautifully into words. An instruction about one boundary between two specific frames does not compress at all, and describing it takes longer than doing it.

Which edits are faster said, which have to be built

Faster said. These share a shape: they are a rule applied across the project, or they are a stack of operations that would otherwise be separate steps.

1. Uniform trims. "Take a second off the head of every clip." One sentence, any number of clips.
2. Multi-feature assembly. Stitch, music bed, voiceover, captions and an aspect-ratio change in one go. This is the case edit_video is explicitly built for, and it is preferred over chaining separate cut, audio and caption calls when you want a multi-clip assembly in a single step. The build-a-video-from-clips capability is this exact path.
3. Reframing. The aspect_ratio parameter reframes the whole output, so "give me the 9:16 version" is one instruction rather than a re-layout.
4. Repeat structure with new footage. Load a saved draft, swap the clips, re-render. That is the reusable-draft pattern and it is the highest-leverage version of this whole comparison.
5. Anything you would have to count. "Every third clip", "all the ones over four seconds". Rules are cheap to say and tedious to click.

Faster built. These share the opposite shape: the intent lives in a specific position, and the position is the whole point.

1. Cut placement against a beat. Music-locked cuts are a frame-level judgement. "On the beat" is not a spec, it is a hope, and you will nudge it either way.
2. Overlap and handles. Where exactly a transition starts eating into the outgoing clip is something you evaluate by watching, not by describing.
3. Text position when it collides. Caption placement that has to dodge a subject, a logo or a platform's safe area is a spatial decision. Describing it takes more words than moving it, and the words are less accurate.
4. Fixing one clip in a sequence of forty. Loading the draft and adjusting the one entry beats explaining which one you mean.
5. Anything you are still deciding. If you cannot state the change, you cannot describe it, and attempting to will produce a render you then have to react to.

A blunt heuristic that holds up: if you can write the instruction without watching the video, say it. If you have to scrub to explain it, build it.

Reproducibility and getting the previous version back

Neither route gives you undo for free, and this is where most of the real pain lives.

The EDL is the reproducible object. A rendered MP4 is an output, and outputs do not tell you how they were made. So the discipline is the same regardless of which surface you use: snapshot before a change you might want to reverse. Saving, listing and loading drafts are project-state operations rather than renders, so snapshotting a composition costs nothing to hold.

The mechanism is the create-versus-update rule, used deliberately:

1. Load the current draft with get_editor_project to get the full EDL.
2. Save it back without an id. That forks a new draft, leaving the original untouched.
3. Make the risky change on the fork.
4. If it fails, the original id is still there. If it works, keep the fork and let the old one age out.

Do this before any change described in words, because a conversational instruction is a request rather than a transaction. You are asking for an interpretation, and interpretations are not always the one you expected. Passing an id when you meant to fork is the mistake, and it overwrites in place.

The second discipline is preview before export. preview: true renders a free 480p pass, subject to a per-user cooldown, so it is not something you can hammer, but it is enough to check pacing, caption timing and whether the crop works before you commit. The final export at preview: false is the default and charges the standard editor export price once, regardless of how many features you stacked into the call. That is the part that changes behaviour: because the charge is per export rather than per operation, there is no reason to build up an edit in expensive increments. Stack everything into one render. The preview-and-export cost page has the fuller version, and the agent's estimate_cost will give you the exact number for your specific job before you confirm.

The review loop this implies

Reviews go badly when the reviewer's comments are in one medium and the edit is in another. The workable loop:

1. Assemble conversationally. Broad strokes, one call, everything stacked.
2. Preview at 480p. Send that, not a description.
3. Collect notes. Most will be broad ("too slow at the top", "captions are too small") and go back through words.
4. Take the frame-specific ones to the timeline. There are usually two or three, and they are always the ones that were hardest to phrase.
5. Fork the draft, apply, preview, export once.

The mistake is inverting steps one and four, building a precise timeline first and then trying to describe global changes to it. That is the expensive direction, because you have already paid the specificity cost on decisions the notes are about to overturn.

FAQ

Can I start conversationally and finish on the timeline?

Yes, and that is the intended shape. Both write to the same EDL, so a described edit produces a draft you can load and adjust. The one thing to watch is that you know which draft id you are working against, because the id is what decides between updating in place and forking.

Does a conversational edit cost more than a timeline edit?

No. The charge is on the render, not on how the edit list was authored. A stitched assembly built in one call and the same assembly built by hand export at the same standard editor price. What differs is how many previews you burn getting there, and previews are free at 480p with the cooldown attached.

What is the fastest way to undo a bad conversational edit?

Reload the previous draft by id. That is why the fork-before-change habit matters: without a saved id there is no previous version to return to, only the render you already have and whatever you can remember about how it was built.

Are simple trims worth doing conversationally at all?

For one clip, no. Trimming or cutting a single video is faster on the timeline and always will be. For a rule applied across a project it inverts immediately, usually somewhere around the fourth clip. The video editor surface exists for the first case and the agent path exists for the second, and the reason there is no single right answer is that the crossover point moves with clip count.