OpenRig: Coding-Agenten als dauerhaftes Team betreiben

Was ist OpenRig?

OpenRig ist eine selbst gehostete Steuerungs- und Betriebsschicht für Coding-Agenten. Es liefert kein eigenes Sprachmodell, sondern organisiert reale Sitzungen von Claude Code, Codex sowie Pi und Oh My Pi. Ein lokaler HTTP-Daemon verwaltet den Zustand in SQLite und startet die Agenten in tmux. Du bedienst das System über CLI, Terminal-UI oder MCP. Die Architektur ist im Release-README dokumentiert.

Ein einzelnes AI Harness verbindet ein Modell mit Werkzeugen und Ausführungsregeln. OpenRig setzt darüber an: Es verwaltet das Team aus solchen Harnesses, seine Rollen und die Übergaben zwischen ihnen. Du ersetzt Codex oder Claude Code also nicht, sondern betreibst sie in einer gemeinsamen Struktur.

Die Analogie zu Docker Compose hilft bei der Vorstellung: Du beschreibst eine Topologie und startest sie als Einheit. Sie bedeutet ausdrücklich nicht, dass jeder Agent in einem isolierten Container läuft. Auch bestehende tmux-Sitzungen lassen sich laut README über Discovery und Adoption unter Verwaltung bringen; für den ersten Versuch ist ein vorbereitetes Team leichter nachvollziehbar.

Welche Kerndaten sind für den Einstieg wichtig?

Kriterium	Stand und Quelle
Projekt	mvschwarz/openrig auf GitHub
Lizenz und Sprache	Apache-2.0 und TypeScript laut GitHub-API
Veröffentlichte Version	v0.6.5, veröffentlicht am 04.10.2026 laut Release-API zum Tag
npm-Paket	@openrig/cli, beim Writer-Abruf ebenfalls Version 0.6.5
GitHub-Snapshot	5.315 Stars und 393 Forks beim direkten API-Abruf am 06.10.2026, 07:52:24 UTC (09:52:24 CEST); kein Beleg für Wochenwachstum
Voraussetzungen	Node.js 22 oder 24, tmux, macOS oder Linux; auf Apple Silicon empfiehlt die Release-Dokumentation Node.js 22
Windows	Nativ nicht unterstützt, WSL2 ungetestet laut README
Eigener Praxistest	Nicht durchgeführt; die folgenden Befehle sind dokumentations- und quellcodegeprüfte Beispiele, keine hier ausgeführte End-to-End-Anleitung

Die Zähler sind eine Momentaufnahme. Für die Befehle ist dagegen der veröffentlichte Release-Tag maßgeblich, nicht ein möglicherweise neuerer Entwicklungsstand auf main.

Welches Problem löst ein dauerhaftes Agententeam?

Mehrere Coding-Agenten parallel zu öffnen ist einfach. Schwieriger wird es, wenn du regelmäßig erklären musst, wer implementiert, wer prüft, welcher Code zuletzt freigegeben wurde und wo eine unterbrochene Aufgabe weitergeht. Ohne feste Struktur wirst du selbst zum Nachrichtenverteiler zwischen Terminals.

OpenRig macht diese Beziehungen zu gespeicherten Objekten. Eine Rolle bleibt adressierbar, Aufgaben behalten ihre Zuständigkeit und Projektquellen können gezielt bereitgestellt werden. Das ist der relevante Unterschied zu einer Ansammlung unabhängiger Chats, wie ihn das Release-README beschreibt. Warum die Ausführungsumgebung neben dem Modell entscheidend ist, behandelt auch Harness statt Modellvergleich.

Begriff	Bedeutung	Praktischer Nutzen
Rig / RigSpec	Deklarative Beschreibung des Teams in YAML	Rollen und Beziehungen lassen sich wiederverwenden
Seat	Feste Rolle und Adresse, etwa dev-owner@first-project	Du sprichst dieselbe Rolle an, auch wenn ihre Unterhaltung wechselt
Pod	Gruppe verwandter Seats mit gemeinsamen Vorgaben und Quellen	Spezialisten erhalten passenden Projektkontext
AgentSpec	Wiederverwendbarer Agentenbauplan mit Skills und Startvorgaben	Eine Rolle muss nicht jedes Mal neu beschrieben werden
Culture	Markdown-Regeln für die Zusammenarbeit	Erwartete Arbeitsweise wird dokumentiert, aber nicht technisch erzwungen

Quelle: OpenRig-Konzepte im Release-README.

Persistent bedeutet hier nicht grenzenloses Gedächtnis. Jeder Agent behält sein eigenes Kontextfenster. Dauerhafte Adressen, gespeicherte Quellen und Aufgaben helfen beim Wiederaufnehmen; sie garantieren nicht, dass sämtliches früheres Wissen jederzeit im Modellkontext liegt.

Wie arbeitet ein Owner mit einem unabhängigen Checker?

Für den Einstieg reicht eine klare Arbeitsteilung: Der Owner verantwortet das Ergebnis, der Checker prüft den ausgewählten Stand. Die Getting-started-Dokumentation setzt genau auf dieses Muster.

Ein sinnvoller Auftrag enthält das gewünschte Verhalten, eine Grenze und einen überprüfbaren Abschluss. Beim CSV-Import könnte das heißen: Eine fehlende Pflichtspalte muss mit ihrem Namen gemeldet werden, vorhandene Daten dürfen sich nicht verändern, und ein Regressionstest soll den Fehlerfall abdecken. Der Checker prüft anschließend denselben Kandidaten, nicht irgendeinen früheren Zwischenstand.

Dabei musst du zwei Ebenen unterscheiden:

• Nachricht: rig send übermittelt deinen Auftrag an eine Rolle. Das erzeugt allein noch keine dauerhafte Aufgabe.
• Queue: rig queue verwaltet Aufgaben mit ID, Zuständigkeit und Statusübergängen. Der Owner muss den Auftrag dort erfassen.

Eine zugestellte Nachricht ist deshalb kein abgeschlossener Auftrag. Auch ein grüner Status ersetzt weder den Diff noch die Testergebnisse oder den Review des konkreten Kandidaten. Diese Unterscheidung ist für orchestrierte Multi-Agent-Loops wichtiger als die bloße Anzahl beteiligter Agenten.

Wie startest du ein kleines OpenRig-Team?

Die folgenden Beispiele beziehen sich auf die Dokumentation von v0.6.5, ergänzt um die unten verlinkten CLI-Codepfade desselben Tags. Ich habe OpenRig dafür nicht installiert oder Agenten gestartet. Sie zeigen den dokumentations- und quellcodegeprüften Bedienweg unter den genannten Voraussetzungen, nicht einen garantierten Ablauf für jede Provider- und Betriebssystemkonfiguration.

Voraussetzungen und Provider prüfen

Teste zuerst in einem nicht sensiblen Repository, möglichst unter einem getrennten Betriebssystemkonto oder in einer VM. Sichere die betroffenen Provider- und Projektkonfigurationen, bevor du OpenRig installierst und einen Daemon oder ein Rig startest. Die konkreten Eingriffe beschreibt What OpenRig changes on your machine.

Für das Codex-Beispiel müssen Codex CLI, Anmeldung und tmux bereits funktionieren:

node --version
tmux -V
codex --version
codex login status

npm install -g @openrig/cli@0.6.5
rig setup --dry-run

Die Release-Anforderungen nennen Node.js 22 oder 24. Das npm-Feld engines >=22 ist kein Nachweis, dass jede neuere Node-Version getestet wurde.

rig setup --dry-run zeigt den Plan des breiteren Setups, führt ihn aber nicht aus. Das tatsächliche rig setup kann beide Harnesses prüfen oder installieren und Einstellungen verändern. Für den Einstieg mit einem bereits vorbereiteten Provider ist es optional. Der Dry-Run zeigt außerdem nicht sämtliche späteren Daemon- und Launch-Effekte.

Welcher Starter passt zu deinem Konto?

Starter	Projektrollen	Modellwahl laut Release-Dokumentation
first-project	Codex Owner und Codex Checker	Beide auf gpt-6-astra gepinnt
first-project-claude	Claude Owner und Claude Checker	Konfiguriertes natives Claude-Standardmodell
first-project-mixed	Claude Owner und Codex Checker	Claude-Standardmodell und gpt-6-astra

Quelle: Providerwahl und Modell-Pins.

Bestätige vor dem Start, dass dein Konto Zugriff auf das gewählte Modell hat, und kontrolliere anschließend das tatsächlich laufende Modell. Der Codex-Starter übernimmt nicht automatisch dein persönliches Standardmodell. Fehlt der Zugang zum Pin, brauchst du eine bewusst angepasste Konfiguration, keinen stillen Modellwechsel.

Wichtig: Die zwei Projektrollen sind nicht zwingend die einzigen laufenden Agenten. Beim gewöhnlichen CLI-Daemonstart kann zusätzlich ein Kernel-Rig anlaufen, das verfügbare authentifizierte Provider unabhängig vom Projektstarter auswählt. Ein Codex-Projekt beschränkt daher nicht automatisch die ganze Instanz auf Codex. Die Kernel-Dokumentation trennt diese Ebenen ausdrücklich.

Team ansehen, starten und Bereitschaft prüfen

Führe die Befehle im Terminal deines ausgewählten Test-Repositorys aus. Die Spec-Preview benötigt bereits einen laufenden Daemon. Starte ihn deshalb bewusst zuerst: Das kann die offengelegten Konfigurationseingriffe auslösen und auf einer frischen Instanz den Kernel mit zusätzlichen Agenten booten. Preview und Plan prüfen anschließend den Projektstarter vor dessen Start; sie sind kein vollständiger Dry-Run aller Daemon-Effekte.

starter=first-project
rig daemon start
rig specs preview "$starter" --kind rig
rig up "$starter" --cwd . --plan
rig up "$starter" --cwd .
rig status
rig ps --nodes --rig "$starter"
rig tui

Die Daemon-Voraussetzung ist im CLI-Code der Spec-Preview sichtbar. Auch rig up --plan kann laut CLI-Startpfad vor der Plan-Anfrage einen Daemon starten. Ein bereits vorhandener Daemon oder Kernel muss für dieses Beispiel nicht gestoppt oder neu konfiguriert werden.

Die Startanleitung unterscheidet Daemon-Zustand und Seat-Bereitschaft. Kläre Login-, Trust- oder Berechtigungsprompts in den bestehenden Agententerminals, bevor du Arbeit vergibst. Starte nicht einfach eine weitere Sitzung, um einen blockierten Prompt zu umgehen.

rig tui öffnet eine unabhängige Ansicht. Das Schließen dieses Betrachtungsterminals bedeutet nicht, dass das Team beendet wurde.

Einen begrenzten Auftrag übergeben

Für ein Repository mit CSV-Import kannst du den Owner so ansprechen:

rig send "dev-owner@$starter" 'Verbessere die Fehlermeldung beim CSV-Import, wenn eine Pflichtspalte fehlt. Nenne die Spalte und lasse vorhandene Daten unverändert. Erfasse den Auftrag in der Queue und nenne seine ID. Ergänze einen Regressionstest, lass dev-check den exakten Kandidaten unabhängig prüfen und dokumentiere das Ergebnis sowie den Testweg. Nur lokal arbeiten, nichts veröffentlichen.'
rig queue list --destination "dev-owner@$starter" --limit 1000
rig queue list --destination "dev-check@$starter" --limit 1000

Die Queue-Abfragen zeigen standardmäßig aktive Aufgaben der jeweiligen Adresse, nicht automatisch die vollständige Arbeit des Rigs. Für abgeschlossene Historie ergänzt du --all. Laut Dokumentation zur Aufgabenvergabe besitzt queue list keine --rig-Option. Ein gesendeter Prompt garantiert zudem nicht, dass der Owner tatsächlich eine Queue-Zeile anlegt: Prüfe die angeforderte ID in der Queue.

Für die Abschlussprüfung empfiehlt dieselbe Dokumentation rig queue show <id> --full und rig queue transitions <id>. Ersetze dabei <id> durch die tatsächlich angelegte Aufgaben-ID. Prüfe anschließend selbst den geänderten Code, den Regressionstest und das Checker-Ergebnis. Halte fest, welcher Kandidat geprüft wurde und ob danach weitere Änderungen entstanden sind. Das ist eine praktische Freigaberegel, keine automatisch garantierte Eigenschaft des Teams.

Was bleibt nach dem Beenden oder Neustart erhalten?

Zum geplanten Beenden mit Snapshot und späteren Wiederaufnehmen nutzt du folgenden Weg. Nutze dieselbe Startervariable wie beim Start. In einem neuen Terminal setzt du sie wieder auf den Namen deines tatsächlich gestarteten Teams. --existing wählt das vorhandene Rig statt des gleichnamigen Bibliotheksstarters.

rig down "$starter" --snapshot
rig daemon start
rig up "$starter" --existing

Quellen: Snapshot/Restore im README, Reboot-Grenzen im Release und CLI-Beleg für die Namensauflösung. Bei den eingebauten Startern ist der Name ohne --existing mehrdeutig, wenn bereits ein gleichnamiges Rig existiert.

Der Snapshot macht die Teamstruktur wiederherstellbar. Er ist aber keine Zusage einer verlustfreien Fortsetzung jeder Unterhaltung. Lies nach dem Restore die Ergebnisse pro Seat: Wurde die bisherige Unterhaltung fortgesetzt, entstand eine frische Sitzung oder schlug der Start fehl? Bei fehlender History braucht es eine bewusste Neustartentscheidung anhand der gespeicherten Aufgaben und Projektartefakte.

Nach einem Host-Reboot startet der Daemon in Version 0.6.5 nicht selbstständig. Persistente Organisation und automatischer Dauerbetrieb sind also unterschiedliche Fähigkeiten. Dass ein Prozess wieder läuft, beweist außerdem weder vollständige Kontextkontinuität noch die Korrektheit seiner weiteren Arbeit.

Welche Vorteile sind plausibel und wann lohnt sich OpenRig?

Die dokumentierten Funktionen stützen einen organisatorischen Nutzen. Eine gemessene Zeitersparnis, geringere Gesamtkosten oder bessere Codequalität gegenüber einem Einzelagenten ist damit noch nicht belegt.

Einsatzfall	Möglicher Nutzen	Was du weiterhin prüfen musst
Wiederkehrende Umsetzung und Review	Feste Owner-/Checker-Adressen und nachvollziehbare Übergaben	Review des exakten Codezustands
Länger laufendes Projekt	Queue und Projektquellen helfen bei Unterbrechungen	Tatsächlicher Restore und verbleibende offene Aufgaben
Arbeit mit verschiedenen Harnesses	Claude und Codex lassen sich im selben Rig koordinieren	Providerzugang, Modellwahl und native Berechtigungen
Spezialisierte Analyse oder Fehlersuche	Getrennte Kontexte halten Teilaufgaben übersichtlicher	Widersprüche und Zusammenführung der Ergebnisse
Viele verstreute Terminals	TUI und Topologie bündeln den Überblick	Laufende Seats, blockierte Prompts und Ressourcenverbrauch

Funktionsgrundlage: Release-README. Die Nutzenbewertung ist eine redaktionelle Einordnung, kein Benchmark.

Meine Empfehlung: Beginne mit Owner und Checker und einer lokal prüfbaren Änderung. Erweitere das Team erst, wenn eine zusätzliche Rolle eine konkrete Lücke schließt. Ohne klar getrennte Verantwortung erzeugen weitere Agenten vor allem zusätzliche Kommunikation.

Wie unterscheidet sich OpenRig von Claude Agent Teams und CrewAI?

Diese Werkzeuge lösen nicht dieselbe Aufgabe. OpenRig verwaltet vorhandene Coding-Sitzungen. Claude Agent Teams ist ein Teamfeature innerhalb Claude Code. CrewAI ist ein Framework zum Aufbau eigener Agentenanwendungen.

Ansatz	Schwerpunkt	Sinnvoll, wenn du …	Wesentliche Grenze
OpenRig	Persistente Rollen und Topologien um verschiedene Coding-Harnesses	bestehende Agenten längerfristig als Team betreiben willst	den zusätzlichen Betrieb selbst verantwortest
Claude Code Agent Teams	Experimentelles Teamfeature mit separaten Kontexten und Kommunikation	einen Multi-Claude-Auftrag in deiner bestehenden Umgebung bearbeiten willst	keine Cross-Harness-Steuerung brauchst; In-Process-Teammates werden durch /resume und /rewind nicht wiederhergestellt
Einzelne Session / Claude Subagents	Leichtere Delegation innerhalb eines Hauptworkflows	kleine, isolierte Aufgaben oder eng gekoppelte Änderungen hast	kein gleichartiges dauerhaftes Cross-Harness-Team erhältst
CrewAI	Eigene Agenten, Tools sowie sequenzielle oder hierarchische Prozesse	eine Agentenanwendung programmieren willst	eine andere Abstraktion als verwaltete native Terminal-Sitzungen nutzt

Quellen: OpenRig-README, Claude Agent Teams und CrewAI Crews, abgerufen am 06.10.2026.

Die Claude-Dokumentation empfiehlt für sequenzielle Aufgaben, Änderungen an denselben Dateien oder viele Abhängigkeiten eher eine einzelne Session oder Subagents. Diese Gegenposition ist auch für OpenRig relevant: Ein dauerhaftes Team macht eine schlecht teilbare Aufgabe nicht automatisch parallelisierbar.

Welche Einschränkungen musst du vor dem Betrieb kennen?

Keine eigene generelle Sandbox

OpenRig setzt auf einen Host und Konten, denen du vertraust. Im Show-HN-Thread zur Topologie bestätigt der Gründer, dass eigene Isolation bislang nicht das gelöste Problem ist. Gemeinsames Dateisystem und Netzwerk erleichtern Zusammenarbeit, schaffen aber auch gemeinsame Risiken.

Das bedeutet nicht, dass jeder Agent immer Vollzugriff hat. Die dokumentierten Standardlaunches nutzen Codex workspace-write beziehungsweise Claude acceptEdits; native Regeln, Sandbox und Prompts bleiben relevant. Markdown-Guidance ist keine technische Sicherheitsgrenze.

Self-hosting schützt nicht automatisch deine Daten

Die Security Policy sieht die eigene Maschine oder ein vertrauenswürdiges privates Netz vor, nicht das offene Internet. Öffentlich erreichbare Daemons sind kein unterstützter Standardbetrieb.

Lokal laufen die Steuerung und die Sitzungen. Daraus folgt nicht, dass auch die Modellinferenz lokal erfolgt. Provider- und ausgewählte MCP-Verbindungen haben eigene Datenflüsse. Self-hosting allein belegt deshalb weder vollständige Datenlokalität noch DSGVO-Konformität.

Bestehende Konfiguration kann sich ändern

Daemonstart und Seatlaunch können Hooks, Trust-Einträge und Ressourcen schreiben. Betroffen sind unter anderem ~/.claude.json, CODEX_HOME/config.toml, projektlokale .claude/settings.local.json und .mcp.json. Der genaue Umfang hängt von Runtime und ausgewählten Ressourcen ab; die README-Offenlegung beschreibt ihn.

Ein separates OPENRIG_HOME isoliert diese Providerkonfiguration nicht automatisch. Sichere relevante Dateien vorher und gehe nicht von einem vollständigen Rollback aller Eingriffe aus.

Version und Testabdeckung begrenzen die Anleitung

Die Release Notes kennzeichnen reale Claude-Tests unter Linux, simulierte Abläufe und nicht real geprüfte Funktionen getrennt. Insbesondere war die Änderung für Codex-Netzwerkzugriff innerhalb der Sandbox nicht mit echten Logins, Managed Policies oder unter Linux geprüft. Ein gestarteter Codex-Seat kann daher trotzdem an seiner Verbindung zum lokalen Daemon und damit an Queue-Arbeit scheitern.

Nutze rig send --dangerously-interact nicht zum Beantworten nummerierter Menüs: Der im Release bestätigte Fehler kann die fokussierte statt der getippten Option bestätigen. Die ältere Web-UI ist im Wartungsmodus und standardmäßig deaktiviert; HTML- und SVG-Vorschauen können laut derselben Quelle Skripte mit den Browserrechten der UI ausführen. Für den Einstieg sind CLI und TUI die naheliegenden Oberflächen.

Mehr Agenten sind kein Kosten- oder Qualitätsbeweis

Zusätzliche Sitzungen können mehr Tokens verbrauchen, redundant recherchieren und Providerlimits schneller erreichen. Die Claude-Dokumentation warnt ausdrücklich vor Tokenverbrauch und Koordinationsaufwand von Teams. Eine feste lineare Kostenformel für OpenRig oder eine pauschale Ersparnis lässt sich daraus nicht ableiten.

Im früheren Show-HN-Thread berichtet der nicht zum Projektgründer gehörende Kommentator unsaved159 von aufeinander aufbauenden Fehlern und hohem Nachbesserungsaufwand bei Agenten-Swarms allgemein. Das ist eine Community-Anekdote, kein OpenRig-Benchmark. Ebenso sind positive Langlaufberichte des Gründers Selbstauskünfte, keine unabhängige Evaluation.

FAQ: Häufig gestellte Fragen zu OpenRig

Brauche ich Claude Code und Codex gleichzeitig?

Nein. Die Starter-Dokumentation bietet reine Codex-, reine Claude- und gemischte Projektteams. Der automatisch gestartete Kernel kann unabhängig davon weitere bereits authentifizierte Provider nutzen.

Läuft mit OpenRig alles lokal?

Nein. Lokal betrieben werden Steuerung und Agentensitzungen, aber die gewählten Modellprovider und MCP-Dienste können extern sein. Prüfe deren Datenflüsse separat anhand der Runtime-Offenlegung.

Ist OpenRig eine Sandbox für Coding-Agenten?

Nein. Es liefert keine generelle eigene Betriebssystem-Isolation; die nativen Berechtigungen der Harnesses bleiben relevant. Die Security Policy setzt einen vertrauenswürdigen Betrieb voraus.

Ersetzt OpenRig CrewAI?

Nicht als gleichartiges Werkzeug. OpenRig organisiert native Coding-Harnesses, während du mit CrewAI eigene Agenten, Tools und Prozesse definierst. Entscheidend ist, ob du vorhandene Sitzungen betreiben oder eine Agentenanwendung bauen willst.

Wie viel kostet OpenRig?

Die Software steht unter Apache-2.0 und benötigt keine OpenRig-Lizenzgebühr. Modellzugang, Providerlimits, Infrastruktur und dein Betriebsaufwand bleiben relevant; einen allgemein belastbaren Gesamtpreis gibt es dafür nicht.

Werden nach einem Neustart alle Unterhaltungen wiederhergestellt?

Das ist nicht garantiert. Prüfe pro Seat den Restore-Ausgang und entscheide bei fehlender History bewusst über eine frische Unterhaltung. Die Release Notes nennen außerdem den fehlenden automatischen Daemonstart nach einem Reboot.

Wann ist ein Einzelagent die bessere Wahl?

Bei einer kleinen sequenziellen Änderung, stark gekoppelten Dateien oder wenn du bislang gar keine mehreren Sitzungen koordinierst. Auch die Claude-Team-Dokumentation empfiehlt für solche Aufgaben leichtere Ansätze.

Fazit

OpenRig ist für erfahrene Coding-Agent-Nutzer interessant, die bereits mehrere Sitzungen koordinieren und diese Arbeitsorganisation dauerhaft erhalten wollen. Starte mit Owner und Checker in einem nicht sensiblen Testprojekt und prüfe Ergebnis, Review und Wiederaufnahme selbst. Für kleine oder eng gekoppelte Änderungen empfehle ich weiterhin einen Einzelagenten; ein Team lohnt sich erst, wenn klare Rollen seinen zusätzlichen Betrieb rechtfertigen.

Zur Vertiefung: AI Harness erklärt, Harness statt Modellvergleich und Multi-Agent-Loops orchestrieren.

Quellen

Primärquellen: OpenRig und offizielle Vergleichsdokumentation

• OpenRig-Repository und GitHub-API: Projekt, Lizenz, Sprache und GitHub-Zähler. Der Artikel verwendet den direkten Writer-Snapshot vom 06.10.2026, 07:52:24 UTC (09:52:24 CEST), mit 5.315 Stars und 393 Forks, nicht den früheren Recherche-Snapshot.
• README unter v0.6.5: Architektur, Konzepte, Voraussetzungen, Konfigurationsänderungen und Snapshot/Restore.
• Getting started unter v0.6.5: Providerwahl, Modell-Pins, Starter, Kernel, Aufgabenvergabe und Queue-Abfragen.
• Spec-Preview: Daemon-Voraussetzung, Up: möglicher Daemonstart vor dem Plan und Up: vorhandenes Rig eindeutig auswählen: statische CLI-Codebelege für die ergänzten Ablaufkorrekturen, keine eigenen Laufzeittests.
• Security Policy unter v0.6.5: Vertrauensannahmen und zulässiger Deployment-Scope.
• Release v0.6.5 und Release-API zum Tag: Veröffentlichung, reale und simulierte Tests, Codex-Netzwerkgrenzen und bekannte Fehler.
• npm-Paket @openrig/cli: Veröffentlichte Paketversion und Engine-Anforderung, im Recherche- und Prüfworkflow zusätzlich über npm view beziehungsweise die Registry geprüft.
• Claude Code Agent Teams: Experimenteller Status, Aufgabenkoordination, Tokenverbrauch und Grenzen der Wiederaufnahme.
• CrewAI Crews: Framework-Abstraktion und sequenzielle beziehungsweise hierarchische Prozesse.

Community und Gegenpositionen

• Show HN: OpenRig als Control Plane: Gründerangaben zur Topologie und fehlenden eigenen Isolation. Keine unabhängige Messung.
• Show HN: Claude Code und Codex als System: Gründerperspektive sowie Community-Anekdote von unsaved159 zu Aufsicht und Fehlerfortpflanzung bei Agenten-Swarms allgemein. Keine kontrollierte OpenRig-Evaluation.

Recherche-Synthese

• NotebookLM: OpenRig-Recherche: Synthese der Recherchequellen, kein Ersatz für die verlinkten Originalquellen. Eine Google-Anmeldung kann zum Öffnen weiterhin nötig sein.

*Quellenstand: 06.10.2026. Anleitung dokumentations- und quellcodegeprüft für OpenRig 0.6.5; kein eigener Hands-on-Test und keine eigene Produktivitäts-, Qualitäts- oder Kostenmessung.*