Diffusion Studio: an open source video editor where the timeline is SolidJS code

The problem Diffusion Studio solves: agents that cannot see the timeline

Video tools built around a graphical timeline assume a human hand on a mouse. When you point an agent at the same tool, it has no stable document to read or write. It can drive menus, but it cannot reason about the edit, and it cannot tell you what changed.

Diffusion Studio takes the opposite position. The README describes the project as "The professional video editor built for agents", and the description says it plainly: edits become code, code becomes video. The document source is a set of SolidJS modules, and the README compares the arrangement to an IDE that renders a video canvas instead of text. That single decision is what makes agent editing tractable. A model reads JSX, proposes a diff, and the diff is the edit.

The audience is narrow on purpose. It fits people who already have raw footage in a folder and want a finished cut with subtitles, filler-word removal, color correction and a render, without dragging clips one by one. The README lists motion graphics, generative assets, clipping for social, and video understanding as the kinds of work people do with it. If your job is a single careful color grade on a feature film, this is not the tool you are looking for.

How the JSX timeline maps onto the editor's ECS

The mechanism is a two-way binding between files and a running scene graph. A project is a folder of JSX. Saving recompiles the entry file and mounts it into the editor's ECS, which the README describes as the entity-component-system backing the canvas. Change the code and the canvas redraws; drag a rect on the canvas and the code updates.

The write-back depends on identity. Every element carries an `id`, and the README states that this id is how the write-back finds its target: a rect dragged on the canvas, a clip trimmed on the timeline, or a retyped line lands as a prop on the element that authored it. That is the load-bearing detail. Without stable ids, a canvas gesture has no place to write itself back to, and the round trip collapses into one-way code generation.

The document tree is shallow. The root is a `<stage>`, which holds one `<scene>` per frame you cut in. Inside a scene you place media and text with `start` and `end` props measured in seconds. The README's example uses `generate.image` and `generate.video` from `@diffusionstudio/jsx` to declare generative assets, then composites them into the timeline alongside ordinary `<video>` and `<text>` elements. Generative assets are not a separate pipeline; they are values you assign to `src`.

import { For } from "solid-js";
import { generate } from "@diffusionstudio/jsx";

const hero = generate.image({ prompt: "A neon city at night, cinematic", aspectRatio: "16:9" });
const motion = generate.video({ prompt: "slow camera push-in", startFrame: hero, duration: 5 });

Note what this implies for review. A generated clip is referenced by a call that takes a prompt, not by a file path, so the diff of a prompt change is readable in a way that a re-rendered binary is not. The cost is that the timeline now depends on a generation service being reachable, which the README does not discuss.

Installing the desktop app and opening a first project

The README does not ask you to clone the repository to get started. It points at a download page for the desktop app, currently advertised for macOS Apple Silicon, and says the app walks you through setting everything up. There is also a hosted editor at app.diffusion.studio. The monorepo itself is a private workspace root (`"private": true` in package.json) with `apps/*` and `packages/*` workspaces, so building from source is a contributor path, not the documented install path.

Once the app is running, the README says it registers its MCP server with your agent, and that you can use it with Claude Code, Codex, Cursor, Copilot, or Gemini CLI. You then ask for what you want in plain language. Each session's instructions carry the editing and watching skills, so the agent reads the guidance up front rather than discovering it mid-task.

For scripted use, the README points at `dapi`, described as the same set of tools as a CLI. The documented first step is to open a folder once from a shell:

dapi open <dir>

After that you edit the JSX files directly. Saving recompiles the entry file and mounts it into the editor's ECS. What you should see is the canvas redraw to match the file. If nothing appears, the entry file is the first thing to check, since the README ties mounting to the entry file specifically and does not document a fallback for a folder with no entry.

There is also a skills package advertised in the README header:

npx skills add diffusionstudio/skills

The README shows this command without further explanation, so treat it as the agent-side skill install rather than a prerequisite for the editor itself.

Where the code-first model gets in the way

The trade-offs are real and mostly stem from the same decision that makes the project useful.

First, the round trip is only as good as the id scheme. The README states that write-back finds its target through each element's `id`, which means hand-written JSX that omits or duplicates ids is a case the documentation does not cover. If you generate a timeline programmatically, you are responsible for identity, and nothing in the README describes what happens when two elements claim the same one.

Second, the documented install is macOS Apple Silicon. The download badge names that platform explicitly, and the README does not describe a Windows or Linux desktop build. The repository has `apps/` and `packages/` workspaces and a `build:desktop` script, so other targets may exist in the tree, but the README does not promise them and I would not plan around them without checking.

Third, the agent loop assumes a local folder of media. The README's core instruction is to drop raw footage and files into a folder and ask for the video you want. If your footage lives behind an asset management system with its own review workflow, or if your organisation forbids sending media to an external model, the workflow the README describes does not apply.

Fourth, the README is silent on rollback, version history and undo semantics beyond the two-way binding itself. Since the document is plain JSX, ordinary version control covers most of that, but the README does not say so, and a canvas drag that writes back to a file is not obviously an atomic operation.

Diffusion Studio compared with scripted renderers like Remotion

The closest comparison in this space is Remotion, which also treats a video as a React component tree rendered to frames. The difference is the direction of the binding. Remotion's model is render-oriented: you write the composition, you run a render, you get a file. There is no canvas that writes back into your source, and there is no element identity scheme for mapping gestures onto props.

Diffusion Studio inverts that. The README describes editing as working both ways, with a canvas and a code document kept in sync through the editor's ECS, and it ships a desktop application with command-line tools that let agents watch and listen to footage, edit it on a timeline, and render the result. Watching and listening are the part Remotion does not attempt: the README's video-understanding examples ask for timestamps, recurring locations and visual cues from a source URL, which implies the agent has some way to inspect the media before cutting it.

The practical split: if your output is a deterministic, parameterised render that runs in CI, a render-oriented tool is simpler, because there is no editor state to reconcile. If your input is messy footage that needs to be understood, cut and then refined by hand, the two-way binding is worth the extra machinery. The README also notes a headless mode is available, which is the case where the two converge, though the README does not document its interface.

Licence, maintenance and the cost of upgrading

The repository is licensed MPL-2.0, declared both in the LICENSE file at the root and in the `license` field of package.json. MPL-2.0 is file-level copyleft: modifications to files covered by the licence stay under it, while larger works that combine those files with other code can be licensed differently. That is a meaningfully different obligation from a permissive licence, so if you plan to embed editor code in a closed product, read the licence text and get your own advice rather than relying on a summary.

Maintenance looks current. The last push was on 2026-09-14, and releases v0.205.0 and v0.205.1 both landed that day, with v0.204.2 a week earlier on 2026-09-06. The version numbers move in small increments, which suggests frequent patch releases rather than long cycles, and the root package version tracks the release tag at 0.205.1.

Upgrade cost is the part to think about before you commit. Because the document format is JSX compiled against `@diffusionstudio/jsx`, a change to the element schema or the `generate` helpers is a change to your project files, not just to a dependency. The repository keeps a `patches/` directory and runs `patch-package` on `postinstall`, which is a signal that upstream dependencies occasionally need local fixes. That is normal for a project at this stage, but it does mean an upgrade can require re-testing your compositions rather than only bumping a version.

What to check before you point it at a client project

The repository structure tells you where to look when something misbehaves. `apps/` holds the desktop and web applications, `packages/` holds the shared libraries including the JSX package, and `docs/` exists at the root, so the documented surface is larger than the README alone. The README itself is the source for the workflow, the prompt examples and the JSX sample, and it is where the `dapi open` step and the skills install command come from.

The honest summary is that this is an early, fast-moving tool with an unusual and coherent core idea. The two-way binding between a SolidJS document and a canvas is the whole product, and everything else (the MCP server, the CLI, the skills package, the generative asset helpers) exists to make that binding usable by an agent. Judge it on whether that binding holds up on your footage.

Editorial conclusion

Adopt Diffusion Studio if your footage lives in a folder, your edits are repetitive, and you want an agent to write the timeline as SolidJS that you can still open on a canvas. Do not adopt it if you need frame-accurate manual grading, or if you cannot run an agent against a local folder of media. Before committing, verify three things: that the desktop download runs on your machine, that `dapi open <dir>` mounts your folder and saving recompiles the entry file, and that the generated JSX round-trips cleanly when you drag an element on the canvas.

Frequently asked questions

Official sources

1. diffusionstudio/editor on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases