OpenCut Rewrite: A Browser Video Editor Rebuilt Around a Plugin API and Rust Core
OpenCut is a browser-based video editor with a multitrack timeline, media import, previews, and export tools.
At a glance
- What is it?
- OpenCut is a browser-based video editor with a multitrack timeline, but the current repository is a ground-up rewrite. This article examines what the rewrite promises, how to run it today, and why you should wait before adopting it.
- Who is it for?
- Adopt OpenCut if you are a developer who wants to experiment with a plugin-first video editor architecture and can tolerate pre-alpha instability. Do not use it for production editing or as a dependency yet.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 36 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenCut Is and What the Rewrite Changes
OpenCut is a free, open source video editor that runs in the browser. The current repository, OpenCut-app/OpenCut, is not the version you should use today. The README states plainly that the project is being rewritten from the ground up. The previous version lives in a separate repository, opencut-app/opencut-classic, and that is what runs on opencut.app. The rewrite will eventually replace it, but not yet. The rewrite introduces an Editor API, first-class third-party plugins, and a Rust core that targets desktop, mobile, and browser from one codebase. That is a significant architectural shift from a typical browser-only editor. The target audience is not end users looking for a finished editor. It is developers who want to build plugins or automate video editing, and who are willing to follow a project that is still in design.
The Plugin-First Architecture and Its Implications
The rewrite is built around a plugin-first architecture. That means plugins are not an afterthought; they are the reason for the architecture. The README lists first-class third-party plugins as a core feature, made possible by this design. It also mentions an Editor API, which would expose editing operations to plugins. The practical implication is that the core editor is likely a thin shell, and most functionality will come from plugins. That is a different model from classic video editors where the timeline, effects, and export are monolithic. For developers, this could mean you can extend the editor without forking the entire codebase. But it also means the core must be stable and the API well-designed before anything else works. The README does not provide details on the API surface, so the actual plugin contract is still unknown. That is a risk if you plan to build on it.
Rust Core, Headless Mode, and MCP Server
The rewrite targets desktop, mobile, and browser from one codebase, with a Rust core. That is a bold claim. Rust is known for performance and memory safety, which matters for video processing. The README also mentions a headless mode for automation and batch rendering, and an MCP server for AI agents. An MCP server, or Model Context Protocol server, would let AI agents interact with the editor programmatically. Headless mode means you could run rendering jobs without a UI, which is useful for server-side processing. These features point to a tool that is not just for humans clicking a timeline. It is for automation pipelines. But none of these are implemented yet, at least not in the current repository. The README describes them as what is coming, not what exists. So treat them as roadmap items, not capabilities you can use today.
How to Run the Current Development Build
The README gives specific commands to run the rewrite in development. You need to install proto, a version manager from moonrepo. On Linux, macOS, or WSL, run the curl command shown in the README. On Windows PowerShell, use the irm command. Then from the repo root, run `proto use` to install the tools pinned in `.prototools`. After that, you start the web app with `moon run web:dev`, which serves on localhost:5173. The API runs with `moon run api:dev` on localhost:8787. There is also a desktop app, but the README points to `apps/desktop/README.md` for instructions. These commands assume you are comfortable with the moon toolchain and proto. If you are not, there is a learning curve. The README also notes that if shims fail to run, you may need to set the PowerShell execution policy to RemoteSigned for your user. That is a concrete setup detail.
Current Limitations and Why You Should Not Use It in Production
The most obvious limitation is that the rewrite is not finished. The README says it is being rewritten from the ground up, and the status section lists features that are coming, not features that exist. There is no mention of a working timeline, media import, or export in the rewrite. The classic version has those, but this repository does not. The README also states that the project is not set up to take outside contributions yet while the architecture is being designed. That means the codebase is in flux, and any code you write against it could break without notice. The last push was April 2026, and the latest release is v0.3.0, but release numbers do not indicate maturity. If you need a reliable browser video editor today, the wrong tool is this rewrite. The right tool is the classic version, which is stable enough to run on opencut.app.
Comparing OpenCut to the Classic Version and Other Approaches
The alternative to the rewrite is the classic version, opencut-app/opencut-classic. That is the one that runs on opencut.app and has the features users expect. The difference in approach is that the classic version is likely a traditional browser editor, while the rewrite is a plugin-first, Rust-core architecture. If you want a video editor that works now, the classic version is the real choice. Another alternative is to use a different browser-based editor like the one from the web platform, but that is not open source. The README does not mention any competitors, so I cannot name one specifically. But the key difference is that the rewrite aims for extensibility and automation, while the classic version focuses on direct editing. If you need batch rendering or AI agent integration, the rewrite is the direction to watch, but it is not ready.
Maintenance and Upgrade Cost, License, and Contribution Status
The license is MIT, which is permissive. You can use, modify, and distribute the code, but the README does not include a warranty disclaimer, so you should check the LICENSE file for details. The maintenance cost is currently low because the project is not accepting outside contributions. The README says they are not set up for that yet. That means you cannot rely on a community to fix issues. You would be on your own if you fork it. The upgrade cost is high because the architecture is still being designed. Any plugin you write now could become obsolete. The README mentions that opencut.app still runs the classic version, and the rewrite will live at new.opencut.app until it is ready. That suggests the rewrite is not even deployed publicly yet. So the maintenance cost of adopting this now is that you are tracking a moving target with no support guarantees.
Editorial conclusion
Adopt OpenCut if you are a developer who wants to experiment with a plugin-first video editor architecture and can tolerate pre-alpha instability. Do not use it for production editing or as a dependency yet. Verify first that the classic version at opencut-classic meets your needs, and check the rewrite's GitHub issues for current blockers before investing time. The rewrite is not ready for outside contributions, so treat it as a preview, not a tool.
Community notes