OpenChatCut: AGPL-Videoeditor, dessen Agenten in eine echte Mehrspur-Zeitachse schreiben

Eine ChatCut-Alternative, die das Ergebnis weiter bearbeitbar hält

0xsline/OpenChatCut beschreibt sich selbst als quelloffene ChatCut-Alternative und weist ausdrücklich darauf hin, unabhängig und nicht mit dem kommerziellen Produkt ChatCut verbunden zu sein. Der Anspruch lässt sich in einer Formel zusammenfassen, die das README selbst aufstellt: lokale Videoprojekte plus Mehrspur-Zeitachse plus KI-Agenten plus MCP plus exportfertige Ergebnisse.

Der interessante Teil ist die Abgrenzung, die das README gleich mitliefert. Es gehe nicht darum, ein Video zu erzeugen, das danach niemand mehr ändern kann. Jede Bearbeitung wird in Spuren, Clips, Übergänge, Untertitel, Effekte und Medien des Projekts geschrieben. Wer mag, bearbeitet danach von Hand weiter, macht Schritte rückgängig, speichert Versionen oder übergibt das Projekt an einen anderen Agenten.

Für die Einordnung hilft die Tabelle im README, die drei Spalten gegenüberstellt: klassischer Zeitachsen-Editor, Einmal-Videogenerierung und OpenChatCut. Präzision auf Clip-Ebene besitzen der klassische Editor und OpenChatCut, die Generierung nicht. Änderungen in natürlicher Sprache erlauben die Generierung und OpenChatCut. Die direkte Steuerung über Codex oder Claude Code bietet laut Tabelle ausschließlich OpenChatCut, und zwar über MCP.

Der Bearbeitungskreis und die Sitzungen externer Agenten

Das README zeichnet den Ablauf als Kette: Ziel beschreiben, Agent liest das Projekt, erzeugt prüfbare Änderungen, schreibt in die Zeitachse, dann Vorschau, Anpassung, Rückgängig, Untertitel und Abmischung, schließlich Export. Auffällig ist das Wort prüfbar, denn es zieht sich durch den Rest der Dokumentation.

Externe Agenten arbeiten laut README über Bearbeitungssitzungen. Eine Sitzung beginnt, Änderungen werden auf einen isolierten Entwurf angewendet, die Sitzung wird geprüft, und danach wird der Vorschlag genehmigt oder verworfen. Im manuellen Modus sieht ein Mensch den Vorschlag im Editor und gibt ihn frei. Im Automatikmodus wird der vollständige Entwurf nach der Prüfung direkt angewendet.

An dieser Stelle liegt eine Entscheidung, die man bewusst treffen sollte. Der Automatikmodus nimmt dem Arbeitsablauf die Wartezeit, nimmt aber auch die letzte Kontrolle vor dem Anwenden. Das README beziffert nicht, wie groß ein solcher Entwurf werden kann, und nennt keine Obergrenze für gleichzeitige externe Agenten an der MCP-Brücke.

Mehrspur-Zeitachse, Wort-Transkript und Gesichtserkennung im Browser

Die Zeitachse ist nach README-Angaben mehrspurig für Video und Audio und beherrscht Bewegen, Trimmen, Schneiden, Ripple-Edit, Fangfunktion, Keyframes, Marker sowie Rückgängig und Wiederholen. Übergänge, Effekte, LUTs und Zooms gehören zum Umfang. Das ist der Bestand, den man von einem Schnittwerkzeug erwartet, und er ist hier die Bedingung dafür, dass ein Agentenvorschlag überhaupt sinnvoll landen kann.

Darüber liegt eine transkriptgesteuerte Arbeitsweise: Transkription auf Wortebene, Schnitte über Text, Behandlung von Pausen, Erkennung von Sprechern und daran hängende Untertitel. Für Interview- und Screencast-Material ist das der Weg, auf dem Spracheingabe praktisch wird, weil sich ein Schnitt auf eine Textstelle beziehen kann statt auf eine Timecode-Angabe.

Der dritte Teil ist ungewöhnlicher. Das README beschreibt visuelle Geometrie im Browser: Personensegmentierung und gesichtssichere Zonen, Untertitel, die dem Sprecher ausweichen, ein Reframe, das dem Motiv folgt, und Overlay-Grafiken, die in freie Flächen gesetzt werden. Wie zuverlässig die Segmentierung bei mehreren Personen arbeitet, steht dort nicht.

WebGL-Effekte, Motion Graphics und die Exportkette über Remotion

Auf der Bildebene listet das README WebGL-Effekte auf, darunter Pixelierung, Duotone, Fischauge, Kaleidoskop, Weichzeichnung und Lichtlecks. Kamerabewegungen wie Push, Pull, langsamer und schneller Zoom sowie Kurven mit Easing arbeiten direkt mit der Zeitachse. LUTs lassen sich gegen ein festes Referenzbild vergleichen.

Motion Graphics sind als bearbeitbare Vorlagen angelegt, ergänzt um eigene Shader. Nach README läuft Shader- und Motion-Graphics-Code in einer eingeschränkten Sandbox. Das ist eine sinnvolle Grenze, weil hier fremder Code auf Medien angewendet wird; Details der Sandbox nennt das Material nicht.

Für die Ausgabe sind MP4, Audio, Untertitel, FCPXML und vollständige Projektdaten angegeben. Die Pipeline nutzt Remotion, FFmpeg, FCPXML und SRT, die Vorschau den Remotion Player. FCPXML ist dabei der Eintrag mit dem meisten Gewicht für Profis, weil er den Übergang in andere Schnittanwendungen öffnet. Ob dieser Übergang verlustfrei gelingt, dazu schweigt das Material.

EditorCore, ~/.openchatcut und der MCP-Endpunkt auf Port 5199

Die Architektur ist im README in Schichten beschrieben. Das Frontend setzt auf React 19, TypeScript 6 und Vite 8, der Bearbeitungskern arbeitet mit unveränderlichem Zeitachsenstatus, einer Befehlsschicht und vorgeschlagener Anwendung. Die Agentenschicht nutzt das Vercel AI SDK 7 sowie Agent Skills. Als Desktop-App dient Electron 43.

Agenten verändern Projekte nach README nur über EditorCore-Befehle. Genau daraus folgt die Nachvollziehbarkeit: Was über Befehle läuft, lässt sich protokollieren und rückgängig machen. Ein Agent, der direkt in Projektdateien schreibt, hätte diese Eigenschaft nicht.

Gespeichert wird unter anderem in einem gemeinsamen lokalen Projektspeicher unter ~/.openchatcut, ergänzt um einen IndexedDB-Cache und ein konfigurierbares lokales Medienverzeichnis. Für externe Agenten stellt das Projekt einen Streamable-HTTP-MCP-Endpunkt unter http://localhost:5199/api/external-mcp/mcp bereit, die Datei .mcp.json im Wurzelverzeichnis enthält die lokale Verbindung bereits. MCP bindet standardmäßig lokal, öffentliche Endpunkte unterstützen die Authentifizierung mit Bearer-Token.

AP-Schlüssel serverseitig und Node.js 24.x für den Quellbetrieb

Zum Datenmodell sagt das README zweierlei. Projekte, Chatverlauf und Versionen liegen im lokalen Speicher, Medien in einem lokalen Verzeichnis, das sich sichern oder umziehen lässt. Ob Anfragen den Rechner verlassen, hängt davon ab, welche Modell-, Generierungs- oder Mediendienste konfiguriert werden. Diese Abhängigkeit ist der Punkt, an dem sich die Zusage lokaler Datenhaltung relativiert, und sie wird im README offen benannt.

Für den Schlüssel-Transport gilt eine klare Regel: API-Schlüssel bleiben serverseitig konfiguriert und dürfen nicht über Variablen mit dem Präfix VITE_ an den Browser gegeben werden. Das ist weniger eine Komfortfrage als eine Sicherheitsgrenze, weil ein Wert mit diesem Präfix im Frontend-Bundle landet.

Wer aus dem Quellcode arbeitet, braucht Node.js 24.x und npm, wobei der unterstützte Bereich aus package.json erzwungen wird und eine .nvmrc die passende Hauptversion für Versionsmanager festlegt. Der Entwicklungsserver läuft auf Port 5199. Der Beitragsleitfaden verlangt einen Zweig von main, eine ausführbare Prüfung für nicht-triviale Logik sowie npm test, npm run lint und npm run build vor dem Commit, bei UI- oder Videoänderungen zusätzlich Screenshots oder Abnahmenachweise.

AGPL-3.0 und was das Material offenlässt

Das Repository ist unter AGPL-3.0 lizenziert, das README formuliert es als Version 3.0 oder später. Für Netzwerkserversoftware verlangt diese Lizenz, dass eine geänderte Fassung, die öffentlich über ein Netz erreichbar ist, ihren Nutzern den Quellcode zugänglich macht. Bei einem Editor, den man üblicherweise lokal betreibt, greift das vor allem dann, wenn man eine angepasste Fassung als Dienst anbietet. Komponenten und Assets Dritter stehen nach README unter ihren jeweiligen Lizenzen, was bei Remotion und FFmpeg relevant wird.

Was das Material nicht belegt, ist mehreres. Es gibt keine Angabe zu Testabdeckungszielen oder zur CI-Konfiguration, keine Hardware-Empfehlung für lokales Rendering und keine Aussage darüber, wie viele Agenten die MCP-Brücke gleichzeitig bedienen kann, nur dass sie für einen Nutzer auf einem Rechner ausgelegt ist. Welche Modelle der Agent ansprechen kann, bleibt offen.

Zur Reife lässt sich immerhin der Release-Takt heranziehen, ohne ihn als Qualitätszeichen zu lesen: v0.2.9 am 20. August 2026, v0.2.10 am 24. August und v0.2.11 am 25. August 2026. Drei Veröffentlichungen in sechs Tagen, alle in der 0.2-Reihe. Wer produktiv damit arbeitet, sollte ein Projektformat einplanen, das sich noch ändern kann.

Redaktionelles Fazit

OpenChatCut passt für Anwender, die ein Video projektbezogen bearbeiten wollen, dabei sowohl per Spracheingabe als auch von Hand arbeiten und die Exporte in anderen Werkzeugen weiterverwenden, sowie für Entwickler, die Codex oder Claude Code über den Endpunkt auf Port 5199 anbinden möchten. Weniger geeignet ist es für Teams, die gleichzeitig an einem Projekt sitzen, weil die MCP-Brücke laut README für einen einzelnen Nutzer auf einem Rechner gedacht ist, und für Umgebungen, in denen die AGPL-3.0-Pflicht zur Offenlegung geänderter Quellen bei Netzbetrieb nicht tragbar ist. Auf die Prüfliste vor dem ersten ernsthaften Projekt gehören drei Punkte: ob der manuelle Modus bei Agentenvorschlägen genügt statt des Automatikmodus, wohin die konfigurierten Modell- und Mediendienste Anfragen senden, und ob ein Export nach FCPXML in der eigenen Schnittanwendung unverändert ankommt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes