# Mortiflix: a gated video pipeline where a Claude session stops for your review > Mortiflix is an AGPL-3.0 motion design harness that drives a video project through a fixed sequence of brief, script, style frames, animatic, build and final, and it stops a Claude session at every gate so a human can approve, pin notes on an exact frame and answer questions. It runs against your own Claude Code login or your own Anthropic API key, and the review room is a local web studio on port 4646. **GTKottman/mortiflix-oss** — A motion design studio on your own machine: Claude makes the video step by step, you approve every stage. Bring your own Claude Code or API key. - Repository: https://github.com/GTKottman/mortiflix-oss - Stars: 652 · Forks: 28 - Language: JavaScript - License: AGPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/gtkottman-mortiflix-oss ## The pipeline shape is the whole argument The README opens by contrasting Mortiflix with the usual category of tool. Most AI video tools are one prompt and a slot machine. Mortiflix works like a real motion design studio: a brief, a script, style frames, a transition board, an animatic, a final, and you review each stage before the next one starts. That sequence is drawn in the README as a pipeline diagram, and the arrows underneath are the important part. The arrows go back to you at every stage, and the caption says it plainly: approve, pin notes, answer questions, with the session stopping at every gate. So the design decision is not which model makes the video. It is where the human sits in the loop and what the human is asked to do at each point. In most generative pipelines the human is asked to accept or reject a finished artefact, which is a poor position because the cost of a rejected video is the whole video. In Mortiflix the human is asked to review a script, or a set of style frames, or an animatic, which is cheap to reject and cheap to correct, and the corrections are structured rather than free-form. The project describes itself as built for one person. You write the briefs, you review every stage, and the studio runs on your machine. That is a clear statement about scope, and it is a meaningful one: this is not a team pipeline with roles and queues, it is a single designer handing work to an agent and reviewing it. The underlying technology is JavaScript, the project is described as a motion design studio on your own machine, and the topics list remotion and harness alongside video and motion-design, which is a fair summary of what sits underneath. ## Sessions end at gates, and the journal carries the project The Why it's built this way section gives four reasons, and the first is the mechanism that makes the whole thing work. Sessions end at gates. A Claude session works until it has something for you to review, submits it, writes a handoff and stops. When you respond, a fresh session picks up from the journal. The claimed benefit is stated in the project's own terms: waiting on you costs nothing, for hours or for days. That is a genuinely different approach to agent orchestration. Instead of one long-lived session that holds a whole project in its context, each unit of work is a session that ends cleanly and leaves a written record behind. The next session reads the journal and continues. It means a review can happen over lunch, and it means the state of a project lives in files on disk rather than in a context window that has to be kept alive. The second reason is about where the rules live: in code, not in the prompt. Only you can approve a step you review. A submission is refused if it doesn't report every error check for its kind of work, or if it doesn't answer each note you left on the last version. And then the strongest claim in the section: what you reviewed is copied out of the session's reach, so it can't change afterwards. That last point addresses a real failure mode of agent workflows. If the reviewed artefact stays inside the session's reach, a later session might quietly revise it, and your approval would refer to something that no longer exists. Copying the reviewed version out makes approval meaningful. The third reason is that it learns your studio. When you point out a real mistake, the session proposes a new check, such as text never touches the frame edge. Approve it once and every future video runs it. Your taste carries across projects in a file called TASTE.md. The fourth is that pipelines are folders. A pipeline is a pipeline.json holding the steps, how each is reviewed and the error checks, a PIPELINE.md holding the craft, and skills. Anyone can write one, and the README says that is the point of open-sourcing it. ## Installing it and running the demo first The quick start is honest about the platform situation, which is worth reading before anything else. The project is tested mostly on Linux so far. A Windows version is coming in the next two weeks, by October 20, 2026, with the installer ready and sessions next, documented in docs/WINDOWS.md. macOS should mostly work but has not been tested yet. The dependencies are Node 20 or newer and ffmpeg. For real videos you also need one of two things: Claude Code, logged in, so your plan pays, or an Anthropic API key, so you pay per token. The install itself is four commands: ```sh git clone https://github.com/GTKottman/mortiflix-oss.git && cd mortiflix-oss npm install npm link # puts `mortiflix` on your PATH (or use: node bin/mortiflix) ``` And then the three commands that set you up: ```sh mortiflix init # makes the studio folder (~/Mortiflix) and picks a backend it finds mortiflix setup # the walkthrough: Claude, narration, music, assets, 3D (asks before installing anything) mortiflix demo # a full walk-through with placeholder work: free, no Claude needed ``` The demo is the interesting one for an evaluation, and it is free with no Claude needed. The demo backend is described as a scripted stand-in that walks every gate with placeholder frames and a test-pattern video. So you can see the entire gate and review loop, with the reviewer in the right seat, before spending anything. The setup step's parenthetical is also a good sign about the project's manners: it asks before installing anything. The same care shows up in the Claude Code plugin section, where the guide asks before it installs anything, opens a port or starts paid work, and where only read commands are pre-allowed so your Claude Code permission settings apply to everything else. The package metadata is consistent with the README. The package is mortiflix at version 0.1.0, licence AGPL-3.0-only, requiring Node 20 or newer, with a single runtime dependency on the Anthropic SDK and two binaries, mortiflix and mfx. The test script runs the Node test runner over a test/ directory. ## Three ways to work with it, and the browser one is the interesting one After setup, the README offers three ways to drive the studio, and they are not equivalent alternatives. The terminal way is the plainest. mortiflix new explainer asks the brief's questions, mortiflix run lets sessions run until something waits on you, mortiflix review is where you read the note, answer questions, pin notes and approve or ask for changes, and then mortiflix run again, and so on until it is delivered. The browser way starts a local web studio: ```sh mortiflix serve # http://127.0.0.1:4646 ``` The web studio shows what is waiting on you, a live log of what Claude is doing, and the review room: you click a frame to pin a note, pause a video to note a moment, comment on a paragraph of the script, answer the session's questions, and approve. Sessions start by themselves while serve is running. That review room is the feature that makes the pinning story work, because pinning on an exact spot of a frame or an exact moment of a video is not something a text chat does well. A note that says the text touches the frame edge is useless without a coordinate. And the note is answered by the next version one by one, with what changed shown to you, which is a tighter feedback loop than re-prompting. There is a network exposure consideration, and the README handles it explicitly. To use the studio from another device, run mortiflix serve with a host of 0.0.0.0, and you then get a private link with an access token, and you should put it behind HTTPS if it leaves your network. The third way is inside Claude Code itself, as a plugin: ``` /plugin marketplace add GTKottman/mortiflix-oss /plugin install mortiflix@mortiflix /mortiflix ``` The slash command walks you through everything in the conversation, covering setup, the demo, a new video's brief and running the studio. At each gate it shows you what the session sent, opens the frames and videos, and turns what you say into pinned notes, reading them back to you before sending. And the important boundary: your Claude Code conversation is the guide, not the studio. The video is still made by the studio's own sessions, behind the same gates. The guide asks you at every gate and is told never to decide one for you. Keys never go into the chat. ## Backends decide who pays and how the work is done The backends table is the part of the README that matters most for cost and for control, because the three options are not the same thing with different prices. The claude-code backend runs claude in print mode in the project folder, with your login, and your Claude plan pays. In practice that means the existing Claude Code binary does the work and the harness drives it. The anthropic-api backend is Mortiflix's own agent loop on the Claude API, and the table enumerates what that buys: a persistent shell, a file editor that can show Claude the frames it renders, web search, prompt caching, and compaction for long sessions. The persistent shell and the frames-rendering editor are the two that matter for motion design, because generating a video means looking at the output and adjusting it, and the compaction matters for a long render. The cost is your API key, per token. The demo backend is a scripted stand-in that walks every gate with placeholder frames and a test-pattern video, and nobody pays. You pick one with mortiflix init with a backend option, with mortiflix config backend, or from Settings in the web studio. Since init picks a backend it finds, you can let it choose and change later. The cost reporting is the feature I would point an evaluator at. Each project shows what its Claude work cost. On a Claude plan, the figure is what it would have cost at API prices, and the note is that you did not pay that. With an API key through Claude Code, it is about what you spent. That is careful honesty about a confusing area. Plan-based and token-based billing produce different numbers for the same work, and showing a single number without saying which one it is would be misleading. ## Keys stay out of the chat, and the licence is AGPL The Your keys section is short and makes one important architectural point: Mortiflix runs on your own accounts, there is nothing to sign up for. mortiflix init asks for your keys, and mortiflix keys changes them at any time, with Settings, Keys in the web studio doing the same. The keys listed are an Anthropic API key, only for the anthropic-api backend since Claude Code uses your own login, and an ElevenLabs API key, only for ElevenLabs narration. The section continues past what the README excerpt shows, but the pattern is clear: each key is tied to a specific capability, and you only supply the ones your project actually uses. The separation between the guide and the studio extends to credentials. Keys never go into the chat. You add them with mortiflix keys in a terminal, or in Settings, Keys. That is a sensible boundary, because a chat transcript is a place where credentials end up in logs, and a local studio with a key file is a place where they do not. The licence is AGPL-3.0-only, confirmed in both the repository listing and the package.json. That is the copyleft licence with network use attached, so if you run a modified Mortiflix as a service for other people, the obligations reach them. For a personal tool that runs on your own machine and talks to your own accounts, it is not the constraint it would be for a hosted product, but it is the constraint it would be if you were planning to run it for a team over a network, and the README's mention of a private link with an access token for other devices is a reminder that the tool can move beyond one machine. The repository has no GitHub releases and the last push was on 2026-10-21, so this is an early, actively developed project at version 0.1.0. ## Pipelines as folders, and what to look at before you rely on it The most extensible idea in the project is that a pipeline is a folder. A pipeline.json holds the steps, how each is reviewed, and the error checks, a PIPELINE.md holds the craft, and there are skills alongside. Anyone can write one, and the README is explicit that that is the point of open-sourcing it. This is a design with real reach, because the pipeline is where the domain knowledge lives. A brief step, a script step, a style frame step and an animatic step have different error checks and different review criteria, and encoding that in a versioned folder means a studio's process can be shared, forked and improved by someone else. The TASTE.md mechanism, where a lesson learned on one video becomes a check that runs on every future video, is the same idea applied to judgement rather than process. The directory layout supports the reading that this is a complete application rather than a script collection: a bin/ directory with the two binaries, src/ for the source, web/ for the web studio, pipelines/ for the shipped pipelines, harness/ for the agent harness, vendor/ for vendored code, plugin/ and .claude-plugin/ for the Claude Code plugin, docs/ for documentation including docs/WINDOWS.md, plus an OVERVIEW.html, install.ps1 for the Windows installer, CONTRIBUTING.md and LICENSE. The honest limits are the ones the README states. The project is tested mostly on Linux, macOS is untested, and the Windows version is promised rather than shipped. It is at version 0.1.0 with no tagged releases. It needs ffmpeg, and real video work needs either a Claude Code login or an API key, so there is a cost floor even for a first look, though the demo backend exists to avoid that. And the fundamental constraint is the one the design chose: nothing moves without you. For a single designer who wants to be in charge of every frame, that is the feature. For anyone hoping to queue up fifty videos, it is a wall. ## Conclusion Adopt Mortiflix if you make motion design videos one at a time and want an agent to do the work in reviewable stages rather than in one prompt, and if you are willing to be the reviewer at every gate, since the gates are the product. Do not adopt it for batch or unattended video generation, because a session ends when it has something for you and a fresh session resumes from the journal, so nothing progresses without you. Before you commit, run mortiflix demo first, which walks every gate with placeholder frames and needs no Claude at all, decide whether the claude-code backend or the anthropic-api backend suits how you are billed, and note that the project is tested mostly on Linux, that macOS is untested, and that the licence is AGPL-3.0-only. ## FAQ ### What is Mortiflix and what does it do? It is an AGPL-3.0 motion design studio that runs on your own machine, driving a video through a brief, a script, style frames, an animatic, a build and a final, with a Claude session stopping at every stage for your approval, pinned notes and answers to questions. It uses your own Claude Code login or your own Anthropic API key. ### How do I install Mortiflix and try it without paying for anything? Clone the repository, run npm install and npm link, then run mortiflix init, mortiflix setup and mortiflix demo. The demo backend walks every gate with placeholder frames and a test-pattern video, so it needs no Claude at all. You need Node 20 or newer and ffmpeg. ### What is the review room in the Mortiflix web studio? It is the part of the local studio served by mortiflix serve on http://127.0.0.1:4646 where you click a frame to pin a note, pause a video to note a moment, comment on a paragraph of the script, answer the session's questions and approve. The next version then answers every note one by one and shows what changed. ### What are the Mortiflix backends and who pays? The claude-code backend runs claude -p in the project folder with your login and your Claude plan pays. The anthropic-api backend runs Mortiflix's own agent loop on the Claude API with a persistent shell, a frames-rendering file editor, web search, prompt caching and compaction, and your API key pays per token. The demo backend is a scripted stand-in that nobody pays for. ### How does Mortiflix remember my preferences across projects? When you point out a real mistake, the session proposes a new check such as text never touches the frame edge. Approve it once and every future video runs it, and your taste carries across projects in a file called TASTE.md. Pipelines themselves are folders holding a pipeline.json, a PIPELINE.md and skills. ## Sources - [GTKottman/mortiflix-oss on GitHub](https://github.com/GTKottman/mortiflix-oss) - [Issues](https://github.com/GTKottman/mortiflix-oss/issues) - [License: AGPL-3.0](https://github.com/GTKottman/mortiflix-oss/blob/main/LICENSE) - [README](https://github.com/GTKottman/mortiflix-oss/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/gtkottman-mortiflix-oss