Pireel Studio: an AGPL-3.0 video editor that agents can drive over MCP
The open-source alternative to Capcut、ChatCut. Drivable by any AI agent over MCP.
At a glance
- What is it?
- Pireel Studio is a TypeScript, browser-based video editor whose README positions it as a local editing workspace that a human and an AI agent can both operate. The interesting part is the split: the editor is AGPL-3.0, while the agent plugin that talks to it is Apache-2.0, and that split is where most of the adoption questions live.
- Who is it for?
- Adopt Pireel Studio if you want a timeline editor you can run locally and hand to an agent for first-cut work, and if AGPL-3.0 on the editor is acceptable for how you plan to distribute anything built on it. Do not adopt it if you need a hosted, managed service with the Chat features built in, or if you intend to ship a closed derivative of the editor itself.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Pireel Studio is aiming at
Most AI video tools take one of two shapes. Either they are a hosted service where you type a prompt and receive a rendered file, with no real timeline to correct, or they are a conventional editor where AI is a side panel that suggests things you then apply by hand. Pireel's README describes a third arrangement: an editing workspace with a canvas and timeline that a person can operate directly, and that an AI agent can also operate, through a plugin. The stated audience is people producing talking-head videos, short clips cut from longer recordings, product demos, tutorials and multi-source edits, plus multiple versions for different platforms. That list is specific enough to be useful. It is not a claim to handle every kind of post-production, and the README does not say it does. The framing that matters is control: the README says AI can help make the first cut while the person keeps the canvas, timeline, captions, graphics, audio and export. Whether that division holds up in practice depends on how much of the timeline the agent can actually reach, which the README leaves to the separate connection guide.
Two packages, two licences, one workflow
The repository is TypeScript, licensed AGPL-3.0-only, and the README is explicit that the agent plugin is a separate project under Apache-2.0. That is not a detail to skim past. The editor and the plugin are distributed under different terms, and the plugin lives in its own repository (pireel/pireel-agent). If your legal review treats copyleft as a blocker, the relevant question is which artefact you are actually shipping or modifying. The README also draws a line between the open-source edition and the hosted product: the open-source edition "focuses on local editing", while built-in Chat and connected services are described as part of the complete hosted experience at pireel.com. So the repository gives you the editor and the plugin, and the hosted site gives you the chat surface. Anyone evaluating this should read the README's own qualifier rather than assuming feature parity between the two.
How the pieces connect
The README does not document the internal architecture, so anything beyond what it states would be guesswork. What it does state is the shape of the integration: Pireel Studio is the editing workspace, and an AI agent such as Codex or Claude Code connects to it through the public Pireel agent plugin, which is installed with a skills command. The project description adds that the editor is "drivable by any AI agent over MCP", which is the Model Context Protocol. The README itself does not walk through the MCP server, the tool list, or the message flow, and it points readers to a connection guide at pireel.com/connect-agent.md for supported agents. Treat that guide as the authoritative source for the protocol details, because the repository README does not contain them. What you can reasonably infer from the layout is that the plugin is the boundary: the editor stays a local application, the plugin carries the agent's instructions into it, and the agent never needs to be a specific vendor's model.
Running the local editor from source
The README gives a four-line setup, and it is worth following literally rather than substituting your own toolchain. Clone the repository, change into it, enable Corepack, install with pnpm, and start the dev server. Corepack being enabled first is the part people skip, and it is what pins the package manager version the project expects. After pnpm dev, the README says to open the URL printed in the terminal and import your media. There is no configuration file documented in the README, no environment variable list, and no build-versus-dev distinction spelled out. If you need a production build, a Docker image, or a headless deployment, the README does not describe one, and the material does not say whether the editor is designed to run anywhere other than a local machine. That is a gap, not a hidden feature. For the agent side, the documented command is npx skills add pireel/pireel-agent, followed by asking your agent to set up Pireel. The README does not list which agent versions or runtimes are supported; the connection guide is where that is supposed to live.
Where this is the wrong tool
The most concrete limitation is stated by the project itself: the open-source edition focuses on local editing, and the built-in Chat plus connected services belong to the hosted product. If your workflow assumes a prompt box inside the editor, the repository alone will not give you that. The second limitation is the licence. AGPL-3.0-only is a strong copyleft licence, and it is a poor fit for anyone who wants to embed the editor in a closed product or offer a modified version as a network service without releasing source. The third is the thin operational documentation. There are no releases retrieved for this repository, so there is no changelog to read for upgrade behaviour, and the README does not describe a migration path between versions, a data format for projects, or how media is stored on disk. For a tool that holds editing state, the absence of any documented project format in the README is something to confirm before you put real work into it. Finally, the README makes no claim about performance, render times, or media sizes, and I have not run it, so none of those should be assumed.
How it differs from a hosted AI video service
The obvious comparison is a hosted prompt-to-video service, where you describe an edit and download a result. The difference is not the AI; it is where the editing state lives and who can inspect it. In the hosted model, the timeline is usually the service's internal representation, and your correction path is to re-prompt. Pireel's arrangement keeps a canvas and timeline as the primary surface and treats the agent as one of several ways to change it, alongside direct manipulation and chat. That matters when an edit is almost right. You can open the timeline and move the cut instead of writing a more precise prompt and hoping. The trade-off is operational: a hosted service handles rendering, storage and scale for you, while a local editor puts that on your machine and leaves deployment, backups and version pinning to you. Neither is strictly better. If your team has no appetite for running local tooling, the hosted service wins on effort. If you need to keep source footage and project state on your own hardware, the local editor is the only one of the two that gives you that.
Maintenance, upgrades and the licence boundary
The repository is not archived and the last push recorded is 2026-09-08, so the project is active. There are no retrieved releases, which means there is no published version history to plan upgrades against, and the README does not describe how project files behave across versions. Practically, that pushes you toward pinning a commit rather than tracking main if you use this for anything you care about. On licensing, the split is the thing to get right: the editor is AGPL-3.0-only, the agent plugin is Apache-2.0, and the README does not state how the two interact at the licence level when they run together. I am not giving legal advice here, and this is exactly the kind of question to put to someone qualified, with both repositories and their LICENSE files in hand. The practical version of the question is simple: are you modifying the editor, and are you exposing it to users over a network? If the answer to either is yes, read the AGPL text before you build on it.
Editorial conclusion
Adopt Pireel Studio if you want a timeline editor you can run locally and hand to an agent for first-cut work, and if AGPL-3.0 on the editor is acceptable for how you plan to distribute anything built on it. Do not adopt it if you need a hosted, managed service with the Chat features built in, or if you intend to ship a closed derivative of the editor itself. Before committing, verify three things from the repository rather than the landing page: which Node and pnpm versions the build actually requires, whether the local editor exposes the same MCP surface that the hosted product documents, and whether the agent plugin's Apache-2.0 licence covers everything you need it to do, since the plugin and the editor are separate packages with separate terms.
Community notes