capcut-cli: A Deterministic Boundary, Running in Public

Where the model has to stop

The interesting question in an AI pipeline is never whether a model can do the work. It is where the model is required to stop.

Timing, subtitle placement, track layout and cut points are arithmetic. They belong in code that returns the same output on every run, that can be diffed against the last version, linted before it ships, and rolled back when it is wrong. Segment selection and hook copy are judgment calls, and those belong to a model or a person. Almost every stalled pilot I get called into has those two halves mixed together, which is why nobody can say what broke.

capcut-cli draws the line in the tooling itself, where it cannot be argued away: the CLI owns the deterministic half and hands back structured JSON, the model supplies only structured input, and the publish click stays with a person. That constraint is the reason an agent can drive it at all without anyone losing sleep.

The same split runs through client systems that carry more risk than a video timeline. PII redaction behind deterministic masking follows it exactly: rules first, the model only for what rules cannot decide.

What the tool actually is

capcut-cli creates and edits real CapCut and JianYing projects from the command line, working directly on the local draft store. No upload, no API key, no server in the background. The result opens in CapCut with every track still editable, not as a flattened export.

One install, four ways to drive it:

• CLI — npm install -g capcut-cli, then capcut <command> <project>
• Library — typed imports (loadDraft, lintDraft, saveDraft), zero runtime dependencies
• Queue runner — capcut serve reads JSONL jobs from stdin, for n8n, Make, or Coze
• Agent sandbox — an experimental WebAssembly component with no filesystem, network, clock, or process access, so a model can inspect a draft without being able to touch anything else

What public adoption forces the project to do

Roughly 12,000 installs a month means other people’s pipelines break when I am careless. So the repository runs what I would expect from a system in operation:

• CI on every push, with the WebAssembly build proving it has zero host imports before it ships
• Versioned releases and a maintained changelog, currently v0.22.0
• Security issues disclosed and fixed in public, with the affected versions named in the README instead of quietly patched
• Both the CapCut and JianYing namespaces in one binary, and detection of newer CapCut layouts rather than assuming a single file is the only source of truth

None of that is glamorous. It is the difference between something that demos and something people can run unattended, which is also the difference I am usually hired to close.

Start here

• Repository — github.com/renezander030/capcut-cli, MIT licensed
• Install — npm install -g capcut-cli, Node 18 or newer
• The pipeline in practice — Automate YouTube Shorts with CapCut: the CLI and Claude pipeline

Star, install and clone figures read from GitHub and npm on 6 September 2026. This is an independent project and is not affiliated with, sponsored by, or endorsed by CapCut, JianYing, or ByteDance Ltd.