What OpenCut Is Building—and What It Has Not Built Yet
OpenCut is an open-source video editor project at a consequential boundary: its earlier editor exists as a product line, while the repository now describes a ground-up rewrite. The question here is not whether OpenCut has an attractive list of planned features. It is what the project is actually trying to rebuild, what the current repository demonstrates, and how readers can judge the distance between the two. That distinction gives this series a useful starting point: it lets us understand OpenCut as an architectural transition rather than confuse a roadmap with a finished application.
A project with two timelines
The name OpenCut currently covers two different stages of a product. The repository describes the project as a free, open-source editor for web, desktop, and mobile, but its status section says that the rewrite is being built from the ground up. It points readers to OpenCut Classic for the previous version, says that the existing public site still runs that classic version, and identifies a separate address for the rewrite until it is ready to take over.
That is more than a hosting detail. It changes how every piece of evidence should be read. The classic editor is the source of the published release history: it had a functioning timeline, preview manipulation, properties controls, animation, effects, audio behavior, captions, and export improvements. The rewrite is the current architectural project. It should not inherit those capabilities in our description merely because they appear in release notes kept in the same repository.
The current code makes the separation visible. The web application has a home route that says “hello world!” and an editor route that says “Coming soon.” The desktop documentation warns that the application is very early and currently only opens a window. The API is a small Cloudflare Worker with status, health, and echo endpoints. None of this diminishes the earlier editor; it tells us that the rewrite is not yet a drop-in replacement for it.
The practical implication is important for anyone deciding whether to use, study, or contribute to OpenCut. The classic line is the stated option to reach for today. The rewrite is the place to watch if the project's deeper architectural bet matters to you. Treating them as one implementation would produce the wrong expectations in both directions: it would understate the classic editor's accumulated work and overstate the rewrite's present capability.
The distinction also clarifies why the repository is worth examining even while the rewrite is incomplete. A mature editor's visible features are only the surface of a harder problem: many views and operations must agree about the same scene, the same time, and the same saved state. Rebuilding that foundation can be a meaningful engineering project before the interface looks complete. But the existence of that project is not evidence that the foundation has already been delivered.
The shared foundation is the real proposal
OpenCut's “What's coming” list describes an Editor API, first-class third-party plugins, desktop, mobile, and browser support from one codebase through a Rust core, an MCP server for AI agents, headless mode for automation and batch rendering, and a scripting tab inside the editor. These are easy to read as separate features. The stronger interpretation is that they are tests of one underlying idea: editing behavior should live in a foundation that can be used by a person at a screen, by a native application, or by an automated process without being reimplemented for each surface.
An Editor API would matter only if it exposed real editing concepts rather than a thin collection of UI actions. A plugin system would need stable boundaries around those concepts, or each plugin would become coupled to one screen. Headless rendering would need the same scene, timing, and rendering rules as interactive editing, or a project that looks correct in the editor could produce a different result in batch mode. An AI-facing MCP server and a scripting tab would raise the same question in another form: can an external actor manipulate a project through explicit, dependable semantics instead of simulating mouse clicks?
This is why the shared Rust core is the theme that ties the proposal together. Rust is not the subject by itself, and “cross-platform” is not a sufficient explanation. The architectural question is what crosses the boundary. If the core owns the meaning of a timeline, the structure of a scene, the calculation of frames, and the composition of media, then web, desktop, and automation surfaces can present different controls while relying on the same rules. If those meanings remain trapped inside individual interfaces, a common repository layout will not create genuine portability.
The current workspace shows preparation for that direction. Moon is configured to discover applications and possible crates, and the project pins its Moon, Bun, and Rust tool versions. Separate tasks exist for the web application, the API, and the desktop application. Yet the visible Rust workspace currently includes the desktop app while leaving a crates glob commented out. That configuration is a useful architectural signal, but it is not a working shared core. It tells us where the project is heading and where the present boundary remains.
The stakes are practical rather than ceremonial. Video editing combines visual feedback with temporal precision. A user expects a clip trimmed in the timeline to remain aligned in the preview, an animated property to follow the same clock as playback, and an export to preserve what the editor showed. Once plugins, scripts, or automated rendering enter the picture, those expectations become interface contracts. A shared foundation could reduce contradictory behavior across surfaces; it could also concentrate more responsibility in one difficult subsystem. The benefit is conditional on clear ownership and stable semantics, not on the word “Rust” appearing in a manifest.
Read the repository at its actual maturity
The rewrite already contains evidence of deliberate groundwork. The desktop shell creates browser, preview, inspector, and timeline panels as persistent entities, rather than rebuilding them on every render. It includes a resizable-panel primitive, context-menu behavior, light and dark semantic themes, and a small collection of reusable controls. The web side has a responsive component foundation, a routed application, and Cloudflare deployment configuration. Continuous integration is configured for Linux, Windows, and macOS, and the project is released under the MIT license.
Those foundations matter because they address real constraints. A desktop editor needs a shell that can own state across repeated renders. A browser-facing product needs responsive controls and a deployment path. A multi-target project benefits from pinned tools and repeatable tasks. But each item proves only its own layer. A resizable panel does not prove that a timeline can calculate a legal edit. A route on the rewrite domain does not prove that a project can be imported. A health endpoint does not constitute the promised Editor API. CI configuration shows intended validation breadth, not successful media processing on every operating system.
The release notes show why the missing layers are substantial. In the earlier editor, the properties panel had to reconcile direct manipulation with exact values; selection, trimming, undo, and playback had to remain understandable during ordinary gestures. Later releases added keyframes, effects, masks, speed and volume controls, captions, audio waveforms, and export behavior. Such features do not merely add buttons. They expand the number of representations that must agree: the scene in the preview, the arrangement in the timeline, the values in the inspector, the audio and video clocks, the saved project, and the exported result.
That history gives the rewrite a meaningful engineering target, but not a completed scorecard. The repository does not yet show the promised Editor API, plugin contract, MCP server, headless runner, scripting surface, mobile client, or integrated shared core. It also does not provide independent performance measurements, a compatibility matrix, or evidence that the rewrite has reached the classic editor's feature level. These are not criticisms imported from a generic standard; they are the boundaries created by the project's own current files and stated status.
The rest of this series therefore follows a particular path. It starts with the editor as a coordination problem: what the browser, preview, inspector, and timeline must share. It then examines why time and rendering become correctness boundaries, and how explicit track rules and ripple-editing semantics turn gestures into reliable state changes. Only after those mechanisms are clear does it make sense to assess the web, API, and desktop shells as possible consumers of a shared core.
The opening judgment can remain simple. OpenCut is not merely polishing an existing interface. It is attempting a difficult architectural reset whose success would be measured by whether editing semantics can travel across human, native, and automated surfaces. At the pinned repository state, that reset is visible as a serious direction and a growing scaffold. It is not yet visible as a finished replacement for the classic editor. Keeping those statements together is the most accurate way to understand what OpenCut is building—and what it has not built yet.