CartCut: a layer-based, FFmpeg-backed video editor aimed at AI agents

The problem CartCut picks, and the claim in its own description

The repository description calls CartCut a "Video Editor for AI agents, built on the belief that open source can beat commercial tools." That is the positioning. The README itself is more concrete: it describes "Video editing software designed for motion effects and versatility" and lists cut editing, animation, sound mixing, external library extensions, project management and text editing as the baseline. The stated goal in the roadmap section is that creators should be able to "achieve stunning motion effects without relying on heavy software like After Effects."

So there are two audiences implied and only one of them is served by the documentation. The motion-graphics editor who wants keyframes and layers without an Adobe subscription is clearly addressed: the feature list names re-position, scale, opacity, rotation animation and keyframes, plus chromakey, WebGL blur, shape drawing and transitions. The AI agent developer is not addressed in the same way. Nothing in the supplied README, feature list or release list describes an agent interface, a scripting API, a headless mode or a tool-calling schema. The phrase is in the repository description and nowhere else. Treat the agent framing as an intent statement rather than a shipped capability until you find evidence in the codebase.

Layers instead of tracks, and why that changes effect stacking

The one architectural decision the README explains is the timeline model. CartCut uses "layer-based editing, which differs from traditional track-based editing," and the stated benefit is that this "makes it easier to apply multiple effects to individual assets, providing greater flexibility and creative control." The feature list backs this with "Unlimited layers."

In a track-based editor, an asset sits on a track and effects are usually applied at track level, so stacking three effects on one clip means either nesting sequences or duplicating tracks. A layer model inverts that: the asset is the unit, and each asset carries its own stack. For motion graphics work where a single logo needs a blur, a chromakey and a keyframed scale, that is a shorter path to the result. The cost is compositing order. With tracks, vertical position in the timeline is the z-order and it is visible at a glance. With layers, z-order has to be managed explicitly, and the README does not describe how CartCut surfaces that. That is the first thing to check in the running app, because a layer editor with an unclear stacking indicator becomes harder to reason about than the track model it replaces.

FFmpeg is not a dependency, it is a directory you populate by hand

CartCut does not pull FFmpeg from a package manager. You install Node dependencies with npm install, then place ffmpeg and ffprobe binaries yourself under ./bin in a folder named for the build target. The README gives the layout explicitly:

bin/darwin-arm64/{ffmpeg,ffprobe} bin/darwin-x64/{ffmpeg,ffprobe} bin/win32-x64/{ffmpeg.exe,ffprobe.exe} bin/yt-dlp

Only the folder matching your machine is needed to run locally, but npm run build reads whichever target it is packaging for. Compatible binaries come from https://github.com/cartesiancs/ffmpeg4nugget. There is also a yt-dlp entry at the root of bin/, which suggests download-from-URL is part of the pipeline, though the README does not describe how it is invoked.

The README is unusually direct about a failure mode here. macOS builds must be native: an x86_64 binary running on Apple Silicon through Rosetta 2 exports at "roughly half the export speed, and nothing in the app will say so." That is a silent degradation, which is worse than a crash. The prescribed check is lipo -archs bin/darwin-arm64/ffmpeg, which must print arm64. The build also has to carry libx264, libx265, libvpx-vp9, prores_ks and the VideoToolbox encoders, verifiable with ffmpeg -encoders. A stock distro FFmpeg often lacks some of these, so the linked build is not optional in practice.

Permissions, running the app, and the Linux gap

After placing the binaries, the README requires a permission grant on the bin folder: chmod -R 777 bin. That is recursive and world-writable, applied to a directory holding executables the app runs. It is the kind of instruction that works and is also broader than the problem requires. If you are building on a shared machine or in CI, scope it down rather than copying the command verbatim, and verify the app still launches.

Running the editor is two commands: npm run dev and npm run start. The README does not explain the difference between them, which is a documentation gap rather than a design problem; the convention in Electron projects is that dev runs the renderer with hot reload and start runs the packaged or production path, but CartCut does not state it.

The bin/ layout covers darwin-arm64, darwin-x64 and win32-x64. Linux is absent. The feature list claims cross-platform support, and the layout does not match that claim. If you are on Linux, you are choosing your own binary directory name and hoping the build script recognizes it. That is unverified and the README offers nothing to go on.

Whisper captions, WebGL blur, and what the feature list does not say

Two entries in the feature list carry more weight than their one-line treatment suggests. "AI Auto Caption (whisper)" means speech-to-text runs locally through Whisper rather than through a hosted API. That matters for anyone working with footage they cannot upload, and it also means caption generation is bounded by the machine's compute. The README does not say whether Whisper is bundled, downloaded on first use, or expected as an external binary alongside ffmpeg and yt-dlp. Given that ffmpeg and ffprobe are manual placements, the third possibility is real and worth confirming before you plan a deployment.

"Blur Effect (WebGL)" indicates the preview pipeline is GPU-accelerated in the renderer, which is consistent with an Electron and Lit stack. The distinction that matters is whether the WebGL path is preview-only and exports fall back to FFmpeg filters, or whether both go through the same shader. The README does not say. If preview and export diverge, what you see is not what you get, and that is the single most expensive class of bug in a video editor. Test one keyframed blur through a full export before trusting the preview.

The rest of the list (8k and 4k editing, screen and audio recording, chromakey, shape drawing, multilingual support, save and load project as file) is stated without qualification. No resolution limits, no codec matrix, no memory guidance. That is normal for a README and still means the numbers are unknown until you measure them.

The alternative, and where the two approaches actually diverge

The obvious comparison is a scripted pipeline built directly on FFmpeg and ffprobe, with no editor at all. CartCut is, in effect, a GUI and project format wrapped around exactly those two binaries. The difference is what you get for the additional weight. A raw FFmpeg pipeline gives you a filter graph expressed as command-line arguments, which is fully reproducible, diffable and runs headless on a server with no display. CartCut gives you a layer tree, keyframes, a WebGL preview, a project file you can reopen and edit, and a UI where the compositing result is visible while you work. The trade is direct: reproducibility and headless operation on one side, interactive iteration on the other.

For an agent that needs to cut video without a human watching, the FFmpeg filter graph is the more direct answer, and CartCut's own description does not yet close that gap. For a person assembling motion graphics, re-deriving a keyframed blur as a filter graph by hand is the tedious work CartCut exists to remove. The two are not competing for the same task, which is why the "AI agents" framing in the description reads as aspirational. If a documented programmatic surface ships later, the comparison changes. As of v0.5.3, the README describes a GUI editor.

Maintenance cost, release cadence and the MIT licence

The release history shows v0.5.1 on 2026-08-27, v0.5.2 on 2026-09-04 and v0.5.3 on 2026-09-09, with the last push to main on 2026-09-10. That is roughly weekly patch releases on a 0.5.x line, which means the API and project format are still moving and you should expect to re-test after upgrades. The repository is not archived.

Upgrade cost has one project-specific wrinkle: because FFmpeg is a manual placement under bin/ rather than a managed dependency, upgrading CartCut does not upgrade your encoder. Those two version streams move independently, and a new CartCut release may expect encoder support your existing binaries lack. The ffmpeg -encoders check is the thing to re-run after each bump, not just at first install.

Licensing is straightforward on the surface. The README states "We are adopting the MIT license" and the repository carries an MIT identifier, which permits commercial use and modification. The complication is the bundled tooling. FFmpeg builds vary in which codecs they include and some builds carry GPL components, and yt-dlp is a separate project with its own terms. The CartCut licence does not determine the terms of the binaries you drop into bin/. Check the licence of the specific ffmpeg4nugget build you download before shipping anything commercial. That is not legal advice; it is the reason the binary provenance matters here more than it would for a project that pulls FFmpeg from npm.

Editorial conclusion

CartCut is worth adopting if you want an MIT-licensed Electron editor where every asset is a layer and rendering goes through FFmpeg binaries you already control, and if you are willing to build and package it yourself. It is the wrong choice if you need a documented agent API today, since the README never specifies one, or if you are targeting Linux, which the bin/ layout does not cover. Before committing, verify three things: that bin/darwin-arm64/ffmpeg prints arm64 under lipo -archs, that ffmpeg -encoders lists libx264, libx265, libvpx-vp9, prores_ks and the VideoToolbox encoders, and that you can live with chmod -R 777 bin on your build machine.

Official sources

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