OpenCut's main branch is a rewrite, and the editor you can use today is in another repository

The editor you can use today is in opencut-classic, not in this branch

The Status section leads with a single sentence that changes how everything else in the repository should be read: OpenCut is being rewritten from the ground up.

The working version was moved out. It lives at opencut-app/opencut-classic, and that is the repository to reach for. The hosted app at opencut.app still runs the classic version, while the rewrite is served from new.opencut.app until it is ready to take over.

That split is the practical fact about this project. A reader who installs from main expecting the editor described in the project description, a browser-based video editor with a multitrack timeline, media import, previews and export tools, will find scaffolding instead. The description describes the product. The branch holds the work toward the next one.

Six capabilities are promised and none of them has an interface yet

The rewrite lists what is coming: an Editor API, first-class third party plugins made possible by a plugin-first architecture, desktop, mobile and browser from one codebase with a Rust core, an MCP server for AI agents, a headless mode for automation and batch rendering, and a scripting tab directly in the editor.

None of the six has a published interface in this tree. There is no API surface to code against, no plugin manifest format, no MCP server to connect an agent to, and no headless flag to pass on a command line. They are intentions, and the order they are written in does not say which lands first.

For an evaluator, the plugin-first architecture is the item worth watching, because it is the one that constrains everything else. A plugin API has to be designed before the editor code that plugins will extend is finished, which is why the rewrite is starting over rather than refactoring what exists.

The Cargo workspace builds one member and has crates/* switched off

The Rust side is small and unfinished. The workspace declares a single member, apps/desktop, with the line for crates/* present but commented out:

[workspace]
resolver = "3"
members = [
  'apps/desktop',
  # 'crates/*',
]

Shared settings follow: version 0.1.0, edition 2024, license MIT, and one workspace dependency, gpui at 0.2.2.

The commented-out crates directory is the detail that matters. It is a wildcard over the shared library crates, switched off while the structure is being decided, which means a build here compiles the desktop shell and nothing else. There is no shared core to depend on yet, even though the Rust core for all three platforms is the stated goal.

The version number tells a second story. The workspace says 0.1.0 while the newest application release tag is v0.3.0, so the Cargo version is not tracking the releases the project has been publishing.

proto installs the tools, moon runs three dev servers on fixed ports

Development goes through proto for tool installation and moon for running tasks. proto itself has to be installed first, with one command per platform:

bash <(curl -fsSL https://moonrepo.dev/install/proto.sh)

irm https://moonrepo.dev/install/proto.ps1 | iex

From the repository root, proto use installs whatever the .prototools file pins, and three tasks come up:

moon run web:dev       # localhost:5173
moon run api:dev       # localhost:8787
moon run desktop:dev   # see apps/desktop/README.md

Two of the three are pinned to a port, 5173 for the web app and 8787 for the API, so a second checkout on the same machine collides. The desktop task has no port and no inline detail, and points at a README inside the app directory instead. The root also carries a moon.yml and a .moon directory, which is where the task definitions live.

On Windows the shims stay silent until the execution policy is changed

proto works by putting shims on the path, and on Windows those shims are scripts. The repository calls out the failure directly: if shims fail to run, allow local scripts for your user.

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

The scope is the part that matters. CurrentUser changes the policy for one account and no machine-wide setting, so it does not need an administrator, and it does not touch other users on the same box.

The symptom this prevents is a confusing one. Without the change, the install appears to succeed and the subsequent command fails, which reads as a broken toolchain rather than a policy setting. Anyone setting this up on a locked-down Windows machine should expect that part of it to be refused, and the repository gives no alternative path for that case.

The newest release tag is an FFmpeg build, not an OpenCut build

Release history explains why the version numbers look inconsistent. The three most recent tags are ffmpeg-8.1.3-1 on 24 September 2026, v0.3.0 on 15 April 2026, and v0.2.0 on 2 March 2026.

The most recent one is not an application release. It is an FFmpeg 8.1.3 build, tagged in this repository, and it shares its timestamp with the last push to main. A reader checking what is current will land on it and find a media library rather than an editor.

So the newest shipped editor is v0.3.0 from April 2026, and the last push is from 24 September 2026. Between those two dates the work has gone into the rewrite rather than into a release, and the release list gives no signal of that beyond the FFmpeg tag appearing on top.

Outside contributions are closed, and one env var hints at where storage lands

The Contributing section is unusually direct. The project says it is not set up to take outside contributions yet while the architecture is being designed, and points to the Discord or an issue tracker instead. An architecture that has not settled is a reasonable reason, and the practical effect is that a pull request opened now has no stated path to review.

What the tree does reveal is small. An .env.example file at the root contains a single variable:

R2_BUCKET=opencut-assets

That is the whole environment surface, and it points at a bucket name for asset storage. With one variable and no application service configured behind it, the storage layer is being designed rather than wired up, which is consistent with everything else on this branch.

Editorial conclusion

Use opencut-classic for anything you need to finish this week, and treat main as something to read rather than something to run. Reach for the rewrite only if you want a Rust core, a plugin architecture and headless rendering early enough to shape them, and only if you can tolerate a workspace where the crate directory is still commented out. Before you build anything from this tree, check whether your editor is pointed at opencut.app or new.opencut.app, because those two serve different code and picking the wrong one wastes an afternoon.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes