Most "open-source CapCut alternative" projects stall at a rough timeline and a few clip trims. OpenCut got far enough to become one of the most-starred open-source video editors on GitHub — and is now in the middle of throwing out its own rendering engine and rebuilding it in Rust. That's an unusual point in a project's life to look at closely, and it's worth being precise about what that actually means for anyone evaluating it today.
The Repo You're Looking At Is a Rewrite, Not the Shipped Product
This is the detail to get straight before anything else, because the README says it plainly and it changes what you should expect from a checkout: OpenCut is being rewritten from the ground up. The version people actually use today — the one running live at opencut.app — lives in a separate, frozen repository, opencut-app/opencut-classic. The repo most people link to and star, OpenCut-app/OpenCut, is the in-progress rewrite, targeted to eventually replace the classic version at new.opencut.app. The project isn't currently accepting outside contributions while the new architecture is being designed, and the desktop app skeleton in apps/desktop/ is explicitly described as having "no features yet." If you clone the headline repo expecting the polished editor from the demo videos, you'll find an architecture in progress instead — the working product is one repo over.
What the Rewrite Is Actually Solving
The stated goals aren't cosmetic: an Editor API, first-class third-party plugins, one Rust core shared across desktop, mobile, and browser, an MCP server for AI agents, headless/automation rendering, and an in-editor scripting tab. That's a meaningfully bigger ambition than "open-source CapCut" — it's building toward a programmable editing platform, not just a free timeline UI.
The Technical Details in the Release Notes Are Genuinely Substantive
The latest release notes go well past a typical changelog, and the "Technical details" section is worth reading directly if you care about how a browser video editor actually gets built:
- A Rust/wgpu compositor replaces the old WebGL renderer entirely, compiled to WASM and consumed from TypeScript. Compositing, effects, and masks (with JFA-based feathering) each live in their own Rust crate under
rust/crates/. - Time is now an integer tick count, not a float.
MediaTimeruns at 120,000 ticks per second specifically because that number divides evenly by every standard frame-rate denominator, including drop-frame rates like 23.976 and 29.97 — replacing floating-point seconds that accumulated rounding errors and broke frame-accurate alignment. - Track ordering is enforced at the type level.
SceneTracksreplaces a flat track array with explicitoverlay,main, andaudiofields, making it structurally impossible to mix track kinds or misplace a track — a type-system fix for a whole class of editor bugs, not a runtime check. - Ripple editing was rebuilt as a diff-based system: track snapshots are compared as interval sets before and after an operation, with the resulting adjustments computed and applied as a separate, testable pass instead of inline mutation.
That's the kind of engineering that shows up in mature desktop NLEs (non-linear editors), not typical browser demo projects — a meaningful signal about where this project is trying to end up.
The Latest Release Shows the Rewrite Isn't Starting From Zero
It's easy to read "in-progress rewrite" as "not much works yet," but the most recent release tells a more specific story: alongside the Rust/wgpu compositor work, it shipped a genuinely large batch of editing features on the new architecture — masks (split, rectangle, ellipse, star, heart, diamond, and cinematic-bar shapes, with position, size, rotation, feather, and stroke controls adjustable either in the properties panel or by dragging handles in the preview), a graph editor for shaping keyframe easing with draggable bezier handles, independent width/height scale controls, volume and speed controls with a maintain-pitch option so sped-up audio doesn't chipmunk, preview zoom and panning, custom canvas sizing beyond the old preset list, canvas backgrounds (blur, solid color, or gradient), and a stickers panel stocked with logos, flags, and shapes. Playback performance was also overhauled — the release notes describe the editor previously slowing to a crawl during playback with audio stuttering on interaction, both now fixed — and the editor now detects browsers without GPU-accelerated rendering support and shows an explanatory notice rather than failing silently. Sixteen new storage-migration steps (v9 through v25) shipped in the same cycle, which tracks with how much schema surface changed underneath those features. None of that makes the rewrite feature-complete, but it's a meaningfully further-along editor than "early architecture reset" alone would suggest.
The Development Setup Reflects the Rewrite's Ambitions
Getting the rewrite running locally isn't a plain npm install — it uses proto, moonrepo's polyglot toolchain manager, to pin and install the exact tool versions the project needs, installed via a shell script on Linux/macOS/WSL or a PowerShell script on Windows. From the repo root, proto use installs everything pinned in .prototools, and moon (moonrepo's task runner) drives the actual dev servers: moon run web:dev for the web app on localhost:5173, moon run api:dev for the API on localhost:8787, and moon run desktop:dev for the early desktop skeleton. That's the same category of tooling mature monorepo projects reach for once a codebase spans a web app, an API, a Rust core, and a desktop shell that all need to build and version together — a heavier setup than the classic repo, but a reasonable one given what the rewrite is trying to unify. The web app can also deploy to Cloudflare Workers via OpenNext, with wrangler.jsonc and an open-next.config.ts included in the repo for anyone who wants to self-host their own instance rather than depend on new.opencut.app.
The Scale Is Real, and So Is the Backing
At over 82,000 stars with a real sponsor (fal.ai) and an active Discord, this isn't a speculative side project — it's a widely-used tool going through a deliberate architectural reset while its predecessor keeps running in production. That combination (large existing user base, frozen classic version still live, ambitious rewrite in progress) is a specific and fairly rare situation to evaluate correctly.
Practical Implications
- For actually editing video today, use the classic repo or opencut.app, not the rewrite branch — the rewrite isn't feature-complete and isn't the version driving the live site yet.
- If you're interested in the architecture rather than the product, the rewrite repo is the more interesting one to read — the Rust/WASM compositor and frame-accurate time system are well-documented, unusually deep engineering decisions for a browser editor.
- Don't attempt to contribute code yet. The project has said directly that it isn't set up to accept outside contributions while the new architecture is being designed — following along in Discord or via issues is the current path, not pull requests.
- The planned MCP server and headless mode are worth watching if you're building AI-driven creative tooling — a scriptable, agent-addressable video editor is a different product category than a manual timeline tool.
Practical Takeaway
OpenCut is a large, real, well-funded open-source project mid-transition: a widely used browser editor keeping its classic version live while a new team rebuilds the core in Rust toward a more ambitious, plugin-and-agent-friendly architecture. The technical decisions documented in the rewrite — integer tick-based time, type-enforced track structure, a real GPU compositor — are the kind of choices that determine whether a video editor stays reliable as it grows features, and they're worth studying regardless of which version you actually use day to day.
Teams evaluating open-source creative tooling, or building automation and AI agents around video editing workflows, can get hands-on architecture help from Woyce Technologies.
FAQ
What is OpenCut?
OpenCut is an open-source, browser-based video editor positioned as a free alternative to CapCut. The OpenCut-app/OpenCut repository currently holds an in-progress ground-up rewrite of the editor onto a Rust/WASM core.
Is the GitHub repo the same as what runs on opencut.app?
No. opencut.app currently runs the "classic" version, maintained in the separate opencut-app/opencut-classic repository. The main OpenCut-app/OpenCut repo is the rewrite, intended to eventually replace it at new.opencut.app.
Can I contribute code to OpenCut right now?
Not yet for the rewrite repo — the project states it isn't set up to accept outside contributions while the new architecture is being designed. Following along via Discord or GitHub issues is the current option.
What's changing in the OpenCut rewrite?
A Rust/wgpu compositor replacing the old WebGL renderer, an integer tick-based time system for frame-accurate editing, type-enforced track structure, a diff-based ripple-editing system, a planned Editor API and plugin architecture, an MCP server for AI agents, and headless/automation rendering.
Is OpenCut free to use?
Yes, it's MIT-licensed and open source, both the classic version and the in-progress rewrite.
Does OpenCut run entirely in the browser?
The classic version does. The rewrite is being built as a shared Rust core targeting browser, desktop, and mobile from one codebase, with the desktop app currently an early skeleton with no features yet.
How do I run the OpenCut rewrite locally?
It uses proto (moonrepo's toolchain manager) to install pinned tool versions via proto use, then moon to run the dev servers: moon run web:dev for the web app on localhost:5173 and moon run api:dev for the API on localhost:8787.
Has the rewrite actually shipped new editing features, or is it just architecture work?
Both. The latest release added masks, a keyframe graph editor, volume and speed controls, preview zoom, custom canvas sizing, canvas backgrounds, and a stocked stickers panel, alongside the underlying Rust/wgpu compositor rewrite — real feature work on top of the new architecture, not architecture alone.
Can I self-host OpenCut?
Yes. Both the classic version and the rewrite are MIT-licensed, and the rewrite's web app includes Cloudflare Workers deployment configuration (via OpenNext) for anyone who wants to run their own instance instead of using opencut.app or new.opencut.app.
What happens to the classic version once the rewrite is ready?
The README states the rewrite is intended to eventually replace the classic version, currently live at new.opencut.app during development. The classic repository stays frozen and separate in the meantime, still powering opencut.app.