OpenCut Explained: An Open-Source CapCut Alternative Rebuilt in Rust

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 confusion is understandable. If you search for an open-source video editor that runs in the browser, OpenCut is likely near the top of the results, but the repository most people land on is not the editor running at opencut.app. Developers who clone it expecting a finished CapCut replacement find an architecture in progress; teams evaluating it for a product or workflow need to know which version to bet on, and on what timeline.

This explainer separates the two. It covers the classic-versus-rewrite split, what the rewrite is trying to solve, the substantive engineering choices in its release notes (a Rust/wgpu compositor compiled to WebAssembly, integer tick-based time, type-enforced tracks, diff-based ripple editing), the features already shipped on the new architecture, the local development setup, how OpenCut compares with other free editors, and who should use which version today.

What Is OpenCut? 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 (see what the Model Context Protocol is if that term is new), 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 (a good example of the shift described in our look at the future of WebAssembly). 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. MediaTime runs 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. SceneTracks replaces a flat track array with explicit overlay, main, and audio fields, 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.

Benefits of OpenCut

Even mid-rewrite, OpenCut offers things that proprietary editors and many open-source alternatives do not. Some apply to the classic editor today; others depend on where the rewrite lands, so it helps to keep the two apart when weighing them.

Free and permissively licensed

Both the classic version and the rewrite are MIT-licensed. There is no subscription, no watermark tier and no account wall for the hosted editor, and the licence allows modification, self-hosting and commercial use as long as the notice is kept. For teams wary of proprietary editors changing their pricing or terms, that permanence matters as much as the zero price.

Nothing to install

The classic editor runs in a browser. That suits shared or locked-down machines, quick edits on a borrowed laptop and teams that do not want to manage desktop software across many devices. The rewrite keeps the browser as a first-class target while adding desktop and mobile from the same core, so skills and projects should carry across devices once those targets ship.

Engineering built for frame accuracy

Integer tick-based time, type-enforced tracks and a diff-based ripple system address the bugs that make browser editors unreliable as projects grow: drifting alignment, misplaced tracks and edits that silently shift the wrong clips. These are choices more typical of mature desktop NLEs, and they are a good sign for how well the editor will hold up as features accumulate.

A path to programmable editing

The planned Editor API, plugin system, headless rendering and MCP server would let developers and AI agents drive edits in code. Few editors, open or closed, aim to expose editing as a platform in this way. If those milestones land, OpenCut becomes infrastructure for automated video workflows, not only a tool for manual editing.

A large community and real backing

More than 82,000 GitHub stars, a sponsor and an active Discord mean the project is unlikely to vanish quietly, and questions tend to get answers. For an open-source dependency, that community scale is a meaningful part of the risk assessment. It also means tutorials, community answers and third-party discussion are easier to find than for smaller editors.

How OpenCut Compares to Other Free Video Editors

OpenCut is not the only free option, and the right choice depends on whether you need a browser tool, a mature desktop editor, or something you can script and extend.

The distinguishing feature of the OpenCut rewrite is not the timeline itself; mature desktop editors already have that. It is the ambition to expose editing as an API, with plugins, headless rendering, and an MCP server that AI agents can call. That puts it closer to the programmable media pipelines discussed in our explainer on ComfyUI than to a traditional consumer editor.

OpenCut Use Cases

Who gets value from OpenCut depends heavily on which version they use. These are the situations where it fits today, and which version each one points to.

Quick edits without installing software

Problem: Creators and marketers often need to trim a clip, add captions or stitch a few shots together on a machine where they cannot or do not want to install a desktop editor. How it's applied: The classic version at opencut.app runs in the browser with no account setup or subscription. Outcome: Short edits get done in minutes. Creators who just want to edit a clip should use the classic version and treat the rewrite as something to revisit later, since it is not yet the editor driving the live site.

Self-hosted editing for privacy-conscious teams

Problem: Some organisations cannot upload footage to a proprietary hosted service because of client confidentiality or data-residency rules. How it's applied: Because both versions are MIT-licensed, a team can run its own instance, and the rewrite includes Cloudflare Workers configuration via OpenNext. Outcome: Editing stays on infrastructure the team controls. Teams going this route should plan for the rewrite's evolving storage schema, which changed through many migration steps in a single release cycle.

A scriptable backend for AI-assisted video workflows

Problem: Developers building agent-driven or automated video pipelines need an editor they can control programmatically, not just a manual timeline. How it's applied: The rewrite's planned Editor API, headless rendering and MCP server are aimed precisely at this. Outcome: Not available yet; developers in this space should watch those milestones closely, because they would make OpenCut a scriptable backend rather than only a UI.

Studying browser media engineering

Problem: Engineers working on browser performance, WebAssembly or GPU rendering have few open, real-world codebases at this depth to learn from. How it's applied: The rewrite's Rust crates and detailed release notes document a wgpu compositor compiled to WASM, integer tick-based time and diff-based ripple editing. Outcome: Engineers interested in browser performance will get the most from reading the Rust crates and release notes now, regardless of whether they ever ship a product on top.

Common OpenCut Mistakes

Most frustration with OpenCut comes from misreading where the project is in its lifecycle. These are the mistakes that show up most in issues and community discussions.

Cloning the main repo and expecting the live editor

The heavily starred repository is the rewrite, not the editor at opencut.app. Developers who clone it expecting the polished tool from demo videos find an architecture in progress and assume the project is broken. Check which repository you need before you start: classic for the editor people use today, the main repo for the new architecture.

Treating planned features as shipped

The Editor API, plugin system, MCP server and headless rendering are stated goals, not current capabilities, and the desktop app has no features yet. Teams that build a roadmap assuming these exist today will be blocked. Plan around what the release notes say has shipped, and treat the rest as milestones to track.

Building on the rewrite's internals too early

The rewrite's storage schema and core interfaces are still moving, as the long list of migrations in one release shows. Integrating tightly with internal structures now risks breaking with each update. If you experiment, isolate your integration and expect to revisit it.

Choosing it for long, complex professional projects

OpenCut's classic editor is good for quick, short edits. For long-form projects with many tracks, colour work and heavy effects, a mature desktop editor such as Kdenlive or Shotcut is still the safer choice today. Picking a browser tool for a feature-length edit invites performance and workflow problems.

Ignoring GPU and browser requirements

The rewrite's compositor relies on GPU-accelerated rendering in the browser. On older machines or browsers without support, it shows a notice rather than working. Testing only on a high-end development machine hides problems your users will hit.

OpenCut Best Practices

Whether you are editing, self-hosting or tracking the rewrite for a product, these habits keep expectations aligned with what the project actually offers today.

• 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.
• Pin versions and back up project data when self-hosting. Deploy a specific release rather than tracking the latest commit, and export or back up projects before upgrading, because storage migrations are still frequent.
• Evaluate with your own footage. Test real clips at the resolutions and lengths you work with, on the browsers and machines your team uses, before committing a workflow to either version.
• Read the release notes, not just the README. The release notes document what has shipped on the new architecture and why design decisions were made, which is the most reliable guide to when the rewrite will be ready for your use.
• Keep a fallback editor in your workflow. Until the rewrite replaces classic on the main domain, keep a mature desktop editor available for projects that outgrow a browser tool, so a missing feature never blocks a deadline.
• 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 or explore our custom web application development work.

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. The editor most people actually use lives at opencut.app and runs the classic codebase. It is popular because it is free, works without installing desktop software, and has a large community, with more than 82,000 GitHub stars and an active Discord.

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. This matters if you clone the main repository: you will be running unfinished software with a different architecture, so use the classic repository if you need the stable editor or want to self-host what is live today.

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. That is a deliberate choice during an architectural reset, when core interfaces such as the compositor, time system and track structure are still moving. If you want to get involved early, reading the Rust crates and release notes is the most useful preparation, and the classic repository remains frozen rather than open for new feature work.

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. The time change matters most for accuracy: ticks run at 120,000 per second, which divides evenly into every standard frame rate and removes floating-point drift. Taken together, the goal is a programmable editing platform built on one shared Rust core, not just a free timeline UI.

Is OpenCut free to use?

Yes, it's MIT-licensed and open source, both the classic version and the in-progress rewrite. There is no subscription for the hosted editor, and the MIT licence also allows you to modify the code and self-host it, including for commercial use, provided you keep the licence notice. That makes it a practical option for teams that cannot upload footage to a proprietary service, as long as they accept that the rewrite is still changing.

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. Because the new compositor relies on GPU-accelerated rendering in the browser, the rewrite detects unsupported browsers and shows a notice instead of failing silently, so a recent browser with GPU support gives the best experience.

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. Install proto first with the shell script on Linux, macOS or WSL, or the PowerShell script on Windows, then run proto use from the repo root so the versions pinned in .prototools are applied. A moon run desktop:dev task also exists, but the desktop app is still an early skeleton.

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. Even so, the rewrite is not yet feature-complete and does not drive the live site, so creators who simply need to edit a clip today should still use opencut.app and treat the rewrite as something to track.

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. Self-hosting suits teams with privacy or data-residency concerns that cannot upload footage to a hosted service. If you self-host the rewrite, plan for its storage schema to keep evolving while the new architecture is being designed.

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. No exact switchover date is given, so anyone relying on the editor day to day should keep using the classic version until the rewrite moves to the main domain. Developers can follow progress through the release notes and Discord in the meantime.

Conclusion

OpenCut is easy to misread. The editor most people use is the classic version at opencut.app, while the heavily starred main repository is a ground-up rewrite that is not yet the shipped product and is not accepting outside contributions. Knowing which one you are looking at prevents most of the disappointment developers report after cloning it.

The rewrite is worth paying attention to. Its Rust/wgpu compositor compiled to WebAssembly, integer tick-based time for frame-accurate editing, type-enforced tracks, and diff-based ripple editing are serious engineering decisions, and the latest release shows real features shipping on top of them. The bigger bet is the plan for an Editor API, plugins, headless rendering, and an MCP server, which would turn a free timeline tool into a programmable video platform.

The caveats are equally clear: the desktop app has no features yet, contributions are closed, and the storage schema is still moving. Use classic for editing today, and track the rewrite if automation or AI-driven video workflows matter to you. If you are planning a product or internal tool built around browser-based media editing, talk to our custom software team.