OpenChatCut

An open-source, local-first video editor whose editing surface is a chat. An agent reads the project and changes it through the same command layer the interface uses, so every edit lands on a professional multi-track timeline as a clip, transition, caption, effect or audio item that stays draggable, undoable, versioned and exportable. The built-in agent runs on API keys you supply, or on a ChatGPT, Claude, Copilot or Grok subscription through that vendor’s own command-line tool; external Codex, Claude Code, Qoder and Qwen Work clients reach the same tools over a local Streamable HTTP MCP endpoint, through draft sessions that are reviewed before they touch the live timeline. Projects, chat history, versions and media live in a store under the user data directory, with an optional Cloudflare R2 bucket for cloud-only media. Preview and headless render both run through Remotion, FFmpeg and a WebGL effect pipeline sit behind export, and local H.264 encoding prefers VideoToolbox on macOS and NVENC on Windows before falling back to software. TypeScript, React, Electron, AGPL.

Who built itWritten almost entirely by one account: 827 of the repository’s 1,029 commits, with the second-largest contributor at 73 and twenty-four more people carrying a handful each. 103 commits carry a co-author trailer, and the largest group among them — forty-five — names Claude Opus 5.5; Cursor and Copilot appear seven times each.

1. 01

   Ten weeks, a thousand commits and twenty-six versions

   The repository was created on 2026-07-15 and its first commit is dated 2026-07-20; the thousand-and-twenty-ninth arrives on 2026-09-30. 1,029 commits, 676 of them in August alone and 229 in September, against 124 in the ten days of July that were left. The bilingual changelog documents twenty-six versions, from 0.1.0 on 2026-07-20 to 0.2.15 on 2026-09-28, and the published release list shows twenty of them, v0.1.6 through v0.2.15, including five in the three days around 2026-08-17. It is a large program for ten weeks: 2,772 files across 156 directories, about 119 MB, of which 640 files are named after checks rather than features. Around it sit 2,061 stars, 314 forks, eight watchers and sixteen open issues. Twenty-six contributors are listed, and although 1,016 of the commits resolve to a linked account, the shape is still one person: 827 commits from the owner, 73 from the next contributor, twenty-four others with a handful each. 103 commits carry a co-author trailer, the largest group of forty-five naming Claude Opus 5.5, with Cursor and Copilot seven each.

2. 02

   The render path: two engines shipped, and the bill for that

   Export is where the hard choices were made, and they were made by shipping both sides. Version 0.1.2 added WebCodecs-accelerated browser export with progress and cancellation that falls back automatically to the server renderer, plus hardware-aware local H.264 that probes FFmpeg for VideoToolbox on macOS and NVENC on Windows and falls back to software. The same release made Remotion concurrency aware of CPU and memory, queued heavy exports globally, and normalized variable-frame-rate media before playback. On Windows the local renderer now decodes with Remotion’s FFmpeg compositor instead of Chrome’s WebCodecs, whose D3D11 hardware decoder could stop producing frames without an error and leave an export at about 10% until it timed out; macOS and Linux keep theirs, and CC_RENDER_VIDEO_DECODER=webcodecs|offthread picks one by hand. GLSL transitions exported frames from several frames earlier, because each input was drawn before its video had finished seeking; both now come from the export’s own decoder. Browser fast export had inherited Remotion’s thirty-second per-frame default while the local renderer allowed far more, so one project could fail on one engine and render on the other; both now share a ten-minute per-frame budget. Automatic 4K hardware bitrate was capped at 30 Mbps while the dialog promised 60, and now resolves to 40 Mbps at 4K30 and 60 at 4K60.

3. 03

   Timeline geometry as one pass, and a format that refuses to strand older builds

   The timeline is the other place where the architecture had to be decided rather than grown. Version 0.1.8 unified it around playback-rate-aware source-time and source-window helpers, with one transition-reconciliation pass shared by move, retime, split, trim, ripple and overwrite, which is why the same release could add slip and rate-stretch modes, insert and overwrite placement, nested sequences, source timecode and sync-lock groups together. Version 0.2.0 added content-addressed media identity, a streaming SHA-256 carried through the browser, multipart, agent and desktop import paths, and deliberately kept the new metadata inside the public v3 project schema so that v0.1.9 can still read projects saved by a newer build. The code keeps that promise the other way too: version history, export history, templates and the job registry preserve records the running build cannot parse instead of dropping them on the next write, a project this build could not read is no longer overwritten by the next save, and media referenced only by a snapshot in a newer format is protected from cleanup. The defects are the same story read backwards: slip editing resolved a source duration by URL even when the clip carried an explicit asset id, so with two pool entries at one URL a 600-frame source was clamped using the first 300-frame entry and an in-point of 540 came out as 240.

4. 04

   Moving the agent loop to the server, and what the editor kept

   Version 0.2.1 made server-side execution of the agent loop opt-in; version 0.2.2, published the same day, made it the only path and removed the browser-side model loop, with chat, drafts, settlements and proposals persisted server-side through a single-writer ledger that survives page refreshes and local service restarts. That is a split-authority problem by construction, and the code answers it by refusing to hand the server the timeline: the server owns the model loop, the editor still executes every change through the same validated, undoable EditorCore commands a human edit uses, and external MCP sessions are bound to project and editor revisions so a stale draft cannot win. The same release removed the cap on tool turns and let the model decide when it is done, protecting long runs with retries on transient provider errors, parallel execution of read-only tools behind an exclusive barrier for mutating ones, pressure-driven context compaction, recovery closers for interrupted tool calls and a rolling event window. Issue #186 shows what a fixed ceiling costs: a long turn accumulated exactly 100 accepted tool requests, 84 allowed and 16 denied, and died with a misleading HTTP 404 instead of a limit message; the fix removed the cap and lifted two further ceilings a long turn would have reached next.

5. 05

   The issue tracker used as a development diary

   The tracker reads like a log because the maintainer answers in it. One reporter running the Linux source deployment filed six numbered issues on 2026-09-28: a locked onnxruntime-node CUDA postinstall that breaks npm ci, a blank editor over plain HTTP with crypto.randomUUID is not a function, a media-pool duration that changes with the active sequence frame rate, local media browsing that is desktop-only, and the tool-call ceiling. The replies name the cause and the fix status: the 404 one was answered the next day, because the store-level reproduction made it quick to pin down; the browsing one was kept open, with the reason stated, that enabling it for the web editor needs an explicit server-root allowlist since an empty AGENT_IMPORT_ROOTS means unrestricted access, and that it is not in v0.2.15. A newcomer whose provider streamed an empty tool-call type got a fix on main the same day, derived from the pasted response body, with the issue left open until the release ships. Beyond bug reports, contributors brought integrations: GitHub Copilot and Claude Code as agent backends, Requesty, OFox and Fal.ai as providers, three montage workflows, and one-click MCP setup for Qoder. One provider pull request was declined for a commercial reason: adding a vendor gateway as a built-in preset is a business placement, and those are handled as partnerships.

6. 06

   What the author wrote down about what did not work

   The reason this repository is worth reading is how much of the failure is on the record. The continuous integration file carries its own history in a comment: pull requests were not covered until 2026-08-31, and it showed, because a pull request sat open failing the build with nothing to tell its author — so the comment now says that a pull request which cannot build must say so on the pull request. A later pull request body admits that the full local build was blocked during native Whisper preparation by the local compiler and SDK combination, and defers the complete build to CI. A benchmarking pull request reports that four workers rendered two short 4K60 tests about 26–28% faster than the warm automatic thirteen-worker baseline on a 16-core M4 Max, changes no runtime default, and states plainly that further testing is needed on longer timelines, more complex compositions and other Macs before an automatic policy change could be recommended. The 0.2.13 notes record a Windows-only crash that escaped testing precisely because the recovery was gated to Windows, where it had been written; the 0.2.12 notes say that Windows local transcription had never actually run, because packaging had moved the executable away from its libraries, so every model tier died on a bare exit code.