The repository is not the product its stars suggest
OpenCut has the irresistible headline of an open-source CapCut alternative. It also has more than 82,000 GitHub stars, an MIT license, and a web editor people can visit. The crucial purchasing fact sits at the top of the README: this repository is being rewritten from the ground up. The maintainers direct anyone who wants to edit today to a separate OpenCut Classic repository, and the public opencut.app site still runs that older version.
That makes OpenCut two evaluations in one. Classic is a usable browser editor with a timeline, captions, keyframes, masks, effects, speed and volume controls, and export. The current main branch is the foundation for a more ambitious replacement. Its stated direction includes a Rust core shared across web, desktop, and mobile, an editor API, third-party plugins, scripting, headless rendering, and an MCP server. Those are aspirations listed under what is coming, not shipped features you should design a workflow around.
The distinction is especially important because the latest release can create the wrong impression. Version 0.3.0 from April 2026 has a substantial feature list and detailed fixes. It describes the earlier editor generation, including a Rust and WebAssembly compositor, masks, keyframe curves, custom canvas sizes, stickers, captions, and improved playback. The current README supersedes that apparent readiness by recommending Classic while the new architecture takes shape.
A promising architecture, still mostly scaffolding
The rewrite has a sensible technical goal. Video editors are difficult to keep consistent across a browser, native desktop shell, and eventual mobile clients. Moving timing and media primitives into Rust could give OpenCut one behavioral core while each surface gets an appropriate interface. The workspace pins Moon, Bun, and Rust versions through proto, which reduces the usual guessing about compatible development tools.
The codebase already separates web, API, and desktop tasks. The web app uses React and Vite, the small API target runs on Cloudflare Workers, and the native app uses GPUI. That is useful evidence of the intended shape, but not evidence of feature parity. The desktop README is admirably blunt: it currently opens a window. Its first build compiles GPUI from source, macOS requires Xcode command-line tools, and Linux needs Vulkan drivers plus Wayland, X11, font, C compiler, and CMake packages. Windows has fewer listed prerequisites, although this is still a developer build rather than an installer for editors.
The project is also not ready for the normal open-source contribution bargain. The README says outside contributions are not set up while the architecture is being designed. You can open an issue or join Discord, but a developer hoping to fix a missing tool and get a patch merged should wait for clearer boundaries. That honesty is good project management; it also lowers the practical value of cloning the repository today.
Classic works, with browser-sized limits
Classic remains the relevant option for creators. Its April release shows unusually capable browser editing: independent scale axes, clip speed with pitch preservation, mask feathering, preview zoom, multi-clip movement, imported transcript captions, editable keyframe curves, and canvas backgrounds. The release also says Firefox MP4 export with audio was fixed and browsers without GPU-accelerated rendering now receive a warning. This is far beyond a toy clip trimmer.
The rough edges are consequential. One open report describes a roughly 50-minute 2K file driving CPU and memory use until an Edge tab crashes. Another reports a 20-second clip consuming RAM until Windows itself is at risk. These are user reports, not controlled benchmarks, but both remain open and have active discussion in August 2026. They make long footage, high resolutions, and low-memory machines poor bets without a trial using the exact source files.
Accessibility is another concrete gap. An open report lists missing ARIA labels on timeline and toolbar controls, no live regions for export or save status, missing pressed states, and no progress or timeline semantics. Keyboard shortcuts alone do not solve that. A team buying for education, government, or an inclusive creator product should audit the interface rather than infer accessibility from its browser delivery.
Health is strong, readiness is not
The last repository push was August 10, 2026. Open issues were also being discussed in August, including performance, accessibility, and browser behavior. GitHub's total of 366 combines issues and pull requests; a separate issue search returned 263 open issues. That is a substantial queue, but recent code and discussion show an active project, not an abandoned one.
Community interest is plainly strong, and the maintainers have made the hard status message prominent. Documentation is thinner for the rewrite because many user-facing systems do not exist yet, but the setup commands, pinned tools, platform prerequisites, and contribution boundary are clear. The MIT license is friendly for experimentation and future integration.
OpenCut is worth watching because an open editor with a shared native core, a real plugin model, and automation hooks would fill a genuine gap. It is not worth pretending the gap has already been filled. For dependable work today, use Kdenlive or Shotcut. Use Classic for lighter browser jobs only after testing memory use, export, and accessibility against your needs. Clone the rewrite if you want to observe its architecture, not because you expect a finished CapCut replacement after the dev server starts.