Velocut: a browser video editor where the LLM is the first user

The problem Velocut targets: two editors, one document

Most editors with an AI feature bolt a chat panel onto an existing UI state machine. The assistant calls hidden APIs, and when it does something wrong you undo it like any other action, with no record of what the model believed. Velocut inverts that. The README states that humans edit via the UI and the LLM issues JSON commands directly, and both flow through one command pipeline into one document model. The project calls the AI agent the system's first-class user, and says the UI's job is to make the agent's perception and actions visible and correctable.

That framing explains the rest of the design. The audience is not the general video hobbyist. It is an engineer or small team that wants an agent to perform bulk edits (cutting silence, placing title cards) on local media, and wants every agent step to appear as a chat card in a branching history tree that can be clicked or undone. If you only want a timeline editor, the agent machinery is overhead you will carry anyway.

The command pipeline, the two engines and the golden vectors

There are two implementations of the same engine. A canonical Rust engine compiles to WASM, and a TypeScript reference engine mirrors it. The README states they are kept in lock-step by shared golden-vector tests, and the justfile encodes that contract: the test recipe runs cargo test and then npm --prefix web test, and both read protocol/vectors/*.json. Any change to engine behavior must land as a new vector, and both sides must pass to count as consistent.

Compositing is handled by WebGPU and decode/export by WebCodecs, which is why the browser requirement is Chrome or Edge 113+ and why Safari and Firefox are listed as not yet supported. The editor falls back to the TS engine when the optional Rust/WASM bundle is absent, and the status bar shows which engine is active. That fallback is the pragmatic part of the design: you can clone the repository and edit before you have ever installed a Rust toolchain. The Cargo.toml comments explain why velocut-wasm is excluded from the default workspace members, since environments without the wasm32 std cannot build it.

Installing Velocut and running a first edit

There are three entry points, and they are not equivalent. The portable release needs no npm install and no source checkout: extract the directory and run the start script, which serves the prebuilt editor and opens the browser. Keep the terminal running, and reuse the hostname and port it prints, because the README notes that browser projects are scoped to that origin.

node start-studio.mjs

The npm route is documented as working after the requested version is published, and the README warns not to assume a version has been published just because it builds.

npx @velocut/[email protected] studio

From source, the dev command builds the workspace SDKs first. Node 22.6 or newer is required (npm test uses --experimental-strip-types), and a .nvmrc sits at the repository root.

git clone https://github.com/open-ribbi/velocut.git
cd velocut/web
npm ci
npm run dev

For a first real use, open the Assistant in the workspace navigation and configure a provider in the settings panel. The README says your own Anthropic API key works as-is, that the key lives only in browser localStorage, and that requests go straight from the browser to the configured endpoint with no intermediary server. The provider settings accept any Anthropic-protocol-compatible base URL (LiteLLM, one-api, a corporate proxy), a choice of x-api-key or Authorization: Bearer auth, custom model ids, and a one-click connection test. The endpoint must allow browser CORS requests. Manual editing and the Codex plugin need no model key.

Building the canonical Rust/WASM engine

The portable releases use the TS engine by default for reproducibility. To get the Rust engine, you add the wasm target, install wasm-pack, and build the crate into the editor's public directory. The justfile wraps this as just build-wasm, and the README gives the manual equivalent.

rustup target add wasm32-unknown-unknown
cargo install wasm-pack
wasm-pack build crates/velocut-wasm --target web --release \
  --out-dir web/apps/editor/public/wasm
cd web && npm run dev

After that the status bar badge switches to "engine: Rust/WASM". To include freshly compiled artifacts in a release build, set VELOCUT_INCLUDE_WASM=1 when running npm run build:release. Release builds copy only declared application and SDK assets, and the README says local videos in the development public directory are excluded. The build profile in Cargo.toml uses opt-level 3, fat LTO and one codegen unit, which is a compile-time-for-runtime trade you will feel on every rebuild.

Where Velocut is the wrong tool

The browser matrix is the first hard limit. Chrome or Edge 113+ only; Safari and Firefox are not supported yet. Any team with reviewers on Macs running Safari, or a policy that standardizes on Firefox, cannot use this for review passes.

The second limit is the dev-server proxies. Web search through Gemini grounding and MiniMax cloud TTS are proxied by the Vite dev server, which injects secrets server-side from gitignored key files under web/apps/editor/. The README is explicit that these proxies exist only under npm run dev, and that after a static vite build, search and cloud TTS are unavailable. So a self-hosted static deployment loses two agent capabilities that work on a developer machine. Local TTS needs no key, which softens that but does not remove it.

Third, the trust model is not a sandbox. The README states that AI observations and optional cloud features send the data needed by the selected provider. Key storage in localStorage and direct browser-to-endpoint requests mean your provider sees the frames, contact sheets and analysis the agent requests. If the media cannot leave the machine at all, the agent path is unusable, and only manual editing remains. Finally, the README does not document rollback of a release or a downgrade path, so pinning the portable bundle you validated is the only safe assumption.

How it compares to a desktop NLE and to a server-side pipeline

Against a desktop non-linear editor such as DaVinci Resolve or Premiere, the difference is not features, it is where state lives and who can drive it. A desktop NLE keeps the project in a proprietary binary and exposes scripting as a second-class surface. Velocut keeps a document model behind one JSON command protocol and treats the agent as a first-class user of that protocol, which is why an agent step shows up in the same branching history tree as a manual cut. What you give up is codec breadth, plugin ecosystems and GPU driver control, since you inherit whatever WebCodecs and WebGPU expose in Chrome.

Against a server-side pipeline built on FFmpeg, the split is inverted. FFmpeg is scriptable, headless and runs anywhere, but there is no interactive preview and no document model with undo; you re-run the job. Velocut gives you a live WebGPU-composited preview and a rollback-able history, but it needs a browser session and a human or agent driving it. Teams that already automate renders in CI should keep FFmpeg for the batch step and treat Velocut as the interactive layer, not a replacement.

MCP, Codex and licence

The portable release directory doubles as a local Codex plugin marketplace. You add that directory as a marketplace source, install Velocut, start a new Codex task, and ask Codex to connect to the running Studio URL. It returns a pairing link; you open it and let Codex select the intended project session. Other MCP clients can start the published @velocut/mcp package through npx or its installed velocut-mcp executable. The README is clear about the division of labor: reasoning runs in your client's model, while the editor owns rendering, state, conflicts and undo.

On maintenance, the last push to the default branch was on 2026-09-10, and the repository is not archived. There are no retrieved releases, and the README states that registry publication is a separate maintainer step, so treat version availability as something to confirm rather than assume. The project is MIT licensed, with the workspace package declaring license = "MIT" in Cargo.toml. MIT is permissive, so redistribution and modification are allowed provided the copyright notice and permission notice are kept; the repository also carries SECURITY.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md. That is a description of the licence text, not legal advice. The upgrade cost is mostly toolchain-shaped: Node 22.6 or newer, Rust stable plus wasm-pack if you want the canonical engine, and a re-run of the shared vectors on both sides whenever engine behavior changes.

Editorial conclusion

Adopt Velocut if you edit in Chrome or Edge on a workstation with WebGPU, want media to stay on the machine, and are willing to treat an LLM as a co-editor that issues JSON commands. Do not adopt it if Safari or Firefox users are in the loop, if you need cloud TTS or web search in a static build, or if you need a published npm version today, since the README states registry publication is a separate maintainer step. Verify first that the status bar reports the engine you expect, that your provider endpoint allows browser CORS requests, and that your project origin stays the same across restarts, because browser projects are scoped to the origin the server prints.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. open-ribbi/velocut on GitHub
4. Project website
5. README