CartCut: an Electron video editor built to be driven by AI agents

What CartCut is, and the editing model it bets on

CartCut is a desktop video editor written in TypeScript and packaged with Electron, from the GitHub organisation cartesiancs. The README calls it "Video editing software designed for motion effects and versatility", and the repository description adds the framing that matters more: a video editor for AI agents, built on the belief that open source can beat commercial tools. That second phrase is a positioning statement, not a documented feature. Nothing in the README describes an agent API, a tool-calling interface or a headless mode. The .mcp.json file and .claude/ directory in the repository root suggest some agent-oriented tooling exists in the development environment, but the README does not document it, so treat the agent claim as an intention rather than a contract you can build against.

The concrete design decision is the editing model. CartCut uses layer-based editing rather than track-based editing, which the README frames as the differentiator: "This approach makes it easier to apply multiple effects to individual assets, providing greater flexibility and creative control." In a track-based editor, a clip lives on a horizontal lane and effects are usually applied at the track or clip level; stacking means adding another lane. In CartCut, assets are layers you can reorder and target individually, which is closer to how a compositing tool behaves than to how Premiere or Final Cut behaves. If your mental model is a timeline with V1, V2 and A1 rows, you will spend the first hour relearning where things go.

The feature list is long and reads like a product page rather than a specification: cut editing, audio mixing, keyframed position/scale/opacity/rotation animation, text, chroma key, WebGL blur, shape drawing, effects and transitions, screen and audio recording, project save and load, multilingual support, and resolutions up to 8K. Two entries are worth pulling out because they imply real dependencies. "Fast rendering with FFmpeg" means the app shells out to FFmpeg binaries you supply. "AI Auto Caption (whisper)" means a speech model is built as part of the dev and build scripts (there is a build:speech script and a scripts/buildSpeech.mjs in the repository). Both are things you will have to provision.

How the pieces fit: Electron, webpack and an FFmpeg you provide

The repository layout tells you most of the architecture. There is an electron/ directory for the main process, apps/ containing at least an overlay-record application (built by build:overlay, which runs npm --prefix apps/overlay-record ci and then its build script), packages/ for shared code, native/ for native modules, and scripts/ for build tooling. The renderer is bundled by webpack (webpack.config.js at the root, with bundle:src running webpack --mode=development --watch and bundle:prod:src running the production mode). TypeScript compilation is separate: npm run compile runs tsc -w -p ./.tsconfig, and build:main runs the same compiler once without watch. So the dev loop is two processes running side by side, which is exactly what the dev script does with concurrently.

FFmpeg is not vendored. The README instructs you to download ffmpeg and ffprobe into ./bin, in a folder named for the build target, and it gives the expected tree: bin/darwin-arm64/{ffmpeg,ffprobe}, bin/darwin-x64/{ffmpeg,ffprobe}, bin/win32-x64/{ffmpeg.exe,ffprobe.exe}, plus a yt-dlp entry. Only the folder matching your machine is needed to run locally, but npm run build reads whichever one it is packaging for. Compatible binaries come from a separate repository, cartesiancs/ffmpeg4nugget. This is the single most important operational fact about CartCut: the app is a shell around an encoder you install yourself, and the quality of your exports depends on which build you drop in there.

The README is unusually direct about one failure mode here. macOS builds must be native. An x86_64 binary runs on Apple Silicon through Rosetta 2 at roughly half the export speed, and the README states that nothing in the app will say so. That is a silent performance regression, which is worse than a crash because you will blame the editor. The verification command is given: lipo -archs bin/darwin-arm64/ffmpeg must print arm64. The README also lists required encoders: libx264, libx265, libvpx-vp9, prores_ks and the VideoToolbox encoders, checkable with ffmpeg -encoders. If you grab a stripped-down FFmpeg build, export options will be missing rather than erroring loudly.

Installing CartCut from source and cutting your first clip

There is no documented package-manager install. The README's Download link points at the GitHub releases page, where v0.5.3 is the most recent tagged release (published 2026-09-09), preceded by v0.5.2 and v0.5.1. The package.json version is 0.5.5, ahead of the last release tag, which is normal for a repository between releases but means the source tree is not identical to the binary you would download. If you want to run from source, start with dependencies:

npm install

Next, place FFmpeg. Create the folder for your platform under bin/ and put both binaries in it. On an Apple Silicon Mac that means bin/darwin-arm64/ffmpeg and bin/darwin-arm64/ffprobe, downloaded from the cartesiancs/ffmpeg4nugget repository the README points to. Windows needs bin/win32-x64/ffmpeg.exe and ffprobe.exe. Only your own platform's folder is required to run locally.

Then grant permissions on that folder, which the README asks for explicitly:

chmod -R 777 bin

Be aware of what that does. It makes everything under bin/ world-writable and executable on a POSIX system. It is the project's instruction, not a general recommendation, and it is broader than the binaries need. If you are packaging CartCut for other people, revisit that step rather than copying it into a build script.

Finally, run the app. The README gives two scripts:

npm run dev
npm run start

npm run dev is the development path: it builds the speech component, then runs the TypeScript compiler in watch mode and the webpack dev bundle concurrently. npm run start runs electron . directly, which expects main/main.js to already exist, so use it after a build rather than on a fresh clone. Once the window opens, the README's feature list is the map: import a clip, apply cut edits, stack layers for effects, add keyframed position or rotation animation, then export. Export is where your FFmpeg choice shows up, so if a codec is missing from the list, go back to ffmpeg -encoders before filing anything.

Where CartCut will let you down

The FFmpeg dependency is a real limitation, not a footnote. CartCut does not ship an encoder, does not verify the one you supply beyond what the README tells you to check manually, and does not warn you when the binary is the wrong architecture or missing codecs. Two of the three documented checks are commands you have to remember to run. A user who skips the README will get working software with degraded output and no signal about why.

The platform story is uneven. The package.json scripts include build:osx and build:win and a build:linux entry, but the README's bin/ layout documents darwin-arm64, darwin-x64 and win32-x64 only, and the release notes give no detail on what the release artifacts contain. Linux is the weakest case: the build script exists, the binary layout is undocumented, and nothing in the README explains where ffmpeg should go on that platform. If Linux is your target, you are reading the build scripts rather than the documentation.

Version maturity is the other constraint. The project is at 0.5.x, and the release cadence over late August and early September 2026 shows several patch releases in a few weeks. That is a healthy sign for activity and a warning sign for stability: project file formats and internal APIs at this stage can move between minor versions. There is a CHANGELOG.md in the repository, and it is the file to read before upgrading rather than after.

Finally, the agent framing. The repository description promises a video editor for AI agents, and the README documents no agent interface, no scripting API and no headless render command. The MCP configuration file in the repository root is evidence of tooling around the project, not of a published API. If your plan is to have an agent drive CartCut programmatically, verify that capability exists in the source before you design around it.

CartCut against the track-based editors you already know

The obvious comparison is CapCut, and it is a comparison the project invites: the repository is named cartcut, and the related searches around it are full of CapCut queries. The difference in approach is not just licensing. CapCut is a closed, account-linked product with a mobile-first editing model and a template ecosystem; CartCut is MIT-licensed source you run on your own machine, with no documented template library and no cloud component in the README. CapCut's strength is that it works immediately on a phone. CartCut's strength is that you can read the code, change it, and ship a build without asking anyone.

Against a track-based desktop NLE, the split is the editing model itself. Track-based editors map cleanly onto how footage is actually shot and how audio is mixed: dialogue on one lane, music on another, overlays above. CartCut's layers are better suited to compositing, where you want to stack effects on a single asset and adjust each independently. The README presents this as an advantage, and for motion graphics work it probably is. For a straightforward interview cut with three audio sources, the layer model adds a translation step that a track-based tool does not have. That is a trade-off, not a defect, but it is the one that will decide whether CartCut fits your work.

Against FFmpeg directly, CartCut is a convenience layer. Anything it renders, an FFmpeg command line can render too, and a scripted pipeline will be more reproducible than a GUI session. What CartCut adds is the interactive part: seeing the layer stack, scrubbing, adjusting a keyframe. If your workflow is already a build script, the editor is overhead. If it is a person at a desk, it is the point.

Licence, maintenance and what an upgrade costs

CartCut is MIT licensed, per the README and the LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in commercial and closed products, provided the copyright notice and permission notice are preserved. There is no copyleft obligation and no source-disclosure requirement. Note that this covers CartCut's own code only. The FFmpeg binaries you download separately carry their own licensing, and FFmpeg builds vary in which codecs are enabled and under what terms, which is a question for whoever built the binary you place in bin/, not for CartCut. This is not legal advice; if you are shipping a product, have someone check the FFmpeg build you chose.

Maintenance looks current on the evidence available. The repository is not archived, and the last push was on 2026-09-10, ten days before this writing. Releases v0.5.1, v0.5.2 and v0.5.3 landed between 2026-08-27 and 2026-09-09, and the package.json version is 0.5.5, so work has continued past the last tag. The repository carries CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md, which are the markers of a project that expects outside contributors.

The upgrade cost is concentrated in two places. First, the FFmpeg binaries are outside the versioning of the app: upgrading CartCut does not upgrade your encoder, and a codec that worked under one release is not guaranteed to be exercised the same way under the next. Second, project files. The README lists "Save&Load Project as File" as a feature, and at 0.5.x there is no documented format stability guarantee. Before moving a production project from one version to the next, keep the old build around, open the project in both, and confirm the layer stack and keyframes survive. The CHANGELOG.md is the only place that would tell you in advance.

Editorial conclusion

Adopt CartCut if you want a layer-based editor you can run from source, are willing to place your own ffmpeg and ffprobe binaries in bin/ per platform, and can live with a 0.5.x API surface that changes between releases. Do not adopt it if you need a signed installer today, a documented headless command line, or an editing model that matches track-based NLEs. Before committing, run lipo -archs bin/darwin-arm64/ffmpeg on macOS to confirm the binary is arm64, run ffmpeg -encoders to confirm libx264, libx265, libvpx-vp9, prores_ks and the VideoToolbox encoders are present, and check the CHANGELOG between 0.5.1 and 0.5.5 for breaking changes to project files.

Frequently asked questions

Official sources

1. cartesiancs/cartcut on GitHub
2. License: MIT
3. Project website
4. README
5. Releases