Editing with Commands

Overview

Vlexor's editing model replaces a traditional timeline with a command bar. Instead of dragging clips and setting keyframes by hand, you describe the edit you want in a sentence, and the app turns that sentence into a concrete, ordered edit plan before a single frame is touched. This is the product's core interaction — the composer at the top of the app screen isn't a search box, it's the entry point for every kind of edit: trims, zooms, captions, color grades, transitions, and full pacing styles are all produced through the same pipeline, whether you type an instruction, strike out words in a transcript, or apply a one-click style template.

Every command is handled by what the codebase calls the Command Engine: a cloud endpoint that takes your natural-language text and returns an ordered list of typed edit steps — never raw video. Those steps are validated against a strict schema before they're shown to you or handed to the desktop app to render, so a step that doesn't parse cleanly is dropped rather than silently corrupting your edit. The result is a workflow that feels conversational on the surface, while the data actually driving the renderer stays exact and typed underneath.

The composer: from a sentence to a validated edit plan

The composer is a text box plus two small pickers — Effects and Reference — and a Send button. Typing a plain-language instruction, such as “cut the first 5 seconds, zoom in on my face, and add clean captions,” and pressing send (or Cmd/Ctrl+Enter) posts it to the plan endpoint, which classifies the request, decides whether it needs a frontier-model call or can be answered deterministically, and returns the ordered steps, the recommended output aspect, a one-line summary, and which model actually produced the plan.

Requests are classified by weight before anything expensive happens. A single-word tweak like “zoom” is treated as a light intent and is handled entirely by a fast, deterministic keyword planner — it never reaches a paid model. A real montage instruction — multiple words, or one containing an editing verb such as “edit,” “cut,” “caption,” “مونتاج,” or “قص” — is routed to the frontier model when an API key is configured, and that model is forced to respond through a single structured tool call rather than free text, so it can only ever produce step data, not prose. Whichever path produced the steps, every single one is re-parsed through the same schema that defines the six legal step types; anything that fails validation is silently dropped rather than reaching your plan.

The Effects and Reference pickers don't call a separate endpoint — toggling a chip (“wipe transition,” “vintage grade”) or applying a saved reference style appends a short natural-language hint straight onto the command you're about to send, so a click and a typed phrase are processed by the exact same planner. While you type, a debounced, no-charge request quietly previews what the full send is likely to produce, showing a live “Will apply: zoom, caption” hint before you've committed to anything. Each successful command also feeds Vlexor's style memory, used to power future suggestions, unless you've turned that off.

• steps – the ordered list of validated edit operations
• renderPreset – the recommended output aspect: YouTube 16:9, Shorts/TikTok 9:16, or custom
• summary – a one-line description of the edit, in your language
• modelUsed – the actual model that produced the plan, or “deterministic” when no AI call was needed

Text-as-timeline: editing the transcript is editing the video

When a project has a saved transcript, Vlexor renders every spoken word as an individual, clickable token beneath the composer. Clicking a word doesn't just cross out text — each word already carries the exact millisecond range it was spoken at, produced by word-level speech recognition, so striking a word is really selecting a span of time. The panel keeps a running count of how many words are marked for deletion and shows each one struck through.

Pressing “Apply cuts to plan” turns the selection into edit steps through a small, deliberately script-agnostic algorithm: it walks the word list once, merges any run of consecutive deleted words into a single contiguous cut — so striking a whole sentence produces one cut, not dozens — and reads only each word's timestamps, never its text. That last property is what makes it correct for Arabic, English, or a mixed line of both: the transcript package's test suite checks identical output for an all-English transcript, an all-Arabic transcript with non-adjacent deletions, and a mixed Arabic/English transcript where the deleted run straddles both scripts. In the interface itself, every word button renders with automatic text direction, so a line mixing right-to-left Arabic and left-to-right English displays correctly regardless of which script dominates that line.

Applying transcript cuts replaces any keep or cut steps already sitting in your working plan rather than adding to them — the render engine gives “keep” steps absolute priority over “cut” steps when compiling, so a leftover whole-clip keep from an earlier command would otherwise silently cancel your transcript-driven cuts. Transcripts themselves are desktop-originated: the web app can view and edit a transcript already saved to your project, but only the desktop app can create one in the first place.

The effect catalog: cuts, zooms, captions, grades, and transitions

Every edit plan is built from six step types defined once in a shared schema, so the same shapes are enforced no matter whether a step came from the frontier model, the deterministic planner, or a transcript-driven cut. Steps are additive and independent — a zoom and a color grade can both target the same range without conflicting — and a transition step is different from the rest: instead of describing a piece of footage, it marks a single point on the finished, cut-together timeline where two kept segments should blend into each other.

Captions are burned directly into the rendered file rather than shipped as a separate subtitle track, using the same subtitle-rendering approach regardless of language — Arabic and other right-to-left scripts render correctly with no special-casing required. Transitions compile to a real crossfade, wipe, or slide blend between the tail of one segment and the head of the next, not a straight cut with a label on it; the segment before a transition is rendered with a little extra footage specifically so there's real material to blend.

• Cut / Keep – mark a time range of the source clip to remove or to retain; a numeric trim like “cut the first 5 seconds” is actually expressed as a plan built from “keep” ranges
• Zoom – a punch-in on a time range, carrying an intensity value (the deterministic planner defaults to 1.3×; the schema allows up to 3×)
• Caption – a styled subtitle over a range, in one of three looks: clean, kinetic, or glass
• Grade – one of six named color-grade recipes — cinematic, vintage, vibrant, noir, warm, cool — each a distinct multi-filter look rather than a single saturation slider
• Transition – a crossfade, wipe, or slide placed at a specific point on the finished timeline

Style templates and reference matching

Beyond one-off commands, the composer has a Reference field for matching an existing style. Paste a YouTube link or describe a style in words, and Vlexor's Pacing Clone endpoint analyzes it into a concrete pacing profile — average shot length, cut frequency, how aggressively silence gets trimmed, zoom intensity, how much B-roll to lean on, and a caption look — which then gets folded into the hint text of your next command, the same way a toggled effect chip would be.

For a faster start, four built-in Style Templates apply that exact same pacing-profile shape with one click, no analysis step required: a fast-paced story vlog with energetic cuts, punch-in zooms, and kinetic captions; a cinematic trailer with dramatic reveals building to a climax under a cinematic grade; a clean explainer short that's calm, vertical, and lightly cut; and a long-form podcast edit with steady pacing and aggressive silence removal. Each one is grounded in scene-by-scene analysis of a real reference video rather than an arbitrary preset, and applying one highlights the active card and needs no network round-trip — it feeds the identical pacing-profile data a pasted reference would.

Bilingual by design: commands work in English and Arabic

Command support for Arabic is a real, tested capability of the product, not a translation layer bolted on afterward. The deterministic planner — the code path that runs whenever no AI key is configured, an AI call fails, or the request is simple enough not to need one — recognizes editing verbs and effect names in both languages side by side: “cut,” “zoom,” “caption,” “transition,” and “grade” alongside “قص,” “زوم” or “قرّب,” “ترجم,” “انتقال,” and “تدرّج.” It even understands Arabic colloquial phrasing for a punch-in (“قرّب على وجهي”) and correctly distinguishes a genuine request for a vertical Short from an unrelated English phrase like “make it shorter and tighter.”

Numeric trims work the same way in either language and either digit system: “cut the first 5 seconds” and “احذف أول ٥ ثوانٍ” both resolve to the same cut step, because Arabic-Indic and extended Arabic digits are normalized to plain numerals before parsing. When a request is complex enough to reach the frontier model, that model is explicitly instructed to keep any generated caption text in the user's own language, and the locale you're working in is passed through on every plan request so language-sensitive decisions stay consistent end to end. In the interface, every piece of user-generated or mixed-language text — transcript words, applied-reference labels, plan-step summaries — renders with automatic text direction, so Arabic and English can sit on the same line without breaking layout.

Where your video actually gets rendered

The web app you compose commands in is a planning surface, not a renderer — its own interface says as much once a plan comes back: live editing runs on the desktop app, and what you're looking at is the plan the AI produced, not a rendered preview. The desktop app is where your source video actually lives, and it's the only place any frame of it is ever processed.

When you send a command from the desktop app, it calls the exact same cloud Command Engine as the web composer, passing only the command text and lightweight context — a duration in seconds, an optional excerpt of an existing transcript, and your locale. The video file itself is never part of that request. Once the cloud returns validated steps, the desktop app compiles them locally into a real render command — deriving which segments to keep, resolving each zoom's crop, looking up each grade's actual filter recipe, generating a subtitle file for any captions — and executes it on your machine. Trimming, cropping, color grading, subtitle burn-in, and transition blending all happen on-device; none of it touches the network.

The one place audio does leave the device is transcription, and even then only a short, silent extracted audio track is uploaded, never the video: the desktop app pulls a mono audio track out of your local file, sends only that to the transcription endpoint, and the endpoint itself enforces that constraint — it rejects anything that isn't an audio file outright, on top of the speech-recognition provider's own size cap. Outside of that one flow, nothing in the app's cloud API accepts a media upload of any kind: the command-planning and pacing-analysis endpoints take only JSON text, and transcription is the sole route in the entire API surface that handles a file at all, with that explicit audio-only check built in.

• Reaches the cloud: your typed command text, duration and locale context, an optional transcript excerpt, and — only for transcription — a short extracted audio track
• Never leaves your device: the source video file, the rendered export, and every actual frame of video processing — trimming, cropping, color grading, caption burn-in, and transition blending

Reliability: the deterministic fallback and usage limits

The composer is designed to work even with no AI provider configured. Whenever a frontier-model call fails, or a request is deliberately routed away from one because it's simple enough to be sure of the answer, an entirely deterministic, keyword-based planner produces the plan instead — it recognizes numeric trims, zoom and punch-in verbs, all six color-grade looks, caption requests with a specific style, transition requests with a specific kind, and vertical-format keywords, in both English and Arabic, without ever calling an external model. It's honest about its limits, too: a vague instruction like “cut the boring parts” produces no cut, because locating a “boring part” genuinely isn't something a keyword match can do safely — that's left to the frontier model or to your own transcript edits, rather than a guess.

If you're on an active paid plan, the Command Engine also enforces usage windows sized to that plan — a rolling five-hour cap plus daily, weekly, and monthly caps — before processing another AI-assisted command; going over one of those windows first checks whether a purchased credit pack can cover the extra minutes before it blocks you outright. Every command you send, along with the model that produced it and the exact steps it returned, is logged against your project, building a running history of every edit you've applied.