Zwei KIs. Ein Gespräch. Beide Richtungen.
Hermes läuft auf deinem Rechner. Thea läuft auf einem Server. Jetzt kann jede der beiden einen Thread an die andere übergeben - und ein fehlender API-Key bremst keinen Turn mehr aus.
next-vibe läuft überall: auf dem Laptop, auf einem VPS, auf beidem gleichzeitig. Verbinde zwei Instanzen, und sie werden zu einem System. Unsere heißen Hermes und Thea.
Dieses Release schließt den Kreis: Remote-Threads laufen jetzt in beide Richtungen, und die Instanz ohne Provider-Key blockiert nichts mehr.
Das Duo
Dieselbe Codebasis. Unterschiedliche Aufgaben.
Hermes
Thea
Jede Instanz verwaltet ihre eigenen Daten und Tasks. Die Verbindung leitet Events weiter - nicht mehr und nicht weniger.
Threads wechseln jetzt in beide Richtungen
Remote-Ordner und private Threads laufen auf der jeweils anderen Instanz - von Thea zu Hermes und von Hermes zu Thea.
Leg einen Thread in einen Remote-Ordner, und die Instanz auf der anderen Seite übernimmt den kompletten KI-Turn: Modell, Systemprompt, Tools. Du schreibst weiter, wo du bist. Das Gespräch wird zu dir zurückgespiegelt.
Ein Turn, von Anfang bis Ende
Du schreibst
Eine Nachricht in einem Remote-Thread auf Hermes.
Die Verbindung leitet sie weiter
Über einen dauerhaften WebSocket - oder per direktem HTTP-Aufruf, wenn die Gegenseite öffentlich erreichbar ist.
Thea führt die Schleife aus
Mit ihrem Modell, ihrem Prompt, ihren Tools.
Tools laufen dort, wo sie zu Hause sind
Ein Tool, das nur auf Hermes existiert, wird auf Hermes aufgerufen. Das Ergebnis fließt zurück in Theas Schleife.
Der Turn landet auf beiden Seiten
Das fertige Gespräch synchronisiert sich zurück in deinen Spiegel.
Kein API-Key? Der Turn läuft trotzdem durch.
Die Instanz, die einen Turn ausführt, braucht den API-Key des Modellanbieters. Nicht jede Instanz hat einen.
Bevor eine Instanz einen Turn übernimmt, prüft sie den Provider-Key auf ihrem eigenen Knoten. Fehlt er, bricht sie sofort mit einer eindeutigen Markierung ab - kein Hängen, kein halb geschriebener Thread.
Die aufrufende Seite erkennt die Markierung, macht ihre Relay-Buchführung rückgängig und führt die Schleife selbst aus. Prompt und Tools der Gegenseite gelten weiter; Tool-Aufrufe laufen über die Verbindung hin und zurück.
Wer führt die Schleife aus?
Unter der Haube
Für alle, die den Diff lesen.
Der Transportweg wird beim Verbinden ausgehandelt, nie von Hand konfiguriert. Das Ziel pingt den Initiator mit einem authentifizierten Health-Check an (maximal 5 Sekunden). Erreichbar: direktes HTTP. Hinter NAT: Die verdeckte Seite öffnet einen ausgehenden WebSocket, und jedes Relay läuft gebündelt darüber.
Der Connector verbindet sich mit exponentiellem Backoff von 1 bis 30 Sekunden neu und liest die Verbindung bei jedem Versuch frisch ein. Dieses Release härtet genau diesen Pfad.
Die Markierung, die ein Empfänger ohne Key zurückschickt:
// relay/constants.ts
export const RELAY_RECEIVER_NO_PROVIDER_KEY =
"[relay-receiver-no-provider-key]";
// receiver: no provider key on this node? fail fast, let the caller run it
if (ctx.mode === "relay" && data.model) {
const missingKey = getMissingProviderKeyMessage(getChatModelById(data.model));
if (missingKey !== null) {
return fail({ /* ...marker + reason... */ });
}
}Außerdem in diesem Release
- Warnung bei veraltetem Lead: Ein Frame an einen Lead, den diese Instanz nicht mehr kennt, wird mit Warnung verworfen statt stillschweigend - eine erneute Authentifizierung der Verbindung behebt es.
- Datenbank-Zeitstempel in UTC, für Postgres-Pool und PGlite gleichermaßen - damit Zeilen mit Standard-Zeitstempel instanzübergreifend richtig sortiert werden.
- Der Stream-Writer setzt die Thread-ID von Anfang an, sodass Gegenstellen keine Events mit leerer Thread-ID mehr verwerfen.
- Revival-Turns synchronisieren mit der Gegenseite, damit nachträglich eingefügte Tool-Ergebnisse auch im Spiegel ankommen.
Selbst ausprobieren
Betreib deinen eigenen Hermes.
Hoste next-vibe auf deinem Rechner, verbinde es mit einem Server und lass beide die Arbeit teilen.