OpenCut is building the editor after CapCut.
A deep dive into the ground-up rewrite: what’s real today, what the architecture is aiming for, and how to get the repository running.
OpenCut wants to be a cross-surface, extensible video editor.
One editor, many surfaces
The rewrite is organised around a Rust core that can support browser, desktop and mobile experiences from one codebase.
Automate the boring parts
The README points towards an Editor API, headless mode, scripting, and an MCP server for AI agents.
Still early
The checked-out rewrite has a minimal web app, a tiny API, and an early GPUI desktop shell. The classic version is the usable product today.
Open source changes the control surface of editing.
Own the workflow
For teams, a programmable editor can be shaped around brand rules, review loops, asset stores and delivery targets.
Compose instead of copy
A plugin-first architecture creates a place for integrations: effects, importers, generators, automations and internal tools.
Make agents useful
An MCP server and scripting surface could let an agent inspect, edit, render and hand work back into a human editor.
Reduce platform lock-in
MIT licensing and self-hostable building blocks make the project easier to study, fork and adapt, subject to the repository’s maturity.
Where this could become more than a video editor.
Short-form repurposing
Import a long recording, cut a set of vertical clips, apply a brand template and export a review pack.
Best fit: scripting + headless rendering, once available.
Branded content ops
Build an internal panel that assembles approved footage, copy, captions and product shots into repeatable edits.
Best fit: Editor API + plugins, as proposed by the README.
Human-in-the-loop agents
Let an agent propose edits, explain its choices and hand a structured project back to a person for review.
Best fit: MCP server + visible editor state.
These are design opportunities inferred from the planned architecture. They are not evidence that the rewrite already supports these workflows.
Deep dive: read the repo as a product architecture.
The most useful signal is not the number of folders. It’s the boundary between what is implemented, what is scaffolded, and what is promised.
The current rewrite is scaffolding, not a finished editor.
Shell present
The home route renders “hello world!” and the editor route says “Coming soon.” The app is wired with TanStack Start/Router and Vite.
Minimal service
The Cloudflare Worker exposes a status route, a health route and a typed echo endpoint through Elysia.
Window + panels
The GPUI app opens an OpenCut window with browser, preview, inspector and timeline entities. Its own README calls it “Very early”.
OpenCut is interesting because the seams are being designed early. It is not yet a drop-in replacement for a mature editor.
Four layers, one development loop.
shared product direction
across client surfaces
The important architectural bet is cross-surface consistency: the product can evolve as a system instead of three unrelated editors.
Each surface already tells us how to think about the product.
Fast distribution
TanStack Start and Cloudflare tooling point towards a web-first experience that can be deployed without asking users to install a native app.
- quick iteration
- shareable entry point
- edge-hosting path
Native control
GPUI gives the rewrite a Rust-native shell and a route to high-performance interaction on the desktop.
- native window
- Rust ownership model
- platform-specific runtime
Automation boundary
The API is tiny today, but a separate service boundary creates a natural home for project, render and agent operations later.
- typed request boundary
- health endpoint
- Cloudflare Worker shape
The rewrite is aiming for composability, not only features.
Editor API
A stable surface for manipulating projects and editor state from tools, plugins or other applications.
Third-party plugins
Extensions are meant to be first-class, enabled by a plugin-first architecture.
MCP server
A bridge for AI agents to work with the editor through structured tools and context.
Headless + scripting
Automation and a scripting tab would let repeatable editing workflows run with less manual clicking.
The product’s long-term advantage could come from a shared project model and clear capability boundaries. That is an architectural opportunity, not yet a validated product outcome.
OpenCut’s promise depends on hard problems it hasn’t solved yet.
Cross-platform parity
One codebase reduces divergence, but browser, desktop and mobile still have different media, GPU and filesystem constraints.
Plugin trust
Plugins increase capability and risk. Permissions, sandboxing, versioning and review become product features.
Agent reliability
MCP access is only useful if edits are observable, reversible, grounded in project state and safe to render.
Media performance
Editing workloads are dominated by decoding, compositing, audio timing, GPU acceleration and export correctness.
The repository gives evidence of the intended direction. It does not yet establish production performance, feature parity or ecosystem adoption.
How to implement: from clone to contribution.
The current implementation path is a workspace setup and inspection loop. Feature development comes after you understand which surface owns the behaviour.
Install the tools the repo expects.
Workspace toolchain
Desktop dependencies
Web development is the easiest starting point. Desktop builds use GPUI and may require platform graphics packages, especially on Linux.
The desktop README lists macOS, Windows, Linux and WSL2/WSLg requirements.
Start with the surface you want to learn.
Browser shell
Use this to inspect routing, UI composition and the future editor entry point.
Worker service
Use this to inspect the typed service boundary and Cloudflare runtime shape.
Native shell
Use this to inspect the GPUI window and panel entities. Expect early scaffolding.
Get the repository and enter its root.
Run proto so local tools match the workspace.
Start one surface and verify its baseline.
Follow the route from UI to API or native shell.
Pick an ownership boundary before writing code.
Start in web
Define the user interaction in the web route or component tree. Keep state close to the surface until a shared model exists.
Start in API
Add a typed Elysia route, then decide how the web or desktop surface calls it. Keep health and failure states visible.
Start in desktop
Use the existing GPUI panel entities and preserve state ownership. The desktop README warns that this surface is very early.
For plugins, MCP or headless rendering, first define the project representation, permissions, undo/redo semantics and validation hooks. The README names these directions, but the current checked-out tree does not yet expose their implementation.
Make “it runs” a small part of done.
Know the project’s current invitation
The README says outside contributions aren’t set up yet while the architecture is being designed. That means the best immediate contribution may be discussion, issue reports, experiments or following the Discord rather than assuming a normal PR flow.
OpenCut is a bet on the editor as a platform.
What’s compelling
- open source and MIT licensed
- multi-surface direction
- plugin, API and automation ambition
- AI-agent integration is part of the plan
What to remember
- the rewrite is still early
- classic is the usable version today
- planned does not mean shipped
- architecture is the current product story
Clone it, run the web shell, read the API and desktop boundaries, then decide whether your interest is creator UX, native media performance, platform architecture or agentic editing.