fast-cutvid Cuts Video for Agents

By Rogier Muller09.06.26

fast-cutvid is modecir’s open-source native video cutter for macOS, Windows, and Linux. It deals with a very specific pain: agents can summarize transcripts, but they still struggle to make good timing decisions on a video timeline. The useful idea is not “let the agent edit everything”; it is “let the human make the cuts, then give the agent a precise edit list it can use.” That is a nice pattern for Codex CLI workflows too: keep judgment in the loop, and make the handoff machine-readable.

fast-cutvid is a focused timeline editor that exports video cuts as portable JSON so humans and local AI agents can render the same sequence. The project was built in Rust with egui for the interface and FFmpeg for media processing, without Electron, HTML, JavaScript, or a webview. As of September 2026, the repository is small, 4 GitHub stars, MIT licensed, mainly Rust, and last pushed on 2026-09-05, but the itch is real enough that developers noticed it. GitHub Copilot Workshop is part of Harness Institute.

Understand the itch before the agent

The author’s workflow starts with a familiar gap. A video agent can work from a transcript, but transcripts flatten time. They do not show the pause before a point lands, the awkward half-second after a sentence, the visual cue that makes a cut feel right, or the moment a screen recording actually becomes useful.

That is why fast-cutvid is interesting. It does not pretend that a model can magically become a senior editor from text alone. It gives the human a small native timeline for the part where taste matters, then writes out a JSON edit decision list for the part where automation helps.

The trap is to frame this as a replacement for Adobe Premiere Pro or Blackmagic Design’s DaVinci Resolve. The README is clear that fast-cutvid is not a finishing suite. Effects, transitions, titles, color grading, compositing, animation, and advanced audio mixing are outside its scope.

That narrowness is the feature. Open fast, cut the useful moments, export something deterministic, then let another editor or agent handle the next stage.

Notice the design trick: JSON is the handoff

The quiet move in fast-cutvid is the portable JSON cut format. The timeline is for people. The JSON is for agents, scripts, and later rendering steps.

That split matters for anyone building with OpenAI Codex, OpenAI’s coding agent, or the codex cli. A good agent workflow rarely depends on chat history alone. It leaves behind files that can be reviewed, diffed, re-run, and passed to another step.

A useful equivalent in a repo might be an AGENTS.md note beside the tool:

# AGENTS.md

## Video cut workflow
- Treat `cuts/*.json` as the source of truth for rough cuts.
- Do not infer timing from transcript text when a cut JSON exists.
- Before rendering, validate that every source path exists and every cut has start < end.
- After rendering, write a short receipt with input files, output path, FFmpeg command, and duration.

That is not bureaucracy. It is a boundary. The agent can help with rendering, naming, compression, upload preparation, or release notes, but it should not silently reinterpret the human’s timing work.

The trap is to make the JSON too magical. If the cut file becomes an undocumented private protocol, only the original app can safely use it. The more boring the handoff format is, the more useful it becomes.

See why Hacker News cared

The Hacker News reaction was warm because the problem is oddly common. Many developers now produce videos: launch demos, changelog clips, course modules, internal explainers, bug reproductions, and social posts. A full editing suite is often too much for trimming a few screen recordings into a clean sequence.

One commenter with Final Cut Pro experience pointed at the same itch: professional editors are powerful, but the agent integration layer is still being figured out. Another said they had imagined an open-source video editor where you edit alongside an LLM, then gave up on it. That is the exact kind of unfinished idea fast-cutvid makes concrete.

There was also a fair limitation in the post: the author said it had only been tested on Apple silicon Macs. The README lists published builds for macOS Apple silicon, macOS Intel, Windows x86-64, and Linux x86-64, but early cross-platform projects still need boring compatibility feedback before anyone should trust them in a deadline workflow.

The practical lesson for agent builders is sharper than the app itself. When a model is weak at a task, do not always add more prompting. Sometimes the better product is a tiny human interface that creates a better artifact for the agent.

That same pattern shows up in code-first agent work, where the useful boundary is often “write a file, then let the agent operate on the file.” We covered a related version of that idea in Ardent Ships a Code-First Office Agent, where the interesting part was not a chat UI but a code-shaped work surface.

Try it when the cut is the bottleneck

fast-cutvid is worth trying when your source material is simple and your pain is timing. Think screen recordings, talking-head clips, product demos, bug repro videos, or course snippets where the rough cut is the annoying part.

It is probably overkill if your current editor is already fast for you. It is definitely underpowered if the job needs finishing work: color, audio repair, motion graphics, subtitles, branded templates, or multi-track sound design.

For Codex users, the best small experiment is not “can an agent edit my video?” It is “can I create a cut file by hand, then ask Codex to validate and render it without changing the timing?” That keeps the test honest.

A simple codex cli verification loop might look like this:

# after creating cuts/demo.json in fast-cutvid
codex "Inspect cuts/demo.json and write a render plan. Do not modify cut timing. Check that source files exist, cut ranges are valid, and FFmpeg is available."

codex "Create a script at scripts/render-demo.sh that renders cuts/demo.json with FFmpeg. Keep it deterministic and print the output duration."

bash scripts/render-demo.sh

The trap is to skip verification because the app feels small. Video tools touch large files, shell commands, external binaries, and platform-specific paths. Ask the agent to check assumptions before it writes commands that churn through gigabytes.

For more patterns like this, the broader Codex CLI workflows topic is the right place to connect file-based handoffs with repo instructions, MCP boundaries, and repeatable checks.

Try fast-cutvid safely

Use this as a small experiment, not a production dependency review.

Fit	Not fit
Cutting screen recordings into a rough sequence	Color grading, titles, transitions, or compositing
Human chooses exact timing, agent renders later	Agent invents timing from transcript only
JSON cut files can live in a repo or project folder	Edits must stay inside a proprietary timeline
FFmpeg-based local rendering is acceptable	You need a managed cloud render pipeline today
You can test on your target OS first	You need guaranteed cross-platform behavior immediately

A safe first pass is small:

Download the build for your OS from the project releases.
Confirm FFmpeg and FFprobe are installed or bundled as expected.
Cut a 30–60 second sample, not a real deadline video.
Export the JSON cut file and commit it beside the source asset manifest.
Ask Codex to validate the JSON, not to change the edits.
Render once manually and compare output duration against the cut list.
Save a receipt with the app version or commit, input files, JSON path, FFmpeg command, and output file.

If the receipt is boring, the workflow is probably healthy. If the receipt is confusing, fix the handoff before you automate more of it.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Common questions

How should teams start with Codex?

Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

Which Codex artifact should teams standardize first?

Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

How do teams know the convention is working?

The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “fast-cutvid Cuts Video for Agents.”
Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.