OpenChatCut
Open-source AI agent video editor with a real timeline
170 followers
Open-source AI agent video editor with a real timeline
170 followers
OpenChatCut is an open-source ChatCut alternative: local-first AI video editing where Codex, Claude, and MCP agents work on a real multitrack timeline. Free, editable exports, AGPL.
Free
Launch Team / Built With
CloudflareStill paying to deploy your apps? Try Cloudflare Workers for free
Promoted
@0xsline This is timely I was just wrestling with AI video tools that paywall you after a couple of clips, so a local-first open-source option is exactly what I needed. Love that it plugs into Claude Code via MCP. Curious how the agent handles multi-clip edits right now stitching a screen recording + b-roll + captions? Excited to try it. Congrats on the launch 🚀
@nishant_06 Thanks Nishant! Yes, that workflow is supported: import the screen recording and B-roll, then ask the agent to arrange and trim them on the multitrack timeline and generate captions. The edits are proposed for review before they’re applied, so you still have full control. Would love your feedback after you try it!
The part I'd poke at is how the agent addresses clips through MCP. Every time we've handed an agent a stateful document as tools, state drift is the thing that bites: it reasons over a snapshot it read a couple calls back, so 'trim the third clip to 5s' hits the wrong clip once the timeline moved underneath it. Are the edits keyed to stable clip IDs it can re-reference, or to positions and timecodes that shift when tracks change?
@dipankar_sarkar Great question. Timeline edits are keyed to stable itemId, trackId, and timelineId values rather than ordinal positions like “the third clip.” read_timeline returns the current live state, and every MCP tool call is executed against the editor’s latest context. If an item has disappeared, the ID lookup fails instead of silently editing whichever clip moved into that position.
The in-app proposal flow also records the base project snapshot and detects staleness before applying. One limitation today is that external MCP calls do not yet carry an explicit expected-revision token, so an agent should re-read the timeline after structural edits.
The 'edits proposed for review before applied' loop on a real timeline is what makes this feel usable rather than a black box. When an external agent works over MCP (say Claude Code), does it get the full timeline state as context each turn or just a diff of the current edit, and where do those proposed-but-unaccepted edits live — in the project file on disk I could version in git, or app-internal state until I accept? I'm trying to gauge whether the whole editing history stays reproducible outside the app.
@noctis06 Important distinction: MCP does not automatically push either the full timeline or a diff into the external agent’s context. The agent can call read_timeline to obtain the full current state, and subsequent tools operate against the live editor.
The propose → preview → apply loop currently belongs to the built-in agent. It runs timeline edits on a scratch project document, lets you preview and selectively accept them, detects stale proposals, and stores an unaccepted proposal in project-scoped local shared storage so it survives a refresh.
External MCP edits currently bypass that proposal store and apply directly. The .ccproj.json export contains the project document, media, chat, and creative mode, but not the full operation log, pending proposals, or named-version history—so complete Git-reproducible editing history is not implemented yet.
open-sourcing an actual multitrack timeline for agent-driven editing (not just a chat wrapper around ffmpeg) is a solid contribution, and AGPL is the right call for something like this. one thing I'm curious about - when Claude or Codex makes an edit through MCP, does it operate on a separate draft track/version so you can diff or roll back a bad cut, or does it modify the working timeline directly?
@omri_ben_shoham1 Thanks! At the moment, Claude or Codex edits made through MCP modify the working timeline directly rather than an isolated draft branch. They still go through the same EditorCommands path, so normal undo/redo works, and you can save and restore named project snapshots.
The built-in agent has the safer draft workflow: edits are first replayed onto a scratch document, previewed without changing the committed timeline, checked for stale state, and then selectively applied as one undoable change. A separate per-session draft/version layer for external MCP agents is not implemented yet.
been wanting a real open source editor like this for a while, the local first angle is huge honestly. one thing that would make me actually switch though is proper proxy generation for 4k footage, my laptop struggles with raw timeline scrubbing and most editors punt on this
@anlcengi7zjn Thanks, Anıl — totally agree. Proper 4K proxy generation is high on our list. A local-first editor should make high-resolution footage smooth to work with, not force users to scrub raw files. We’re exploring automatic proxy generation with flexible resolution and codec options.
Love that the timeline stays multitrack and editable on export, not flattened into a render. Hooking Codex and Claude into real video editing through MCP feels like the first time agents can touch a timeline without breaking it.
@takbug32958 Really appreciate that! Keeping the timeline multitrack and editable through export is one of our core principles. The Codex/Claude + MCP workflow is designed to let agents make structured timeline edits without flattening everything into a render.
Love the open-source approach and the multi-agent timeline idea. One thing that would help adoption a lot is adding a simple share/export-to-web preset that bakes the project into a viewable link, so non-technical folks can preview cuts without installing anything. That alone would make sharing work-in-progress much easier.
@yeimoyranshdr Great suggestion, Yeşim. A simple share-to-web workflow would make reviewing work-in-progress much easier, especially for non-technical collaborators. We’re definitely exploring this direction.