OpenChatCut: an agent-native video editor where the AI writes to a real timeline

The gap OpenChatCut is trying to fill between timeline editors and one-shot generators

Two kinds of video tools dominate right now, and they fail in opposite directions. A traditional multitrack editor gives you clip-level control but no way to say "cut every pause and add captions" and have it happen. A one-shot AI generator gives you that sentence, then hands back a file you cannot inspect, re-cut or hand to someone else. OpenChatCut's README frames the project as an open-source ChatCut alternative that sits between the two, and the repository backs that up with a timeline, an agent loop and an export path in the same application.

The intended user is specific: a creator or developer who already thinks in tracks and clips, and who wants an agent to participate in that workflow rather than replace it. The README states the project is independent open source under AGPL and not affiliated with the commercial ChatCut product. If you have never opened a timeline editor, this is not the tool that teaches you; it assumes you will want to intervene manually at some point, which is exactly why the agent writes to real tracks instead of rendering a finished file.

How the agent loop writes to tracks instead of rendering a black box

The README describes a loop in plain terms: describe the goal, the agent reads the project, produces verifiable edits, writes them to the timeline, then you preview, adjust or undo, add captions and mixing, and export. The important word is writes. Every change lands as a track, clip, transition, caption, effect or media reference inside the project, which is why undo, redo, version saves and manual editing still work afterward.

Around that loop the repository lays out a client and server split. The top level contains src/ for the editor UI, server/ for agent runs, desktop/ for the Electron shell, remotion/ for rendering, skills/ for Agent Skills, and shared/ for code used on both sides. The .env.example confirms the LLM layer is the Vercel AI SDK with per-provider credentials, and it notes that API keys stay server-side, which matches the README's claim that media and projects stay local while keys do not ship to the browser.

The agent is not the only client. The README states the built-in agent and external MCP agents share the same editing tools, and the repository ships a .mcp.json alongside a dev-with-mcp.sh script. That shared-tool design is the part worth judging: it means a Claude Code or Codex session is not a second-class citizen with a smaller command set, but it also means the tool surface has to be stable enough for two callers, which is a real maintenance commitment for a project at v0.2.x.

Installing OpenChatCut and running a first agent edit

The README points at the project website and the release list rather than walking through a desktop install, so the reproducible path in the repository is the development one. Node is pinned by engines and by .nvmrc: the package.json requires Node >=24 <25, so check that before anything else.

node --version
npm install
cp .env.example .env

The copy step matters because .env.example is where every provider is declared. It ships with LLM_PROVIDER=anthropic and a full block per provider, each with a base URL, an API key and a model id. Fill in the key for the provider you actually use and leave the rest empty; the file's own comment says LLM_PROVIDER only controls which provider is initially selected in AI Chat, so a single key is enough to start.

npm run dev

The dev script is not a bare Vite command. Its predev hook runs sync:mediapipe, sync:whisper-cli and verify:server-tool-catalog first, which means the first run downloads the segmentation and transcription binaries and then checks that the generated server tool catalog is in sync with the source. If that check fails, the dev server will not start, and the fix is regenerating the catalog rather than editing it by hand.

npm run generate:server-tool-catalog
npm run verify:server-tool-catalog

After the app opens, create a local project, import media, and give the agent a task in the chat panel. The README's example screenshots describe exactly this: generating music, invoking tools, and writing transitions, captions and multitrack media directly to the timeline. What you should see is new clips and caption entries appearing on tracks you can then drag, trim or delete. If nothing appears on the timeline, the edit did not happen, regardless of what the chat panel says.

There is also a split dev mode. The scripts include dev:isolated and dev:shared, where dev:shared runs Vite directly with config/vite.config.ts and skips the whisper sync step. That is the faster loop if you are only touching front-end code.

Where OpenChatCut will frustrate you

The setup is heavier than the product description suggests. Node 24 is a hard floor and a hard ceiling, the predev hook pulls MediaPipe and a whisper CLI binary, and the tool catalog is generated code that the build verifies. On a fresh machine you are several minutes and a few hundred megabytes away from a running editor, and any failure in those sync steps blocks the app entirely.

Provider configuration is the second trap. The .env.example lists model ids such as claude-fable-5, gpt-5 and gemini-3.5-flash, and it warns that image generation credentials must not use a VITE_ prefix. If you paste a key whose model id does not exist on that endpoint, the failure surfaces as an agent that cannot respond rather than as a validation error at startup. The README does not document rollback behaviour for a partially applied agent edit, so if you are running a long multi-step instruction, save a version first.

Finally, this is the wrong tool if you want a hosted, collaborative, browser-only editor. The README is explicit that projects and media stay on your machine by default, which is the selling point and also the limit: there is no shared team workspace described here, and moving a project between machines means moving the project data yourself. It is equally wrong if you want a single prompt to produce a finished clip with no timeline in front of you.

OpenChatCut against Descript and against one-shot generators

Descript is the closest well-known comparison, and the difference is architectural. Descript's model is a document: you edit the transcript and the video follows, with the timeline as a secondary view. OpenChatCut inverts that. The README describes transcript-driven editing as one capability among many (word-level transcription, text-based cuts, pause handling, speakers, linked captions), but the timeline is the source of truth, and the agent is one of several things that can write to it. If your mental model is "edit the text, the video follows", Descript is a better fit. If your mental model is "the timeline is the artifact and I want an agent to operate it", OpenChatCut is the one that matches.

The other comparison is against one-shot AI video generation. That category wins on speed and loses on everything after the first render: you cannot split a clip, nudge a transition or fix one caption. OpenChatCut's own README table makes this the central claim, and the repository supports it with FCPXML export, which means a finished project can leave for another editor rather than being trapped in this one. That export path is the strongest argument for the project, because it bounds the risk of adopting it.

Licence, maintenance and what an upgrade costs you

OpenChatCut is licensed AGPL-3.0-or-later according to package.json, and the README calls it independent open source under AGPL. The practical consequence for anyone embedding this in a product is the network clause: if you modify it and expose it to users over a network, the AGPL's source-availability expectations apply. That is a real consideration for a hosted offering and not one to settle by reading a blog post. This is a description of the licence text, not legal advice; talk to someone qualified before building a service on it.

Maintenance looks current rather than dormant. The last push was on 2026-08-25, and the release list shows v0.2.11 on 2026-08-25, v0.2.10 on 2026-08-24 and v0.2.9 on 2026-08-20, so the project was shipping frequently in the weeks before that date. The version in package.json is 0.2.14, ahead of the newest listed release, which is normal for a repository whose releases lag its main branch.

The upgrade cost is concentrated in two places. First, the generated server tool catalog: because the build verifies it with verify:server-tool-catalog, a pull that changes agent tools will fail your build until you regenerate. Second, the pinned Node range. A Node 25 machine will not satisfy engines, so an upgrade plan has to include the runtime, not just the package. Neither is unusual for a project of this shape, but both mean upgrades are a deliberate step rather than an npm update you forget about.

Editorial conclusion

Adopt OpenChatCut if you already edit on a timeline and want an agent to do the repetitive parts (captions, cuts, transitions, music placement) while the project stays inspectable and undoable. Skip it if you want a one-click generated clip, if you need a hosted collaborative editor, or if you cannot run Node 24 locally. Before committing, verify three things: that your machine is on Node >=24 <25, that your chosen LLM provider key works with the model id in .env.example, and that a test export produces the MP4 and FCPXML you expect.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes