OpenEdit ships the Claude skill to npm and leaves the Codex and Gemini ones behind

The published tarball carries the Claude skill and not the other two

The repository holds three agent integration directories at the top level: `.claude/`, `.codex/` and `.gemini/`. That matches the three agents the page says are supported, Claude Code, Codex and Gemini CLI, and the first run is described as registering a session hook in the settings of all three.

The published file list has four entries: `cli/dist`, `.claude/skills/open-edit`, `LICENSE` and `NOTICE`.

So the npm tarball contains the Claude skill directory and nothing equivalent to it for Codex or Gemini. `LICENSE` and `NOTICE` are both included, which is better than most packages manage, and `cli/dist` is the compiled command, so a consumer gets the binary. What a consumer does not get is two of the three integrations the documentation promises.

Two more entries in the manifest are worth reading alongside that. There is a `packageManager` field pinning pnpm at 10.16.1, and a `publishConfig` that sets public access and a scoped registry override pointing at `https://registry.npmjs.org` for the `@veedstudio` scope. There is no `version` field in the manifest at all, so the published version number does not live in the file that describes the package.

The root test script points at a tests directory that is not in the repository

The scripts block has five entries, and two of them run tests.

`test` is a Node test runner invocation with `tsx` loaded through the import flag, pointed at a `tests/` path with a double star and a `.test.ts` suffix, and `test:cli` does the same against `cli/tests/`. The glob is quoted in both, which matters: quoting keeps the shell from expanding the pattern and hands it to the runner intact.

The problem is the root target. The repository's top level contains `.claude/`, `.codex/`, `.gemini/`, `.github/`, `AGENTS.md`, `AUTHORS.md`, `CLAUDE.md`, `CODEOWNERS`, `LICENSE`, `NOTICE`, `README.md`, `SECURITY.md`, `SETUP.md`, `cli/`, `config.ts`, `docs/`, `package.json`, `pnpm-lock.yaml` and `tsconfig.json`. There is no `tests/` directory there.

So `test:cli` has a target and `test` does not. Running the root test script on a clean checkout either reports zero tests or fails on the missing path, and nothing in the documentation mentions a second test suite, because there is only the one under `cli/`.

The type check side is in better shape, with a root `tsc --noEmit` and a separate `tsc -p cli/tsconfig.json --noEmit` for the CLI project. The build is not `tsc` at all, it is `node cli/scripts/build.mjs`, a custom script.

Links in the readme point one directory above the repository

The page sits at the repository root, and several of its links are written as if it sat one level down.

The header logo is referenced as `../docs/logo/dark.png` and `../docs/logo/light.png`, and the licence badge points at `../LICENSE`. The section describing how the tool works says the CLI reference is listed in `../README.md`. All four of those are parent-relative paths.

From a file at the root of a repository, a leading `../` resolves outside the checkout, so the logo, the licence badge and the CLI reference all point at a location that does not exist for anyone who cloned the project. The `docs/` directory is in the tree, and so is `LICENSE`, so the targets are one level too high rather than missing.

It is a small defect, and it is the kind that a renderer on a hosting site may paper over while a terminal or an IDE does not. It is worth knowing if you arrived here because a link did not resolve, because the content you were looking for is present and the path is wrong.

The same section is otherwise the clearest statement of the architecture on the page: the skill gives your agent tools and leaves the design to it, transcribing with real per-word timings, composing the piece as an HTML page, rendering frame by frame in a browser, looking at the frames and fixing what it sees.

Hosted transcription stores your file and local transcription does not

Transcription is asked once and remembered, and there are three routes with materially different consequences.

The hosted route is described as transcribing best, and it needs a veed.io account. The free tier is stated as covering about ten minutes a month. The privacy detail is stated plainly: hosted transcription uploads the file in order to transcribe it and stores it for that purpose.

The local route is WhisperX, which runs for free, needs `uv` or `pipx`, and downloads the model on first transcription, about 2 GB for the fast tier and more for the better one. Nothing leaves your machine.

The third route is to bring your own service. Any Whisper-family JSON is accepted, and the page states that no credentials pass through OpenEdit.

All three providers write the same file, `runs/<key>/transcript.json`, and the page states that per-word timings are required: without them the caption reveals drift, so a transcript that has none is refused rather than rendered badly.

That last behaviour is the useful one to know before your first run. A refusal with a reason is much easier to debug than a hundred milliseconds of accumulating subtitle lag, and it is the one place where the pipeline is documented as choosing to fail.

Three platforms, three installer behaviours and an unchecked macOS version

The requirements table gives a different answer for every platform.

The install itself is one command run from the project folder, which pins the skill into that project rather than into a global agent configuration:

npx skills add veedstudio/open-edit --skill open-edit

macOS is built and tested on Tahoe 26.0, and the table says in the same cell that nothing checks the version, so earlier releases may work untested. That is a stated absence of a gate: an older macOS produces a warning nobody will see rather than a refusal.

Windows requires Windows 10 or newer, and the installer extracts with the bundled `tar` rather than a system tool. Node is expected to come from winget, and the table says init prints the exact command and never runs it itself. ffmpeg is fetched into the user folder with no admin rights needed. Git is optional and used to version your project when present.

Linux is given as supported, with the cell cut off there.

The first run behaves differently again on each platform. On a Mac it installs missing tools through Homebrew once you approve. On Linux and Windows it prints the commands for you to run, except that on Windows ffmpeg is fetched into your user folder for you. So on macOS one prompt is enough, on Linux you run everything yourself, and on Windows the agent handles one binary and leaves the rest to you.

The rest of the first run is the same everywhere: it checks for Node and ffmpeg, pins itself into your project as a dev dependency, registers the session hook, asks once about transcription, and downloads the rendering browser into your user's app data folder on the first render.

The launch video was made with an agent outside the supported three

The flagship example is captioned as made in OpenEdit with GPT-6 Astra driving the pipeline, described as pure motion graphics with no source footage, prompted against a brand film used as a visual reference.

GPT-6 Astra is not among the three agents the page says to install. The requirement is one of Claude Code, Codex or Gemini CLI, and the install command names a skill for the agent rather than a model. The three integration directories in the tree are the same three names.

So the flagship output was produced by driving the pipeline with something outside the documented support surface, which is a reasonable thing for the authors to do and a useful thing for a reader to know. It means the example demonstrates the pipeline rather than the supported configuration, and it does not tell you what happens when the agent is one of the three listed.

The other example prompts are closer to the supported path. One asks for viral subtitles plus translation into five languages with a lip sync model on a third party platform, one asks for three generated hooks in a video model on that platform plus motion graphics, and one asks to use a Figma MCP server to study a brand book and produce campaign cards. The last two pull in external generators, which is the pattern the page describes as its intended extension: any AI video or image generator, or any MCP server, when it helps.

Two runtime dependencies and a browser fetched on the first render

The dependency list is short enough to be the whole architecture. There are two runtime entries: `playwright-core` pinned to exactly 1.63.0, and `undici` at a caret range of 7.

`playwright-core` is the driver, not the browser. The page says the first render downloads the browser it renders with into the user's app data folder, which is what the core package expects: the library and the browser binary are separate downloads. So the first render of a project is a network operation whether or not the agent model is local.

The development entries are `@types/node` at a caret 22, `tsx` pinned to 4.21.0 and `typescript` at a caret of 7.0.2. The type stubs at 22 sit against an `engines` floor of 20.18.1, so code can typecheck against an API surface that the minimum supported runtime does not have.

The manifest's remaining shape is worth noting for anyone automating it. The bin is `openedit` pointing at `cli/dist/cli.js`, `type` is `module`, and there is a single package name, `@veedstudio/openedit-cli`, described as the Open Edit command line tool. The repository is `open-edit`, the skill is installed under the name `open-edit`, and the executable is `openedit`, so the three names in play are not the same string.

Nothing outside ffmpeg and a browser is a dependency, which is the point of the design: the pipeline shells out to media tools and drives a renderer, and the agent supplies the decisions.

Editorial conclusion

OpenEdit is worth trying if your editing work is text-shaped, which for subtitles, lower thirds, title cards and re-cutting a clip it very much is. The design bet is that a language model can drive a browser rendering an HTML page, look at the frames it produced, and fix what it sees, and the incremental re-render after a change is what makes the iteration loop affordable. The output is inspectable in a way a closed tool is not, because the thing that made the video is written next to it under `runs/`.

Three packaging facts should be checked before you rely on npm. The manifest publishes `.claude/skills/open-edit` and not the `.codex/` or `.gemini/` directories, so a tarball install gets the Claude Code integration only. The root `test` script globs a `tests/` directory that is not in the repository, so `npm test` at the root has nothing to run. And the package manifest carries no version field, while the repository's only release is a media bucket called `launch-examples` from 2026-08-03 that exists so the example videos can be linked.

The decision with real consequences is transcription. The hosted option is described as the most accurate and it uploads your file to be stored for that purpose; WhisperX runs locally with nothing leaving the machine, at the cost of a model download of about 2 GB for the fast tier. That is asked once and remembered, so pick it deliberately. Generative work such as a talking head from a script is a separate, billed feature that quotes its price in workspace credits before spending anything.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. veedstudio/open-edit on GitHub