Ironclad Rivet: Graph-IDE für Prompt-Ketten und die TypeScript-Laufzeit dahinter

Welche Lücke Rivet schließt und für wen

Prompt-Logik wächst schnell über eine einzelne Zeichenkette hinaus. Aus einem Aufruf werden mehrere: eine Vorverarbeitung, ein Modellaufruf, eine Verzweigung, ein zweiter Aufruf, eine Zusammenfassung. Wer das in TypeScript von Hand verdrahtet, verliert die Übersicht über den Datenfluss, sobald Bedingungen und Schleifen dazukommen. Rivet setzt genau dort an. Das Projekt beschreibt sich selbst als IDE zum Erstellen komplexer AI-Agenten und Prompt-Ketten, die anschließend in eine Anwendung eingebettet werden. Die Zielgruppe sind damit nicht Endanwender, sondern Entwickler, die eine Kette entwerfen, ihren Verlauf beobachten und das Ergebnis als ausführbaren Graphen in eine bestehende TypeScript-Anwendung hängen wollen. Der zweite Teil ist genauso wichtig wie der erste: Rivet besteht aus der Anwendung und aus Rivet Core, einer TypeScript-Bibliothek, die von der Anwendung selbst genutzt wird, aber auch im eigenen Code laufen kann. Damit kann die Anwendung in Rivet-Graphen hineinrufen und umgekehrt. Für Teams, die Prompt-Änderungen ohne vollständiges Refactoring durchspielen wollen, ist das ein anderer Arbeitsablauf als das Bearbeiten einer Konstanten im Quelltext.

Graph, Knoten und die zwei Laufzeiten

Das sichtbare Architekturmerkmal ist der Graph. Laut README erstellt man in der Desktop-Anwendung komplexe Agenten und Prompt-Ketten und bettet sie danach in die eigene Anwendung ein. Der Graph ist also das Artefakt, das zwischen Editor und Laufzeit wandert. Ausgeführt wird er von Rivet Core, der TypeScript-Bibliothek, die auch die Anwendung selbst verwendet. Diese Doppelrolle ist der Kern des Designs: Es gibt keine zweite, abweichende Ausführungsumgebung für den Produktivbetrieb, sondern dieselbe Bibliothek in zwei Kontexten. Die Anwendung ruft in den eigenen Anwendungscode hinein, und der eigene Code ruft in Rivet-Graphen hinein. Praktisch heißt das, dass selbst geschriebene Funktionen als Knoten im Graphen auftauchen können, während der Graph an anderer Stelle die Steuerung übernimmt. Das README nennt für die Einbettung zwei Pakete: Rivet Core als @ironclad/rivet-core und Rivet Node als @ironclad/rivet-node. Welche der beiden für einen serverseitigen Node-Prozess gedacht ist und welche die plattformneutralen Bausteine enthält, lässt sich aus dem README nicht ableiten. Die Aufteilung nach Kern und Node-Hülle ist aber ein Hinweis darauf, dass nicht jeder Anwendungsfall beide Pakete benötigt.

Modell- und Vektor-Anbindungen

Rivet ist nicht modellneutral im Sinne einer offenen Schnittstelle. Das README listet die unterstützten Anbieter namentlich. Bei LLMs sind das OpenAI GPT-3.5 und GPT-4, Anthropic Claude Instant und Claude 2 sowie die Claude-3-Familie mit Haiku, Sonnet und Opus. Dazu kommt das LeMUR-Framework von AssemblyAI für Sprachdaten. Für Embeddings und Vektordatenbanken nennt das README OpenAI Embeddings und Pinecone. Als weitere Integration ist Speech-to-Text von AssemblyAI aufgeführt. Diese Liste ist der praktische Rahmen: Wer ein anderes Modell oder eine andere Vektordatenbank einsetzen will, findet im README keinen Hinweis auf einen generischen Adapter. Das ist keine Kleinigkeit, sondern eine Architekturentscheidung mit Folgen. Die Anbindung an AssemblyAI wird im README über mehrere Zeilen hinweg mit Produktlinks und einem utm_source-Parameter auf rivet geführt, was auf eine Partnerschaft oder zumindest auf eine bewusst gepflegte Beziehung hindeutet. Für die Bewertung ist wichtig, dass die Anbieterliste den Funktionsumfang begrenzt, nicht nur die Bequemlichkeit.

Installation: Binärdateien zuerst, Quellbau nur mit CONTRIBUTING.md

Der einfachste Weg führt über fertige Pakete. Das README verlinkt direkte Downloads: Rivet.dmg für macOS, Rivet.AppImage und Rivet.dmg für Linux sowie Rivet-Setup.exe für Windows. Alle vier liegen unter dem latest-Release-Pfad, ältere Stände finden sich auf der Releases-Seite. Wer aus dem Quellcode bauen will, wird ausdrücklich auf CONTRIBUTING.md verwiesen. Das README selbst beschreibt den Build nicht, nennt weder Node-Version noch Paketmanager noch konkrete Skripte. Diese Information ist also im Repository, aber nicht in der Hauptdokumentation. Für die Bibliotheksnutzung nennt das README die Paketnamen @ironclad/rivet-core und @ironclad/rivet-node und verweist für die Einbettung auf die Seite Rivet Integration Getting Started sowie auf die API-Referenz unter rivet.ironcladapp.com/docs/api-reference. Konkrete Aufrufe, Konfigurationsschlüssel oder ein Beispiel für den Aufruf eines Graphen aus TypeScript heraus enthält das README nicht. Wer die Integration plant, muss diese Seiten lesen, bevor er den Aufwand schätzt.

Getrennte Versionslinien für Anwendung und Bibliothek

Die Releases zeigen zwei Zählwerke. app-v1.11.3 vom 8. August 2025 und app-v1.11.2 vom 2. Juni 2025 sind Anwendungsversionen. v1.25.0 vom 30. Juni 2025 ist als Rivet Libraries v1.25.0 ausgewiesen, also die Bibliothekslinie. Diese Trennung ist sinnvoll, weil die Anwendung und die npm-Pakete unterschiedlich schnell wandern, sie erzeugt aber auch eine Kompatibilitätsfrage, die das README nicht beantwortet: ob eine in app-v1.11.3 gespeicherte Graph-Datei von @ironclad/rivet-core in Version 1.25.0 gelesen werden kann. Wer Graphen versioniert und über CI ausführt, sollte diese Frage klären, bevor er sich auf die visuelle Bearbeitung verlässt. Der letzte Push auf den Hauptzweig wird mit dem 26. August 2026 angegeben, das Repository ist als nicht archiviert markiert. Ob dieser Zeitstempel die Release-Aktivität widerspiegelt oder nur Aktivität am Hauptzweig, lässt sich aus dem Material nicht entscheiden.

Wo Rivet das falsche Werkzeug ist

Die Desktop-Anwendung ist Teil des Arbeitsablaufs, nicht nur ein optionaler Editor. Wer Graphen ausschließlich in CI oder in einem Container erzeugen und ändern will, hat dafür laut README keinen beschriebenen Weg. Dazu kommt die Modellkopplung: Die unterstützten Anbieter sind explizit aufgezählt, und für alles darüber hinaus nennt das README keine generische Schnittstelle. Ein Team, das ein selbst gehostetes Modell oder eine Vektordatenbank außerhalb von Pinecone betreibt, müsste diese Anbindung selbst bauen oder den Graphen an dieser Stelle aufgeben. Ein weiterer Punkt betrifft die Kosten: Jede Ausführung eines Graphen löst die darin verdrahteten Modellaufrufe aus. Ein visuell gebauter Graph macht es leicht, versehentlich mehrere Aufrufe hintereinander zu schalten, und das README enthält keine Aussage zu Caching, Wiederholungsversuchen oder Kostenkontrolle. Wer Rivet als dünnen Wrapper um einen einzelnen Modellaufruf einsetzt, trägt die Komplexität von Editor, Graph-Format und Laufzeit ohne Gegenwert.

Alternative: Code-First-Orchestrierung

Der naheliegende Vergleich ist eine Orchestrierung direkt in TypeScript, etwa mit LangChain.js. Der Unterschied liegt nicht im Funktionsumfang, sondern im Ort der Wahrheit. Bei Rivet ist der Graph das primäre Artefakt, das in einer Desktop-Anwendung entsteht und anschließend von @ironclad/rivet-core ausgeführt wird. Bei einer Code-First-Bibliothek ist der Quelltext das primäre Artefakt, und die Struktur ergibt sich aus Funktionsaufrufen. Der zweite Unterschied ist die Anbieterbindung. Rivet zählt seine Anbieter im README auf, während Code-First-Bibliotheken in der Regel breiter aufgestellt sind und neue Anbieter über Pakete nachziehen. Dafür bekommt man bei Rivet einen visuellen Verlauf und die Möglichkeit, den Graphen ohne Neubau der Anwendung zu ändern. Wer den Ablauf häufig mit nicht-technischen Beteiligten durchspricht, gewinnt dadurch Zeit. Wer die Kette in Tests, Review und Deployment wie normalen Code behandeln will, verliert sie.

Lizenz und Pflegeaufwand

Rivet steht unter der MIT-Lizenz. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Copyright-Hinweis und der Lizenztext beibehalten werden. Für eingebettete Bibliotheken in kommerziellen Produkten ist das die unkomplizierte Variante. Das README enthält keinen Hinweis auf eine separate Lizenz für die Anwendung oder die npm-Pakete, was bedeutet, dass dieselbe Lizenz für beide Teile gilt, soweit aus dem Material erkennbar. Diese Einschätzung ist keine Rechtsberatung; wer die Lizenz in einem Produkt einsetzt, sollte den Lizenztext im Repository selbst lesen. Zum Pflegeaufwand: Es gibt zwei Versionslinien, eine Anwendung und mindestens zwei npm-Pakete, dazu eine Discord-Community, Discussions und eine Issues-Seite. Ein Upgrade betrifft damit nicht nur eine Abhängigkeit, sondern das Zusammenspiel von Editor und Laufzeit. Wer Graphen im Repository ablegt, muss außerdem entscheiden, ob sie als Binär- oder Textformat versioniert werden und wie Diffs in Reviews aussehen. Das README gibt dazu keine Auskunft.

Redaktionelles Fazit

Rivet passt zu Teams, die Prompt-Logik visuell entwerfen und den fertigen Graphen über @ironclad/rivet-core oder @ironclad/rivet-node in eine TypeScript-Anwendung einbetten wollen, und die mit der MIT-Lizenz sowie der Modellkopplung an OpenAI, Anthropic, AssemblyAI und Pinecone leben können. Wer eine reine Code-Pipeline ohne Desktop-Abhängigkeit oder einen serverlosen Betrieb mit sehr kleinen Bundles braucht, sollte zuerst prüfen, wie groß rivet-core im eigenen Build ausfällt und ob der Ausführungsweg ohne die Anwendung dokumentiert ist. Vor dem Einsatz zu klären sind die Versionspflege getrennt nach app-v1.11.3 und v1.25.0 sowie die Frage, ob die Graph-Dateien im Repository versioniert werden sollen.

Offizielle Quellen

1. Ironclad/rivet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases