Model or dataset
barefootford/buttercut avatar
barefootford/buttercut

ButterCut: an agent that edits video by writing Final Cut, Premiere and Resolve XML

Edit Video with Claude Code

607 stars98 forksRubyNOASSERTION

At a glance

What is it?
ButterCut is a Ruby and Python project that gives an AI coding agent a video editing workflow, built on FFmpeg and WhisperX transcription and aimed at Mac users with Apple Silicon. The free core handles single-track cuts and exports to three editors, and its licence permits commercial output while barring repackaging the tool.
Who is it for?
Adopt ButterCut if you edit on a Mac with Apple Silicon, already work in Final Cut Pro, Premiere or DaVinci Resolve, and want an agent to assemble a single-track cut from transcribed footage, and skip it if you need multi-track B-roll layouts or if your only option is Windows or Linux, since broad compatibility is not supported.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 30 days ago.
What is it written in?
Mainly Ruby, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

ButterCut is an editing agent, not a video editor of its own

The repository holds the core ButterCut XML generator and video editing agent. The project description says it plainly: Edit Video with Claude Code. There is no timeline application in this repository and no rendering pipeline competing with a NLE. Instead, ButterCut is a set of capabilities and conventions that an AI coding agent uses to drive an existing editor, with the editing model reduced to two abstractions. Libraries are where footage goes. Cuts are what the agent builds with you, and the README names three shapes of cut, a select, a scene, and a roughcut. The output is XML that a real editor opens. That design is what makes the tool interesting to a developer, because the editing intelligence lives in scripts and templates that can be read, forked and versioned, while the final assembly still happens in Final Cut Pro, Premiere or DaVinci Resolve. The trade-off is that the tool is only as good as the editor it hands work to, and it adds no interface of its own beyond the agent conversation.

Cloning the repo and running the setup skill is the whole install path

ButterCut targets Macs with Apple Silicon, M-series chips, and the README is direct about what happens elsewhere. If you are technical and do not mind agent churn, you can likely get it working on Windows, Linux and similar systems, but broad Windows and Linux compatibility is not a priority and is not something the author will publicly support for non-technical users. The install itself starts with a clone.

bash
git clone https://github.com/barefootford/buttercut.git && cd buttercut

After that, the README instructs you to call the `/setup` skill to install dependencies automatically, or to read skills/setup/advanced-setup.md for a custom install. The primary requirements are Ruby, Python, FFmpeg with full support, and WhisperX, and the repository pins versions through .python-version and .ruby-version while Gemfile and requirements.txt carry the dependencies themselves. The version tooling is mise, since the repository includes a .mise.toml, and the requirements file spells out the intended setup order.

code
#   mise install                    # Install Python 3.12.8 & Ruby 3.3.6
#   pip install -r requirements.txt # Install packages

The repository layout supports that structure. A skills/ directory holds the agent-facing capabilities, scripts/ holds helper code, lib/ holds the Ruby implementation, templates/ and dtd/ hold the XML shapes and their document type definitions, spec/ holds the RSpec tests, and AGENTS.md, CLAUDE.md and .agents/ and .claude/ directories hold the instructions the agent itself reads.

The transcription stack is pinned hard because unpinned installs broke

The requirements file is the most instructive document in the repository, because it explains what broke and why. The Python dependencies are for a video agent transcription workflow, and WhisperX is pinned at 3.8.6 for video transcription with timestamp alignment. The VAD and diarization stack is pinned at pyannote-audio 4.0.7, with a comment noting that whisperx 3.8.x requires pyannote-audio at or above 4.0.0, the reverse of the old constraint that whisperx 3.4.2 needed pyannote-audio below 4 because 4.x removed use_auth_token. The ML block is pinned exactly, and the reasoning is concrete: whisperx and pyannote declare only open floors for most of these packages, so unpinned installs resolve whatever is newest that day, and a drifting torch is exactly how whisperx 3.4.2 installs broke, since torchaudio 2.9 removed AudioMetaData and torch 2.6 flipped torch.load weights_only.

code
whisperx==3.8.6
pyannote-audio==4.0.7
torch==2.8.0
torchaudio==2.8.0
torchvision==0.23.0
torchcodec==0.7.0

The file also warns about a known false alarm, since whisperx 3.8.x pulls in torchcodec whose native FFmpeg bindings may fail to load at startup with a libavutil or LC_RPATH warning, and that this is harmless because whisperx decodes audio through the ffmpeg binary, so transcription works and the warning should not be chased. This pinning discipline is the price of an agent-driven transcription step, and it is the part most likely to need attention on a new machine.

The free core covers single-track cuts and nothing more

ButterCut comes in two editions and the README draws the line between them in a table. This repository is the core, free version, and ButterCut Pro is the paid edition at 49 dollars a year. Both editions support single-track cuts and both export to Final Cut Pro, Premiere and DaVinci Resolve. Multi-track cuts, meaning B-roll laid over an A-roll spine, are Pro only, as is ButterCut Preview, which browses libraries, clips and cuts inside Claude Desktop. Multicam cuts appear in the Pro column as coming soon rather than as shipped. That split matters for how you plan the work. The free core can sequence a single track of selected material and hand it to your editor, which is enough for many interview and screencast pieces, but it cannot lay B-roll over a spine, and it cannot give you an in-chat view of the libraries and cuts the way the Pro preview does. There is also a stated path for developers who want a reduced-cost Pro licence in exchange for bug reports, arranged through the Discord linked from buttercut.io, which tells you the author treats the free core as the funnel and the paid edition as the supported path.

The PolyForm licence allows commercial output but not commercial packaging

ButterCut is open source under the PolyForm Noncommercial License 1.0.0 with a Commercial Output exception, which is a custom licence that GitHub cannot classify, so the LICENSE file is the authoritative text and the README summary is the friendly version. The two halves matter separately. You can use ButterCut to make commercial videos, whether that is a YouTube video funded by ad revenue, a paid client project or a sponsored brand piece, and the videos are yours, with the licensor claiming no rights to them. You cannot repackage ButterCut as commercial software, so selling, hosting or bundling the tool itself, or a fork of it, into a commercial product, plugin or SaaS needs a separate commercial licence from TubeSalt LLC. Personal, hobby, research and educational use of the software is also free under the underlying licence, and a commercial software licence is available by contacting the address given in the README. Contributors are asked to start with an issue rather than a pull request, and the legal section of the README asks that any changes submitted be assigned to TubeSalt LLC, with an explicit instruction not to submit a pull request if your employment contract prevents such an assignment.

Maintaining working XML across three editors is the hard part

The author explains why contributions start with an issue rather than a code change, and the explanation is about coherence rather than about language models. It is easy to spike a quick change, add a feature or fix a bug, but it remains difficult to keep the code cohesive and to maintain working XML across three different editors. In practice that means the risk in this project lives in the compatibility surface rather than in the transcription logic. A template that produces valid XML for Final Cut Pro can produce something an editor rejects in Premiere, and the failure appears as a refused import rather than as an error message you can read in a log. The workflow for a contributor is therefore to open a human-written issue, work from there to a commit, with pairing and calls offered for context. The same README suggests a lighter-weight path for people who want to customise rather than change the core, namely creating your own skills, or forking existing ones, and prefixing them with user-, such as user-quick-interview-summary, which stay on your own machine, are gitignored, and can contain their own Ruby or Python scripts so you can build workflows without forking.

Release cadence and the gap between the last release and the last push

The repository is not archived and the last push was on 2026-09-23. Recent releases show v0.9.0 on 2026-09-14, v0.8.0 on 2026-06-27 and v0.7.2 on 2026-06-02, which places the project below 1.0 with several feature releases across a few months. A CHANGELOG.md and a GitHub directory for issue and pull request templates sit at the top level, and the versioning convention visible in the tag names suggests the author increments minor versions for feature sets rather than only for bug fixes. The licence detail deserves one more note for anyone planning around the free core, since the paid edition is where the multi-track and preview features live, and the free core is the version that receives the fixes that matter to a working installation. The project was inspired by open source work from Chris Hocking and Andrew Arrow, named in the README, which is the place to look if you want to see the shape of the underlying ideas.

Editorial conclusion

Adopt ButterCut if you edit on a Mac with Apple Silicon, already work in Final Cut Pro, Premiere or DaVinci Resolve, and want an agent to assemble a single-track cut from transcribed footage, and skip it if you need multi-track B-roll layouts or if your only option is Windows or Linux, since broad compatibility is not supported. Verify first that FFmpeg and the pinned WhisperX stack install cleanly, that your editor version accepts the generated XML, and that the PolyForm Noncommercial terms fit how you intend to use the tool.

Frequently asked questions

What does ButterCut need installed before I can use it?

The primary requirements are Ruby, Python, FFmpeg with full support and WhisperX, and the README directs you to call the /setup skill for an automatic install or to follow skills/setup/advanced-setup.md for a custom one. Specific language versions live in .python-version and .ruby-version, with dependencies in Gemfile and requirements.txt.

Can I use ButterCut on Windows or Linux?

ButterCut targets Macs with Apple Silicon. A technical user may get it working on Windows, Linux and similar systems, but the README states that broad compatibility is not a priority and is not publicly supported for non-technical users.

Can I use ButterCut to edit videos I sell commercially?

Yes, commercial output is permitted. The PolyForm Noncommercial License 1.0.0 with a Commercial Output exception allows commercial videos, and the licensor claims no rights to them. Repackaging ButterCut itself, including a fork, into a commercial product, plugin or SaaS requires a separate commercial licence from TubeSalt LLC.

Official sources

  1. barefootford/buttercut on GitHub
  2. Issues
  3. README
  4. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/barefootford-buttercut.svg)](https://hysenlabs.com/projects/barefootford-buttercut)

Was this useful?