Last week I open sourced FableCut,
a Premiere-style video editor that runs in the browser and that AI agents can
operate. It hit the front page of Hacker News
(thread), and the questions
there made me realize the interesting part isn't the editor. It's one design
decision: the project file is the interface.
The usual way, and why I flipped it
Most AI video tools hide the edit behind an API. You call addClip(),
applyFilter(), and the tool owns the state. If you want a human to touch the
result, you build a whole collaboration layer.
FableCut does the opposite. The entire timeline lives in one JSON document,
project.json: media, clips, tracks, keyframes, transitions, markers. The
editor UI reads it. The export renders it. And anything that can write JSON
can edit video: Claude Code through MCP, a Python script, jq, or you with a
text editor.
{
"id": "c_title", "kind": "text", "track": "V3",
"start": 0, "duration": 2.2,
"props": { "text": "HANDMADE", "font": "Bebas Neue",
"glow": 45, "textAnim": "letter-pop" }
}
That clip is a glowing kinetic caption. There is no API call that creates it.
Writing it into the file IS creating it.
SSE as a doorbell, not a data channel
The first question on HN was "what's the benefit of SSE here?" Fair question,
because the SSE channel does almost nothing, and that's the point.
The server watches the project file with fs.watch, debounces 150ms, and
pushes the literal string change to the browser. No payload. The browser
re-fetches the project and re-renders. The whole mechanism is about 15 lines
on a bare node:http server.
Why not WebSockets? Because the data only flows one way. Everything that
writes (the UI, an agent, a shell script) goes through REST or the
filesystem. The browser only ever needs to hear "something changed, go look."
An event with no payload can't arrive out of order, and a missed event costs
nothing because the next fetch has the latest state anyway.
The revision counter, or: how a human and an agent share a timeline
The file carries an integer revision. Every write must bump it. If a write
arrives with a revision that isn't newer than what's on disk, the server
rejects it with a 409.
This one integer is the entire concurrency model. If I drag a clip in the UI
while an agent is mid-edit, the agent's stale write bounces, it re-reads,
re-applies its change on top of mine, and writes again. No operational
transforms, no CRDTs, no lock files. It works because edits are coarse
(a whole document) and rare (human speed), so last-writer-wins with a
staleness check is enough.
The trick I'm proudest of: frame-accurate CSS animations
FableCut has animated SVG overlays (lower thirds, confetti, sparkles) that
are plain .svg files animated with CSS @keyframes. The problem: a video
compositor needs to render the animation state at an exact time, and export
isn't realtime. You can't just let the animation play.
The solution: pause every animation and drive time by hand. The compositor
sets animation-delay: calc(var(--d, 0s) - t) where t is the clip's local
time. A negative delay means "you started in the past," so a paused animation
with delay -1.3s displays exactly its 1.3 second frame. Deterministic,
scrubbable, identical in preview and export. The only rule for SVG authors is
to never hardcode animation-delay and use the --d custom property for
staggering instead.
"You can just give Claude access to ffmpeg"
Someone said this on HN and it deserves a straight answer. For trims,
concats, and batch transcodes: yes, absolutely, do that.
The difference is the creative loop. ffmpeg is write-only. The agent builds a
filter graph, renders for minutes, and cannot see what it made. You give
feedback, everything re-renders. In FableCut an edit is a JSON diff, the open
browser updates in 150ms, and the timeline stays editable instead of being
baked into a filter string. It's not a replacement for ffmpeg anyway: the
export pipeline renders frames in the browser and pipes them to ffmpeg for
encoding. FableCut is the state and preview layer between the agent and
ffmpeg.
Honest limitations
The compositor is the browser, so export needs a browser open (headless
export is not there yet). It's Chromium-first. And an AI can misjudge a cut
just fine, which is why the human-in-the-loop part matters more than the AI
part: the agent does the labor, you do the taste.
Full disclosure since HN asked: Claude helped write the README, and large
parts of the editor were built in collaboration with it. That felt fitting
for a tool whose primary user is an AI agent, but the architecture decisions
above are the ones I'd defend in person.
Repo: https://github.com/ronak-create/FableCut. It's MIT, zero dependencies,
one node server.js. If you build something weird with it, I want to see it.