Timeline Studio: a browser video editor where agents and humans share one timeline

The problem is not AI editing, it is the second timeline

Most AI video tools are one-shot generators. You write a prompt, you get a clip, and the moment you want to change one cut you are back in a conventional editor with none of the generation context. Timeline Studio takes the opposite position. It is a multi-track timeline first, described in the README as CapCut-style, and the AI features are operations that write into that timeline rather than replace it. Voiceover lands on an audio track. Generated music is inserted into My Assets. Captions, repair regions and markers are timeline objects with times and undo history. The intended user is a creator who wants local inference and does not want to hand the edit over to a black box, plus a second user type the project takes seriously: an AI agent that needs to read and modify a real project rather than produce a finished file. The README frames the whole thing as local-first, which here means the models run in the browser through WebGPU and WASM instead of on a vendor's GPU. That choice is what makes the agent story coherent, because the project state never has to leave the machine to be edited.

One command engine, three front doors

The architectural detail that matters is stated plainly in the September 10, 2026 update: the browser adapter for WebMCP reuses the shared command engine, checks for concurrent edits before applying, and preserves editor undo. That single sentence describes the whole design. Edits are commands, not direct mutations of UI state. The same command layer is reachable from the Skill, from a CLI, and from MCP, according to the release notes for v1.0.7 and the project updates. Markers are the clearest example of the data flow: an agent can read, add, update and delete timeline markers, and the README says markers stay at project time, are saved in portable .timeline projects, and support undo and redo. Project inspection and semantic diff previews happen before changes are applied, so an agent proposes a plan and a human reviews it. The concurrency check is the part worth pausing on. If a person drags the playhead or trims a clip while an agent is preparing a reorder, the adapter is designed to notice and refuse rather than merge silently. That is a conservative choice, and it is the right one for a timeline, where a merged conflict produces a wrong cut rather than a visible error.

Getting it running: the browser is the runtime

The README gives a Live Demo URL and a Hugging Face Space, and states that the root URL opens directly into the editor. There is no install command in the supplied material, no npm script, and no Docker instructions, so anyone expecting a local dev server setup will have to read the repository itself; I cannot confirm a build path from what is here. What the material does confirm is the shape of the runtime. Models are lazy-loaded, revision-pinned and cached, per the local-first inference bullet. That matters operationally: the first run of a feature pulls a specific model revision rather than whatever is current, so a later upstream change to a model file should not silently alter your output. The feature set maps to concrete model choices. Whisper small q8 ONNX handles captions. Stable Audio 3 Small Q4 ONNX handles music, with 30, 60, 90 and 120 second options and waveform-aware looping for longer tracks. MI-GAN does watermark and object removal, NanoVSR 644K does 4x restoration, YOLOS tiny plus MODNet handle smart framing, JoyVASA and LivePortrait handle the talking avatar with 256px preview and 512px quality paths. Voiceover splits by language: Hojo TTS Light 80M FP16 for Chinese and mixed Chinese and English, Kokoro 82M for English, Piper for German, Spanish, French, Italian and Brazilian Portuguese. The division of labour between WebGPU and WASM is stated for voiceover specifically, autoregressive generation on WebGPU with waveform decoding on WASM, which suggests the project treats the two backends as complementary rather than interchangeable.

The export path is deterministic, and that is a constraint

The README calls the export deterministic and offline. Deterministic is a stronger claim than fast, and it has consequences. A deterministic renderer cannot simply drop frames when the machine falls behind, so export time scales with project length and resolution rather than with how much time the user is willing to wait. The project does not publish export benchmarks in the material I have, and I will not guess at them. What can be said is that the same design that makes the output reproducible also makes the browser tab the bottleneck, and a long 512px LivePortrait render or a 4x NanoVSR restoration pass on a full video is the kind of job where a tab that must stay in the foreground becomes an operational problem. The README does not describe a background worker or a headless mode. Anyone whose workflow is batch rendering on a server should treat that absence as the deciding factor.

Where the design gets thin

Two areas look under-specified from the outside. The first is hardware. WebGPU availability varies by browser and platform, and the README does not list a support matrix or minimum adapter requirements, only that inference runs through WebGPU. A user on a browser without it will find that the AI features are the product, so the editor degrades to a plain timeline tool. That is not a bug, but it is a fact worth knowing before you plan around voiceover or music generation. The second is the agent surface. The updates describe WebMCP, a Skill, a CLI and MCP, and mention that agent discovery and integration documentation are included, but the supplied README excerpt does not show the command names, the MCP tool schema, or the CLI flags. If you are evaluating this specifically as an agent target, the integration documentation in the repository is the thing to read, not the README. There is also a governance point the project raises itself. It carries a responsible-use section on deep synthesis, requiring that users work only with faces they own or have lawful authorization for, and that generated content not be presented as authentic footage. That is a statement of user responsibility, not a technical control, and the material shows no watermarking or provenance mechanism.

How it differs from a server-side render pipeline

The obvious alternative for programmatic editing is a scripted pipeline built on FFmpeg, where an agent writes filter graphs and the render happens on a server. The difference is not quality, it is where state lives. An FFmpeg pipeline is stateless per invocation: the agent produces a command, the command produces a file, and there is no shared timeline to inspect or to conflict with. Timeline Studio keeps a persistent project with markers, undo history and concurrent-edit detection, and pays for that with a hard dependency on a browser that supports WebGPU and WebCodecs. If your agent's job is to produce a finished asset from a spec, the FFmpeg route is simpler and runs anywhere. If your agent's job is to work alongside a person inside an edit that is still in progress, the shared command engine is the part that does not have an equivalent in a script pipeline. The trade is real in both directions, and the project has clearly chosen the interactive case.

Maintenance, licence and what the release cadence implies

The project is MIT-licensed, which permits commercial use and modification, and the repository is not archived. The release history shows v1.0.6 on August 26, v1.0.7 on September 8 and v1.0.8 on September 10, 2026, with the project updates describing shipped features between those tags. A cadence that tight means the surface you integrate against can move, and the agent-facing pieces are the newest part of it: markers for agents arrived in v1.0.7, WebMCP in v1.0.8. Pinning to a tag rather than tracking main is the practical response, and the model revision pinning the README describes already applies that same instinct to the weights. On licence, MIT covers the code, but the bundled models are separate artefacts with their own terms, and the supplied material does not enumerate them. Anyone shipping a product built on Whisper, Stable Audio, LivePortrait or the rest needs to check those model licences individually. That is not a legal opinion and it is not legal advice, just the boundary of what this repository's MIT file actually covers.

Editorial conclusion

Adopt Timeline Studio if you want browser-local inference on your own hardware and you are willing to check the WebGPU and WebCodecs support of your target browsers first, because those two browser APIs decide whether the AI pipeline and the export path work at all. Do not adopt it if you need headless server rendering or a stable plugin API, since the repository shows no such surface. Before committing, verify three things in the Live Demo: that your browser exposes the WebGPU adapter the models need, that a full export completes on a project of your typical length, and that the agent path applies a reviewed reorder plan without clobbering a concurrent manual edit.

Official sources

1. License: MIT
2. MartinDelophy/ai-video-editor on GitHub
3. Project website
4. README
5. Releases