# Velocut 0.0.2 is a browser video editor whose Rust workspace still reads version 0.1.0

> Velocut puts a multitrack video editor, an editable 3D Director and a programmable project runtime in the browser, and lets Codex drive the same editing services through a pinned MCP package. The release numbers and the Rust workspace do not agree, and the development path changes engines without saying so.

**open-ribbi/velocut** — AI-native, local-first video editor by Ribbi — runs entirely in the browser. Rust/WASM engine, WebGPU compositing, WebCodecs export; humans and LLM agents edit through the same JSON command protocol.

- Repository: https://github.com/open-ribbi/velocut
- Website: https://ribbi.ai
- Stars: 454 · Forks: 0
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-ribbi-velocut

## Cargo.toml declares version 0.1.0 while every download is named 0.0.2

Two version numbers live in this project and they do not match. The workspace manifest opens with resolver = "2", a members list holding crates/velocut-core, and a [workspace.package] block whose version reads 0.1.0, with edition 2021, license MIT, and the repository field pointing back at open-ribbi/velocut. Everything a user installs is numbered lower.

The releases are v0.0.1 on 2026-09-10 and v0.0.2 on 2026-09-17, seven days apart. The starter command pins the same pair, the portable bundle unpacks into a directory called velocut-0.0.2, the Codex plugin is installed against Git ref v0.0.2, and eight packages under the @velocut scope sit at 0.0.2 on npm. So a 1.0.0 engine sits under a 0.0.2 product, or the manifest number was never revised. Nothing on the front page reconciles the two, and a bug report that quotes the engine version is quoting a different number than the one in the download URL.

Two release workflows, ci.yml and distribution.yml, sit behind the build badges, and the release carries a SHA256SUMS.txt next to the archives. Checking an archive against that file is the only integrity step the project puts in front of you.

## The dev server silently falls back to the TypeScript engine

The engine that produces the final render is Rust compiled to WebAssembly, and the engine you get while developing depends on which recipes you ran first. The task runner makes that a one liner:

```sh
setup:
    rustup target add wasm32-unknown-unknown
    cargo install wasm-pack
build-wasm:
    wasm-pack build crates/velocut-wasm --target web --release --out-dir web/apps/editor/public/wasm
dev:
    npm --prefix web run dev
```

The annotation on the dev recipe reads: editor dev server, TypeScript engine unless build-wasm has run. So a developer who jumps straight to just dev gets a working editor, on a different engine, with nothing printed to say so. The build-wasm recipe writes into web/apps/editor/public/wasm, which the same file calls a gitignored product, so the WebAssembly bundle never arrives through a checkout.

That substitution is the reason the two engines have to agree byte for byte on behaviour, and the reason the shared vectors exist rather than a pair of test suites that each cover their own ground.

## The test recipe claims both engines, but the WebAssembly crate is excluded from the workspace

The workspace manifest keeps one crate in members and puts another in exclude. crates/velocut-core is the default member. crates/velocut-wasm is excluded, with a comment giving the reason: environments without the wasm32 standard library cannot build it, so it is compiled separately with wasm-pack build crates/velocut-wasm.

The task runner then defines the test recipe as cargo test followed by npm --prefix web test, annotated as both engines against protocol/vectors/*.json, described there as the behavioral contract. Since the WebAssembly crate is not a workspace member, the cargo half of that recipe never compiles or exercises it. Running the pair as written covers the core crate and the web tests, not the crate that produces the shipped bundle.

So the safety net for engine drift needs a manual step the recipe does not perform. That is the same gap as the previous section seen from the other side: a build artifact outside version control, a crate outside the workspace, and a test command that reads as if both were covered.

## Projects are bound to the browser profile, the hostname and the port

Local storage is one of the selling points and one of the sharpest edges. Projects live in browser IndexedDB and OPFS, and the instruction is to reuse the same browser profile, hostname and port to reopen them. The studio is a local server, started either through the pinned npm CLI or by running the entry script inside the unpacked bundle, so the port is chosen at launch.

Move the port, or reach the editor through a different hostname, and the storage origin changes with it. The project list comes back empty rather than reporting a mismatch, and nothing in the documentation describes moving a project between origins. Two tabs on one origin share state, which the feature table calls same-origin multi-tab synchronization, and a third tab on a different port is a separate universe. The same table promises per-project storage and persisted history, and the Director section refers to a project document as one of the three things a human and Codex share, yet no documented path exports that document out of the browser.

For an agent workflow this is the constraint to plan around: the same profile, the same origin, every time.

## Export depends on the browser, and Safari and Firefox are out

The stated requirements are Node.js 22.6+ and Chrome or Edge with WebGPU and WebCodecs, and the two other engines are excluded by name: Safari and Firefox are not currently supported by the full editor. Compositing needs WebGPU and the export path needs WebCodecs, so this is not a preference.

The export row of the feature table promises WebCodecs encoding and MP4 muxing, with codec availability determined by the browser. That is the honest form of the claim and also the whole of it. Which encoders a given Chrome build exposes is not something the project controls, and no fallback codec, no container list, and no message for a missing encoder appear anywhere in the documentation. The AI inspection row carries the same hedge, noting that available tools depend on the host integration.

Distribution comes as velocut-standalone.zip or velocut-standalone.tar.gz under the v0.0.2 release, with the sums file alongside. The bundle carries the editor, the scene assets and a Codex plugin marketplace, so a working install needs no source checkout and no npm install.

## Two AI paths with different key requirements, and one of them is optional

Manual editing and the Codex integration need no additional model API key. That is a real design choice, and the plugin follows it: the model runs in Codex, the plugin supplies tools for scene creation, object editing, GLB import, arrangement, camera control and visual inspection, and it does not call a second language model inside Velocut. Other MCP clients can drive the same generic server.

The built-in Assistant is the other path, and it is separate and optional. It wants an Anthropic-compatible provider configured, and browser-local Whisper and VITS plus cloud generation services carry their own dependencies or credentials. None of them are needed for editing or for Codex. One detail catches portable users: development-only cloud relays are not included in the portable server, so an unpacked bundle has no relay to fall back on.

The privacy boundary is stated in one sentence and worth reading literally. Media storage and rendering stay in your browser, while AI observations and optional cloud features send the data needed by the model or provider you choose. Local first stops at the model call, and the choice of provider is what decides the rest.

## The model template paragraph ends mid-sentence and a demo block is empty

Two gaps sit in the middle of an otherwise dense feature list. The model configuration section opens properly: open Model settings in the toolbar, import a YAML or JSON model definition or ask Codex to configure one from API documentation, then enter a Base URL and an API Token. Templates are named for Task API MiniMax H3 and Seedance, for Ark content tasks, and for native MiniMax video, speech and music. Then the text stops: All templates use t. Whatever every template shares is left unstated in the English text, and a Chinese version is linked alongside as README.zh-CN.md.

The other gap is an empty element. The section about keeping the canvas usable in a small window describes bottom navigation opening the media and objects, properties, history and assistant panels, a timeline that collapses, and media inserted by clicking without dragging, and it is followed by a centered paragraph element containing nothing at all, where the demonstration of that layout belongs.

Around those gaps the behaviour claims are specific. Edits are attributed in a branching history you can inspect, undo, or return to and continue from, and revision checks reject stale AI edits when someone else has changed the scene.

## Conclusion

Velocut fits a workflow where one person drives the timeline and Codex drives the same project document, and the agreement between the two engines is enforced by a shared set of golden vectors rather than by convention. Before you rely on it, check three things in your own browser: that WebGPU and WebCodecs are present, that MP4 encoding is actually offered on your Chrome build, and that your port and hostname never move, since the project store is keyed to the origin. On the build side, treat the TypeScript engine as a development stand-in, not as the product, because the recipe that starts the dev server picks it silently when the WebAssembly build has not run.

## FAQ

### Which browsers can run the Velocut editor?

Chrome or Edge with WebGPU and WebCodecs, on Node.js 22.6+. Safari and Firefox are not currently supported by the full editor, and export codec availability is determined by the browser.

### Does the Codex plugin for Velocut need a model API key?

No. Manual editing and the Codex integration need no additional model API key, and the plugin does not call a second language model inside Velocut, because the model runs in Codex.

### Why does my Velocut project list look empty after I restart the studio?

Projects live in browser IndexedDB and OPFS, keyed to the browser profile, hostname and port, so reaching the editor on a different port or hostname shows an empty project list instead of the previous one.

### What version does the Velocut Rust workspace declare?

Cargo.toml sets version 0.1.0 in the workspace package block, while the releases, the npm CLI, the @velocut packages and the Codex plugin are all numbered 0.0.2.

### How do I install the Velocut Codex plugin?

In Codex, add a plugin marketplace with source open-ribbi/velocut and Git ref v0.0.2, optionally using the sparse paths .agents/plugins and plugins/velocut, then install Velocut and start a new task. The plugin runs the pinned npm MCP package.

### What does the built-in Velocut Assistant need that the Codex path does not?

The Assistant is a separate optional integration that wants an Anthropic-compatible provider configured, while browser-local Whisper and VITS plus cloud generation services carry their own dependencies or credentials and are not required for editing or Codex.

## Sources

- [Issues](https://github.com/open-ribbi/velocut/issues)
- [License: MIT](https://github.com/open-ribbi/velocut/blob/main/LICENSE)
- [open-ribbi/velocut on GitHub](https://github.com/open-ribbi/velocut)
- [Project website](https://ribbi.ai)
- [README](https://github.com/open-ribbi/velocut/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-ribbi-velocut