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 ...
For further actions, you may consider blocking this person and/or reporting abuse
The project-file-as-interface idea is very strong. It gives the agent something durable to operate on instead of asking it to pretend the UI is the API. The hard part is making that file format stable enough that edits are reviewable, reversible, and not just a hidden pile of state mutations.
Treating the project file as the interface is a clean idea, it gives the agent something concrete to read and write against instead of inferring intent from a prompt. Curious whether that file format has needed versioning yet, since an agent's assumptions about what a field means will drift the moment the schema changes under it.
The revision counter as the entire concurrency model is a nice minimal-mechanism story, last-writer-wins with a staleness check works precisely because you named the actual constraint that makes it safe, edits are coarse and rare, and it would fall apart the moment either assumption breaks. SSE as a doorbell rather than a data channel is the same instinct in a different layer, an event with no payload can't arrive out of order and a missed one costs nothing because the next fetch has the latest state anyway, that's a good default any time you're tempted to reach for something heavier like websockets or CRDTs. The honest-limitations section is doing real work for credibility, naming that export needs a browser open rather than pretending headless export exists yet. One question on the 409-reject-and-reapply flow: when the agent's stale write bounces and it re-applies on top of a human's concurrent edit, does it re-derive the diff from the new base state, or does it just retry the same write verbatim and risk clobbering the human's change a second time?
A verbatim retry can't clobber, it just keeps bouncing. The re-apply is semantic, done by the agent, not mechanical, done by the server. And the recommended path sidesteps the whole dance.
Semantic re-apply by the agent, not mechanical retry by the server, is the right default and it's the part I'd have gotten wrong by instinct. Worth spelling out for anyone skimming: which path is "recommended" here, does the agent re-fetch and re-derive the diff against the new base state before reapplying, or does the 409 just hand it back the fresh state and trust the agent's next turn to notice what changed on its own?
it's re-fetch and re-derive, the 409 does not hand back the fresh state.
Re-fetch and re-derive is the answer I was hoping for, that's the version where a 409 costs a round trip instead of a silent clobber. Good to have it confirmed rather than assumed from the architecture description alone.
The negative animation-delay trick got me. Pausing every animation and steering time by hand through one custom property is such a clean answer to "export is not realtime" that I'm mildly annoyed it isn't already the standard pattern for browser compositors. Thanks for sharing!
One nice side effect of this approach is that it works with pretty much any CSS
@keyframesanimation. We simply pause the animation and drive it by updatinganimation-delayrelative to the current timeline position, so animations become a pure function of the editor's timeline instead of real time. That's what lets the preview and the export use the exact same rendering path, which is why SVG animations stay frame-accurate in both.The only small tradeoff is that staggered animations need to use a
--dcustom property instead of a fixedanimation-delay, since the engine takes control ofanimation-delaywhile scrubbing the timeline. It wasn't an obvious design choice at first, but it ended up making the whole animation system much more predictable and deterministic.How does FableCut handle complex editing tasks like multi-track audio syncing, and I'd love to hear more about your approach to AI-driven editing decisions, can you share some insights?
So audio is split across three dedicated tracks, A1 to A3, but here's the thing, every video clip also carries its own audio baked in, with its own volume and volume keyframes. Which sounds like it'd be a sync nightmare honestly, tracks plus per-clip audio all fighting for the same timeline. But it actually holds up because export never tries to record anything live. It just builds an offline mix first, every audio clip gets placed at its exact timeline position, and only after that mix is built does ffmpeg come in and stitch it to the rendered frames. So you're never fighting playback timing, the placement is just... fixed, deterministic, no drift.
That same logic is what saves you when you throw speed ramps into the mix. Slow-mo, speed-up, whatever, the audio gets time remapped right along with the video (the math is basically in-point plus the integral of speed over time, if you want the formal version), so nothing drifts out of sync even in the weird stretchy sections. And since beat markers exist too, you can actually snap your cuts to hit the beat instead of eyeballing it.
Then there's the AI editing side, which is really a different conversation but ties back to the same "nothing hidden" philosophy. The whole idea is the project file IS the interface, the agent isn't quietly deciding things you can't see. It's handed a compact JSON snapshot of where things stand, plus an analysis blueprint, shot boundaries, beats, BPM, energy per shot, where the drop lands, all pulled out with ffmpeg ahead of time. That analysis part is deterministic, it's not guessing. What's not deterministic is the creative call, which shot goes where, which cut, which effect, that's on the agent. But even those decisions get written back as plain readable JSON, so nothing's locked away, you can just open the timeline and override whatever it picked.