Neustarts und Fortsetzen

Jede Konversation hat ihren eigenen Agent, der in einem Hintergrundprozess auf dem Rechner des Relays läuft. Die Konversation selbst, mit Verlauf, Queue und Entwurf, liegt im Relay. Diese Seite erklärt, wie beides zusammenpasst, damit du weißt, was dich ein Kill session (Session beenden), ein Neustart des Relays oder ein Reboot kostet und was von selbst zurückkommt.

Die Kurzfassung: Nichts, was du geschrieben hast, geht verloren. Die nächste Nachricht an eine Konversation startet ihren Agent erneut, falls er nicht läuft, und der Agent setzt die eigene Session des Providers fort, keine leere.

Der Agent-Prozess einer Konversation #

OAR nennt diesen Prozess den Session-Worker. Du startest ihn nicht selbst. Das Relay startet ihn, wenn eine Konversation ihn braucht, meist mit deiner ersten Nachricht, und der Worker verbindet sich zurück zum Relay, um Nachrichten zu empfangen und die Antwort zu melden. Unter Linux und macOS mit installiertem tmux laufen Worker in abgekoppelten tmux-Sessions, und Inspect tmux console (tmux-Konsole ansehen) im ⋯-Menü zeigt eine davon. Ohne tmux laufen sie als einfache Hintergrundprozesse.

Neu in 0.9.11 Worker laufen auf jeder Plattform auf dem eigenen Node.js des Relays, über dessen vollen Pfad, sodass sie auch starten, wenn der PATH des Relays kein node enthält, etwa bei einem Relay, das der Windows-Start-Task gestartet hat, bevor sich jemand angemeldet hat. COPILOT_WEB_RELAY_NODE legt ein anderes fest (Umgebungsvariablen). Wenn der PATH eines Workers kein node enthält, wird dieser Node.js-Ordner an sein Ende angehängt, damit auch die CLIs und Befehle, die ein Worker startet, eines finden.

Kann der Worker nicht gestartet werden, zeigt die Konversation eine Notiz:

The worker for this conversation could not be started (2 tries). Cause: <reason>. Your message stays queued; the relay tries again every 1 minute until 14:20 UTC.

Das Relay versucht es 10 Minuten lang jede Minute erneut. Danach sagt die Notiz, dass es aufgehört hat, und zeigt einen Button Retry (Erneut versuchen). Deine Nachricht bleibt die ganze Zeit in der Queue und wird zugestellt, sobald ein Worker startet. Unter Windows schlägt ein Start, der fehlschlägt oder nie zurückkehrt, sofort fehl und nennt das Programm, und das Log des Relays nennt den Befehl und den PATH, mit dem er gestartet wurde.

Von selbst stoppen #

Eine Claude- oder DeepSeek-Konversation und eine GitHub-Copilot- oder OpenAI-Konversation auf der SDK-Engine geben ihren Speicher frei, wenn nichts passiert. Nach 10 Minuten ohne Aktivität beendet sich das eigene Programm des Agents, und die nächste Nachricht startet es erneut und setzt dieselbe Provider-Session fort. Der Worker-Prozess bleibt und behält seine Verbindung zum Relay. Die App hat keine Einstellung für die 10 Minuten.

Der Agent wird nicht gestoppt, solange eines davon passiert:

• ein Turn läuft für ihn oder steht in der Queue,
• eine Rückfrage- oder Berechtigungskarte wartet auf deine Antwort,
• ein Hintergrund-Task läuft, oder die Fortsetzung eines gerade beendeten steht noch aus.

Hintergrund-Tasks allein können ihn nur bis zum Background task timeout (Timeout für Hintergrund-Tasks) in Settings → General (Einstellungen → Allgemein) offen halten (Standard 4 Stunden; 0 heißt kein Limit).

Neu in 0.9.17 Eine DeepSeek-Konversation startet das Programm ihres Agents auch neu, wenn du ihr Modell oder ihren Reasoning-Effort änderst, weil Claude Code beides nur beim Start liest. Der Neustart passiert vor dem nächsten Turn, wenn nichts im Programm läuft, und setzt dieselbe Session fort. Solange darin noch Hintergrundarbeit läuft, läuft der Turn im Programm, wie es ist: Ein neues Modell wird dort umgeschaltet, ein neuer Effort wartet auf den Neustart.

Die anderen Provider haben keinen solchen Leerlauf-Stopp. Ein Worker von Claude Cloud, Cursor oder Grok läuft weiter, bis du die Session beendest, die Konversation archivierst oder der Rechner stoppt. Die Extension-Engine von Copilot hält ihre Copilot CLI ebenfalls am Laufen. Ein Cursor-Worker, der 30 Minuten unbenutzt war, schließt sein Agent-Handle und öffnet bei der nächsten Nachricht denselben Cursor-Agent wieder.

Kill session #

Kill session im ⋯-Menü der Konversation oder im Menü ihrer Zeile in der Liste stoppt den Worker und die Prozesse, die er gestartet hat. Nutze es, wenn eine Konversation festhängt, wenn der Agent nicht auf Stop (Stoppen) reagiert oder wenn der Agent frisch starten soll, damit er neue Tools oder Einstellungen übernimmt, z. B. nachdem du Agent-Sessions eingeschaltet hast.

Zuerst öffnet sich eine Bestätigung:

Kill the session for <title>?
This stops the current worker and any active turn will need a manual retry or a new message.

Danach sagt ein kurzer Hinweis Session killed. (Session beendet.) Wurde kein laufender Prozess gefunden, sagt er stattdessen Session state cleared; no live worker process was found. Überlebt ein Prozess den Versuch, sagt eine Meldung Failed to kill session, und nichts wird zurückgesetzt.

Ein Turn, der lief, endet mit einer Notiz in der Konversation: This session was killed from the relay UI before the turn completed. Sende die Nachricht erneut oder schreib eine neue. Die Konversation, ihr Verlauf und ihre eingereihten Nachrichten bleiben. Die nächste Nachricht startet einen neuen Worker, und die Provider-Session wird fortgesetzt.

Auch das Archivieren einer Konversation stoppt ihren Worker. Siehe Die Konversationsliste.

Wenn der Agent nicht erreichbar ist #

Hat sich 10 Sekunden lang kein Worker gemeldet, erscheint ein Banner über der Konversation, und die Statuszeile in der Seitenleiste zeigt CLI offline:

⚠️ CLI is offline — messages will queue until it reconnects

Das Banner gehört zum Relay, nicht zu einer einzelnen Konversation, und auf einem Relay, das länger untätig war, kann es normal sein. Nachrichten, die du sendest, bleiben erhalten. Sende eine: Das Relay startet den Worker der Konversation, und das Banner verschwindet, sobald er sich verbindet. Bleibt es, sieh dir worker-<session>.log im Log-Ordner des Relays an; wo der liegt, steht unter Dateien und Ordner.

Ein Worker, der seine Verbindung verloren hat, z. B. bei einem Neustart des Relays, versucht weiter, sich neu zu verbinden, und wartet bis zu 8 Sekunden zwischen den Versuchen. Neu in 0.9.13 Er gibt außerdem einen Verbindungsaufbau auf, der nicht innerhalb von 15 Sekunden fertig ist, und wartet nicht darauf, dass ein Relay, das herunterfährt, die Verbindung schließt; ein hängender Neustart lässt ihn also nicht mehr ohne nächsten Versuch zurück. Jeder fehlgeschlagene Versuch schreibt eine Zeile worker ws disconnected mit dem Grund in sein worker-<session>.log: die ersten drei, danach höchstens eine pro Minute. Neu in 0.9.11 Als Sicherheitsnetz ersetzt das Relay einen Worker, der 60 Sekunden ohne Verbindung war, während eine Nachricht auf ihn wartet: Es stoppt den alten Prozess und startet einen neuen, der die Nachricht übernimmt. Das tut es nie, während ein Turn oder Hintergrundarbeit dieser Session läuft, und es schreibt dabei eine Zeile WORKER DETACHED ins Log.

Das Relay neu starten #

Starte das Relay neu, um eine neue Version, eine geänderte Config-Datei oder eine neu installierte Provider-CLI zu laden. Wähle 🌄 Restart web relay (Web-Relay neu starten) im ⋯-Menü der Konversation, oder führe oar restart auf dem Rechner des Relays aus. oar update und der Button Update (Aktualisieren) in Settings → General starten es nach einer Installation für dich neu.

Worauf der Neustart warten würde Neu in 0.9.13 #

🌄 Restart web relay zeigt zuerst, worauf ein Neustart warten würde und was er weiterlaufen ließe:

• die Sessions mit einem laufenden Turn, jeweils mit Titel;
• wie viele Nachrichten er bis dahin zurückhalten würde;
• die Sessions mit Hintergrund-Tasks (Befehle, Monitore, Subagents), jeweils markiert als weiterlaufend oder als may stop. Ein Task, den das Relay von einem früheren Neustart behalten hat und den sein Worker noch nicht bestätigt hat, wird als noch nicht bestätigt aufgeführt.

Läuft ein Turn, bietet das Fenster 🌄 Restart when idle (Neu starten, wenn nichts läuft), das den Neustart einreiht, und Restart now (Jetzt neu starten), das nicht wartet. Läuft nichts, heißt der Button 🌄 Restart web relay, und das Relay startet sofort neu.

Der Neustart wartet auf laufende Turns #

Der Neustart unterbricht keinen Turn. Restart when idle reiht ihn ein, und jede Seite auf jedem verbundenen Gerät zeigt ein Banner:

🌄 Relay restart queued — waiting for 2 sessions · waited 4 min of 30 min
Waiting for: Review: server/, Build docs (2 turns)
New messages are held until the restart: 3 messages waiting.

Die Session-Namen sind Links, die die Konversation öffnen. Eine Zeile Background tasks: folgt, wenn Sessions Hintergrundarbeit haben, mit der Angabe, ob sie jeweils weiterläuft. Das Banner hat zwei Buttons:

• Restart now fragt zuerst, nennt die Sessions, auf die es nicht wartet, und startet dann neu. Deren Worker laufen weiter und melden sich beim neu gestarteten Relay; die Live-Ausgabe ihrer Turns pausiert, solange das Relay weg ist, und ein Turn, dessen Antwort nicht ankommt, muss erneut gesendet werden. Unter dem Linux-Dienst können die Worker mit dem Relay stoppen, und das Fenster sagt das.
• Cancel restart (Neustart abbrechen) zieht den Neustart zurück. Die zurückgehaltenen Nachrichten gehen sofort raus.

Nur laufende Turns halten den Neustart auf. Solange er eingereiht ist, warten Nachrichten, die du sendest, in der Queue und werden keinem Agent übergeben, damit ein beschäftigtes Relay den Neustart nicht immer wieder hinausschieben kann. Sie laufen nach dem Neustart. Ein Turn, dessen Agent verstummt ist, wird nach dem Inaktivitätsfenster des Relays aufgegeben, standardmäßig 10 Minuten (processingTimeoutMs), und hält ihn danach nicht mehr auf.

Wenn das Warten lange dauert Neu in 0.9.13 #

Ein eingereihter Neustart wartet höchstens Ask after a queued relay restart has waited (Nachfragen, nachdem ein eingereihter Relay-Neustart gewartet hat) in Settings → General: standardmäßig 30 Minuten; 5, 10, 15 oder 30 Minuten, 1, 2 oder 4 Stunden oder No limit (Kein Limit). Dann wird das Banner zu einer Frage:

🌄 The relay restart has waited 30 min for 2 sessions — restart now, keep waiting or cancel?

Es bietet Restart now, Keep waiting (30 min) (Weiter warten, 30 Min.) und Cancel restart. Keep waiting wartet einen weiteren vollen Zeitraum, ab dann gezählt, und fragt erneut. Geräte mit eingeschalteten Benachrichtigungen bekommen ebenfalls eine, mit dem Titel Relay restart waiting (Relay-Neustart wartet).

Das Relay startet nie von selbst neu, solange Turns laufen, ob mit Frage oder ohne, und es startet weiterhin neu, sobald der letzte endet. Mit No limit warten ein eingereihter Neustart und die Nachrichten, die er zurückhält, bis die laufenden Turns enden oder du entscheidest. Eine geänderte Einstellung gilt auch für einen Neustart, der schon eingereiht ist.

Läuft nichts, zeigt das Banner Relay restarting now…, und das Relay ist nach wenigen Augenblicken zurück. Ein geöffnetes Gerät zeigt eventuell einen kurzen Verbindungsabbruch und, bis sich der erste Worker gemeldet hat, das Banner CLI is offline.

oar restart verhält sich genauso, wenn das Relay mit oar start oder in einem Terminal gestartet wurde: Es reiht den Neustart ein, sodass das Banner und die Frage nach der maximalen Wartezeit auch dafür gelten. Es wartet bis zu einer Minute und sagt dann, dass das Relay noch beschäftigt ist und von selbst neu startet, wenn seine Turns fertig sind. oar stop wartet auf dieselbe Weise bis zu 30 Sekunden. Läuft das Relay als systemd-Dienst (oar service install), gehen oar restart und oar stop über systemd und wirken sofort, ohne auf Turns zu warten. Ein laufender Turn endet dann und wird wie unten beschrieben behandelt.

Neu in 0.9.11 Jeder angemeldete Browser kann den Neustart einreihen oder abbrechen; es braucht nur das Zugriffstoken. Lehnt das Relay ab, zeigt die Seite seinen Grund. Von einem Terminal auf dem Host aus funktioniert oar restart immer.

Neu in 0.9.13 Ein Agent, den du bittest, das Relay neu zu starten, reiht den Neustart auf dieselbe Weise ein und erfährt, worauf der Neustart wartet, welche Nachrichten er zurückhält und welche Hintergrund-Tasks weiterlaufen, damit er es dir sagen kann. Agents sind angewiesen, das Warten nie zu überspringen: Ein Neustart ohne Warten ist Restart now, und das ist deine Entscheidung.

Was ein Neustart behält und was er verliert #

Behalten:

• Konversationen und ihr Verlauf
• Eingereihte Nachrichten, auch die, die auf den Neustart gewartet haben
• Entwürfe im Eingabebereich und Anhänge
• Neu in 0.9.11 Previews, beim Start erneut geprüft
• Neu in 0.9.11 Die Hintergrund-Tasks von Workern, die weiterlaufen
• Neu in 0.9.13 Die Task-Konsolen: fertige Zeilen für den Rest ihrer Stunde und die Ausgabe laufender Befehle
• Abonnements, die Agents eingerichtet haben, um andere Sessions zu beobachten
• Die Genehmigung, die ein Agent zum Starten von Sessions bekommen hat
• Eine Pause am Nutzungslimit
• Die Provider-Sessions der Konversationen

Verloren:

• Ein eingereihtes Suspend host (Host in den Ruhezustand versetzen; Windows), das das Relay verwirft und meldet
• Hintergrund-Tasks von Workern, die der Neustart gestoppt hat (unter dem Linux-Dienst, siehe unten)

Wurde das Relay mit oar start oder in einem Terminal gestartet, stoppt es die Worker beim Beenden nicht. Sie bemerken, dass die Verbindung weg ist, und verbinden sich erneut mit dem neuen Relay. Der Dienst von oar service install ist anders: systemd stoppt alles, was der Dienst gestartet hat, Worker eingeschlossen, weil der Dienst nichts anderes verlangt. Die nächste Nachricht an jede Konversation startet dann einen neuen Worker, und die Konversation geht wie unten beschrieben weiter.

Ein Turn, der lief, als alles ausfiel #

Ein geplanter Neustart wartet auf Turns, das betrifft also Restart now, einen Absturz, ein Kill, einen Stromausfall oder einen Reboot.

Das Relay markiert einen Turn als laufend, bis sein Worker sich meldet. Hört der Worker auf, sich zu melden, wartet das Relay sein Inaktivitätsfenster ab (standardmäßig 10 Minuten, processingTimeoutMs; höchstens 45 Sekunden, wenn überhaupt kein Worker verbunden ist) und stellt die Nachricht dann zurück in die Queue. Die Nachricht wird erneut an einen neuen Worker zugestellt, der die Provider-Session fortsetzt, sodass der Agent seine frühere Konversation hat. Dateien, die der Agent schon geändert hat, bleiben geändert.

• Eine Nachricht wird höchstens maxRequeueRetries-mal zurückgestellt (Standard 5). Dann schlägt sie fehl mit Relay recovery limit reached … Send it again to retry.
• Ein Turn, den der Agent nach einem Hintergrund-Task selbst gestartet hat, eine Fortsetzung, wird nicht zurückgestellt. Er wird verworfen, weil ein erneuter Lauf dem Agent seine eigene Benachrichtigung so übergeben würde, als wäre sie dein Prompt.
• Copilot auf der SDK-Engine behält eine fertige Antwort, die das Relay während des Neustarts nicht annehmen konnte, und bietet sie bis zu fünf Minuten lang erneut an, damit die Antwort nicht verloren geht und der Prompt nicht zweimal läuft.

Ein Worker, der den Neustart über weitergelaufen ist, behält seinen Turn: Er meldet sich beim neuen Relay, und der Turn geht weiter.

Einer unterbrochenen Session sagen, dass sie weitermachen soll Neu in 0.9.13 #

Einige Turns können nicht erneut laufen, weil der Agent die Nachricht schon übernommen hatte: eine Nachricht, die du gesendet hast, während er arbeitete, eine Fortsetzung oder ein Turn, der schon begonnen hatte, als sein Worker ohne ihn zurückkam. Ein solcher Turn hört einfach auf, und der Agent erfährt nie, dass er unterbrochen wurde.

Schalte After a relay restart, tell interrupted sessions to carry on (Nach einem Relay-Neustart unterbrochene Sessions weitermachen lassen) in Settings → General ein (standardmäßig aus, eine Einstellung des Relays), und eine solche Session bekommt eine Notiz vom Relay, sobald es zurück ist. Sie erscheint als kompakte Zeile relay in der Konversation, und der Agent liest:

Automatic message from OAR, not from the user: the relay restarted at 2026-10-20 14:05 UTC, and the turn you were working on was interrupted before it finished. Check where you were (the files you changed, the commands and background tasks you started) and carry on from there. Do not repeat steps that already completed; if the work was already done, say so briefly.

• Deine Nachricht wird nie erneut gesendet, und eine Session bekommt höchstens eine Notiz pro Neustart.
• Nichts wird gesendet an untätige Sessions, für Turns, die von selbst erneut laufen, an archivierte Konversationen oder während eine Pause am Nutzungslimit die Session hält (deren eigene Folgenachricht führt den Turn fort).
• Eine Nachricht, die du inzwischen eingereiht hast, geht zuerst; die Notiz wartet dahinter.
• Die Notiz startet den Agent der Session wie jede Nachricht. Es zählen Turns, die innerhalb von 30 Minuten nach dem Start des Relays abgebrochen wurden.

Ohne die Einstellung sende selbst eine kurze Nachricht wie „mach weiter“.

Nach Provider #

Die Konversation und die Queue hält das Relay bei jedem Provider. Was der Provider behält und wovon eine fortgesetzte Konversation also weitermacht, unterscheidet sich. Konversationen mit OpenAI Image haben keinen Worker: Das Relay ruft die Images API selbst auf, deshalb gilt nichts auf dieser Seite für sie.