Turns und die Queue
Ein Turn ist eine Arbeitsrunde: Du schickst einen Prompt, der Agent arbeitet daran und antwortet. Eine Konversation ist eine Folge von Turns, einer nach dem anderen. Schickst du eine Nachricht, während noch ein Turn läuft, hält OAR sie in einer Queue, bis der Turn vorbei ist. Macht ein Turn keinen Fortschritt mehr, bemerkt OAR das, stellt ihn zurück in die Queue oder beendet ihn mit einer Notiz und lässt ihn nicht endlos weiterlaufen.
Das Nachsteuern eines laufenden Turns und der Button Stop (Stoppen) stehen unter Während ein Turn läuft. Neustarts stehen unter Neustarts und Fortsetzen.
Die Zustände eines Turns #
| Zustand | Was du siehst |
|---|---|
| In der Queue | Deine Nachricht steht im Verlauf, darunter ein Button Cancel (Abbrechen). |
| Läuft | Die Antwortblase füllt sich, während der Agent arbeitet, mit seinen Tool-Aktivitäten und einem Button Stop. Die Konversation wird in der Liste als beschäftigt angezeigt. |
| Wartet auf eine Rückfrage | Eine Rückfrage-Karte zeigt Waiting for your answer (Wartet auf deine Antwort). Der Turn geht weiter, sobald du antwortest. |
| Fertig | Die Antwort ist vollständig. |
| Fehlgeschlagen | Die Antwort ist eine kurze Systemnotiz, die sagt, was passiert ist. Siehe Wenn ein Turn fehlschlägt. |
| Gestoppt | Du hast Stop gedrückt. |
Ein Turn, der auf eine Rückfrage-Karte wartet, gilt nie als hängend. Zur Karte selbst siehe ask_user.
Senden, während ein Turn läuft #
Was auf dem Senden-Button während eines Turns steht, sagt dir, was mit der Nachricht passiert:
- Steer (Nachsteuern): Die Nachricht geht in den laufenden Turn. Das gibt es bei Claude, DeepSeek und der SDK-Engine von Copilot.
- Queue (Einreihen): Die Nachricht wartet hinter dem Turn und startet als nächster. Der Button zeigt Queue bei allen anderen Providern und auch bei Claude, DeepSeek und der SDK-Engine, während der Turn auf eine Rückfrage-Karte oder eine Plan-Freigabe wartet oder während er kompaktiert, und bei der SDK-Engine, während ein Tool-Aufruf läuft. Dann wartet die Nachricht als eingereihte Nachricht und geht in den Turn, sobald die Karte beantwortet, die Kompaktierung beendet oder der Tool-Aufruf fertig ist.
Eingereihte Nachrichten laufen in der Reihenfolge, in der sie gesendet wurden, die älteste zuerst.
Ist dein Gerät beim Senden offline, behält der Browser die Nachricht und zeigt You are offline. Message queued — it will send when the connection returns. Das ist eine andere Queue: Sie liegt auf deinem Gerät und leert sich von selbst, wenn die Verbindung zurück ist.
Eine eingereihte Nachricht abbrechen #
Eine eingereihte Nachricht hat einen Button Cancel, bis der Agent sie übernimmt. Ein Druck darauf entfernt die Nachricht aus der Queue und zeigt Queued message cancelled. Hat der Agent inzwischen mit der Nachricht begonnen, meldet das Relay Message is already being processed. Use Stop on the thinking bubble instead.
Queue leeren #
Das ⋯-Menü einer Konversation hat eine Zeile Queue. Sie zeigt die Zahlen des
ganzen Relays, nicht nur dieser Konversation:
pending=1, processing=1, parked=0
Pending-Nachrichten warten auf ihren Turn. Processing-Nachrichten laufen. Parked-Nachrichten werden zurückgehalten, z. B. während das Relay neu startet.
🚮 Empty queue (Queue leeren) daneben verwirft alle, in jeder Konversation, auch die Nachricht eines Turns, der gerade läuft. Vorher fragt eine Bestätigung:
Drop all queue rows in pending, processing, and parked states?
This is a local maintenance action and cannot be undone.
Danach zeigt ein Hinweis Queue emptied: dropped 3 rows. oder Queue is already empty., wenn nichts zu verwerfen war. Neu in 0.9.11 Jeder angemeldete Browser kann das nutzen: Es braucht nur das Zugriffstoken (siehe Endpunkte, die nur der Rechner des Relays nutzen darf). Lehnt das Relay ab, nennt Failed to empty queue den Grund. Die Aktion entfernt die Nachrichten nur aus der Queue. Sie sagt einem laufenden Agent nicht, dass er aufhören soll; dafür ist Stop da. Um eine einzelne Nachricht loszuwerden, nutze stattdessen Cancel an ihr.
Erneut einreihen #
Ein Turn, der schiefging, ist nicht immer verloren. Das Relay stellt ihn zurück in die Queue und versucht es erneut, wenn:
- der Turn hing (siehe unten),
- der Worker-Prozess der Session starb, während er lief,
- der Worker einen Fehler meldete, bei dem sich ein weiterer Versuch lohnt.
Jedes erneute Einreihen zählt als Versuch. Das Limit ist 5 Versuche pro
Nachricht (max in der Config-Datei, beim Start gelesen), der
fünfte Fehlschlag ist also endgültig. Die Wartezeit bis zum nächsten Versuch
hängt von der Ursache ab:
| Ursache | Wartezeit |
|---|---|
| Ein Turn, der hing | 30 Sekunden (2 Sekunden, solange das Relay die Verbindung zu seinem Agent als offline ansieht) |
| Der Worker-Prozess der Session starb | 2 Sekunden |
| Der Worker meldete einen Fehler | 1, 2, 4, dann 8 Minuten nach dem ersten, zweiten, dritten und vierten Fehlschlag |
| Der Worker meldete einen Fehler innerhalb von 15 Sekunden nach dem Start, vor jeder Aktivität oder jedem Antworttext | 10, 20, 40, dann 80 Sekunden |
Am Limit schlägt die Nachricht endgültig fehl, mit einer Notiz (siehe unten).
Zwei Arten von Turns werden nicht wiederholt. Eine Nachricht, die schon in einen laufenden Turn eingeflossen war, würde zweimal beantwortet; sie schlägt deshalb stattdessen mit einer Notiz fehl. Die eigene Fortsetzungsantwort eines Hintergrund-Tasks hat keinen Prompt, der erneut gesendet werden könnte; sie wird verworfen.
Wenn ein Turn hängt #
Ein Turn kann langsam sein, oder er kann hängen. OAR kann das nicht an der Antwort erkennen und achtet deshalb auf Lebenszeichen. Es gibt drei Arten der Überwachung: Das Relay überwacht den Worker, jeder Worker überwacht seinen Agent, und zwei Limits begrenzen Hintergrundarbeit und Rückfrage-Karten.
| Timer | Standard | Wo du ihn änderst | Was du siehst, wenn er auslöst |
|---|---|---|---|
| Inaktivität: kein Lebenszeichen vom Worker der Session | 10 Min. (45 s, solange das Relay die Verbindung zu seinem Agent als offline ansieht) | processing in der Config-Datei, in Millisekunden; starte das Relay nach dem Bearbeiten neu |
Der Turn geht zurück in die Queue und startet nach 30 Sekunden erneut. |
| Max turn duration (Maximale Turn-Dauer): die Gesamtzeit eines Turns | 60 Min., 0 bis 10 h in 5-Minuten-Schritten; 0 heißt kein Limit | Settings → General → Max turn duration (Einstellungen → Allgemein → Maximale Turn-Dauer) | Dasselbe: zurück in die Queue. Bei Grok schlägt der Turn stattdessen mit einer Notiz fehl. |
| Stille einer Runtime von Copilot (SDK-Engine), Cursor oder Grok: nichts in Arbeit | 120 s | OAR_ in der Umgebung des Relays; 0 schaltet die Überwachung ab |
Der Turn schlägt mit einer Systemnotiz fehl. |
| Dasselbe, während eine Modellanfrage läuft | 300 s | OAR_; 0 heißt kein Limit |
Der Turn schlägt mit einer Systemnotiz fehl. |
| Dasselbe, während ein Tool-Aufruf läuft | 30 Min. | OAR_; 0 heißt kein Limit |
Der Turn schlägt mit einer Systemnotiz fehl. |
| Background task timeout (Timeout für Hintergrund-Tasks): Nur Hintergrundarbeit hält eine Session nach ihrer Antwort am Laufen | 4 h, 0 bis 10 h in 5-Minuten-Schritten; 0 heißt kein Limit | Settings → General → Background task timeout | Das Relay stoppt die Tasks. Bei Claude Cloud endet stattdessen der Turn. Siehe Nach Provider. |
| Warten auf eine Rückfrage-Karte | 8 h; 2 h bei der Extension-Engine von Copilot | Nicht einstellbar | Der Agent erfährt, dass niemand geantwortet hat, und macht je nach Modus der Konversation weiter. |
Die drei OAR_-Variablen unter Linux und macOS
Wo Sessions unter tmux laufen, wird eine für das Relay gesetzte Variable nicht an die Prozesse der Agents weitergegeben, und diese drei wirken dann möglicherweise nicht. Siehe welche Variablen die Agents erreichen.
So greifen sie ineinander:
- Das Relay überwacht den Worker. Der Worker meldet alle 10 Sekunden, an welcher Nachricht er arbeitet. Solange er das tut, lebt der Turn, egal wie lange er läuft. Bleiben die Meldungen für die Dauer des Inaktivitätsfensters aus, stellt das Relay den Turn zurück in die Queue. Es prüft alle 15 Sekunden.
- Max turn duration ist der harte Stopp. Sie fängt einen Worker ab, der hängt, aber weiter meldet. Ein Turn ist über dem Limit, wenn der spätere von zwei Zeitpunkten älter ist als die Einstellung: der Start des Turns und die letzte Rückfrage-Karte, die du beantwortet hast. Ein Interview, das stundenlang auf deine Antworten gewartet hat, wird also nicht direkt nach der letzten Antwort abgebrochen. Es gibt einen Haken. Wenn die Prüfung irgendeinen Turn erneut einreiht, reiht sie jeden laufenden Turn erneut ein, dessen Start älter ist als das Limit, und schaut bei diesen nicht auf deine Antworten. Ein Turn, in dem du kürzlich eine Karte beantwortet hast, kann deshalb zusammen mit einem anderen Turn zurück in die Queue gehen, der in derselben Prüfung (alle 15 Sekunden) ein Limit erreicht hat. Wird ein langer Turn ohne erkennbaren Grund erneut eingereiht, erhöhe diese Einstellung oder setze sie auf 0.
- Jeder Worker überwacht auch seinen Agent. Bei der SDK-Engine von Copilot, Cursor und Grok schlägt ein Turn fehl, wenn von der Runtime länger als ihr Fenster überhaupt kein Ereignis kommt. Das Fenster hängt davon ab, was die Runtime gerade tut: Ein Befehl, der nichts ausgibt, kann lange still sein, ein Modell, das schreibt, nicht. Deshalb unterscheiden sich die drei Fenster. Ist nur das Leerlauffenster gesetzt, skalieren die anderen beiden mit.
- Ein wartender Turn hängt nie. Ein Turn, der auf eine Rückfrage-Karte
wartet, hält beide Wächter des Relays und die Stille-Überwachung des Workers an. (Die Grok-Obergrenze und das 2-Stunden-Limit der Extension-Engine pausieren dafür nicht.) Eine Kompaktierung und ein
relay_-Aufruf halten die Stille-Überwachung ebenfalls an. Max turn duration kennt kein langes Warten auftool relay_; ein Warten nahe an dessen Maximum kann mit den standardmäßigen 60 Minuten deshalb von ihr abgebrochen werden.tool - Hintergrund-Tasks sind getrennt. Der Task-Timeout zählt erst nach der Antwort, wenn nur noch Hintergrund-Tasks die Session am Laufen halten. Er begrenzt keinen Turn. Claude Cloud ist die Ausnahme, siehe unten.
Ein erneutes Einreihen wird nicht als Fehler angezeigt. Die Nachricht geht zurück auf queued und läuft erneut. Erst wenn die Versuche aufgebraucht sind, schlägt der Turn fehl.
Wenn ein Turn fehlschlägt #
Ein fehlgeschlagener Turn endet mit einer Antwort des Relays, in reinem Text. Sie sagt, was passiert ist, endet mit einem Fehlercode und sagt dir, was du als Nächstes tun kannst. Ein Turn, den die Stille-Überwachung beendet hat, lautet z. B.:
System note: the Copilot runtime sent nothing for 300s while a model request was running, so the relay ended the turn.
Lief gerade ein Tool, nennt die Notiz es: while a tool was running (build). Eine Runtime, die auf Nachfrage des Relays nicht mehr antwortet, liest sich als the Copilot runtime stopped answering … (nothing for 120s, no reply when asked), so the relay ended the turn.
Eine Nachricht, deren Versuche aufgebraucht sind, schlägt mit einer dieser Meldungen fehl:
Relay timeout after 5 attempts. Message was skipped to keep the queue moving. Retry the message.
Relay recovery limit reached after 5 attempts (stale-recovery). The worker kept dying before completing this turn, so the message was failed to keep the queue moving. Send it again to retry.
Die meisten Fehlschläge enden mit dem Rat, die Nachricht erneut zu senden. Zwei Dinge helfen:
- Erneut senden. Füge die Nachricht ein oder tippe sie neu, oder drücke Resend (Erneut senden), wo der Verlauf es anbietet. Resend erscheint an einer Nachricht, die in einen Turn nachgesteuert wurde, der dann fehlschlug oder gestoppt wurde. Ihre Markierung lautet Steered into the turn above, which failed — not answered. oder Stopped with the turn — not answered. Nachdem du ihn gedrückt hast, zeigt der Button auf jedem Gerät Resent (Erneut gesendet).
- Den Button an der Antwort nutzen. Manche Fehlschläge nennen eine Korrektur, die das Relay für dich vornehmen kann, und die fehlgeschlagene Antwort trägt einen Button dafür. Ein Problem mit dem Claude-Konto zeigt Claude settings (Claude-Einstellungen). Neu in 0.9.17 Ein DeepSeek-Turn, der abgelehnt wurde, weil das Guthaben aufgebraucht ist, zeigt Top up DeepSeek (DeepSeek aufladen) und DeepSeek settings (DeepSeek-Einstellungen); einer, der wegen des API-Keys abgelehnt wurde, zeigt DeepSeek settings (siehe DeepSeek-Fehler). Ein Grok-Turn, der nicht starten konnte, zeigt Install Grok CLI (Grok CLI installieren) und Grok settings (Grok-Einstellungen) oder Sign in to Grok (Bei Grok anmelden) und Grok settings, wenn keine Anmeldung bestand.
Eine Konversation, deren Session-Worker wegen eines Startproblems stoppte, zeigt an der Notiz einen Button Retry (Erneut versuchen), der den Worker erneut startet.
Eine Konversation, die festzustecken scheint, lässt sich mit ☠️ Kill session (Session beenden) im
⋯-Menü befreien; das stoppt ihren Worker. Sende die Nachricht danach erneut.
Nach Provider #
Die Queue, Cancel, Empty queue, das Inaktivitätsfenster und Max turn duration sind bei jedem Provider gleich. Was sich unterscheidet, ist die Überwachung des Agents selbst.
| Provider | Stille-Überwachung | Steer oder Queue |
|---|---|---|
| GitHub Copilot und OpenAI, SDK-Engine | Ja: 120 s, 300 s und 30 Min. Einmal pro Leerlauffenster fragt der Worker die Runtime, ob sie noch da ist, mit 5 Sekunden Zeit für die Antwort; eine Runtime, die nicht antwortet, beendet den Turn sofort. | Steer |
| GitHub Copilot, Extension-Engine | Keine Stille-Überwachung. Ein Turn ist insgesamt auf 2 Stunden begrenzt; läuft das ab, geht der Turn zurück in die Queue und zählt als fehlgeschlagener Versuch, mit den Wartezeiten oben. Mit den standardmäßigen 60 Minuten greift normalerweise Max turn duration zuerst. Eine Rückfrage-Karte wartet 2 Stunden. | Queue |
| Claude | Beobachtet nur. Ein Turn, in dem die CLI 10 Minuten lang nichts gesagt hat (30 mit offenem Tool), wird ins Log des Workers geschrieben und läuft weiter, weil ein Beenden die CLI und ihre Hintergrund-Tasks töten würde. | Steer |
| DeepSeek Neu in 0.9.17 | Wie Claude: Ein DeepSeek-Chat führt Claude Code aus, mit derselben Überwachung, die nur beobachtet. | Steer |
| Claude Cloud | Keine Stille-Überwachung des Agents. Der Worker überwacht seine Verbindung: Ein Stream ohne Daten für 120 s wird neu geöffnet, und ein Stream, der 5 Minuten wegbleibt, gibt die Nachricht an die Queue zurück, wo der nächste Versuch demselben Turn folgt, statt ihn erneut zu senden. Ein Cloud-Turn, der still ist, während seine Verbindung lebt, läuft weiter. Beendet der Agent seinen Turn, während noch Hintergrundarbeit läuft, bleibt der Turn für Background task timeout offen (60 Minuten, wenn das 0 ist). Dann endet er mit einer Aktivitätszeile, die dir sagt, eine Nachricht zu senden, um zu sehen, wie die Arbeit gelaufen ist. | Queue |
| Cursor | Ja, mit denselben drei Fenstern. Während ein Lauf geht, gibt es keine Idle-Phase: Er zählt als Modellanfrage, außer ein Tool-Aufruf ist offen. | Queue |
| Grok | Ja, mit denselben drei Fenstern; bei einem ausstehenden relay_-Aufruf wird zuerst nachgefragt. Ein OAR_ von 0 schaltet sie hier nicht ab. Der Turn ist außerdem auf Max turn duration begrenzt, gezählt ab dem Start des Turns ohne Neubeginn bei beantworteten Rückfragen, und eine Karte, die du unbeantwortet lässt, zählt mit. Ein Grok-Turn, der die Obergrenze erreicht, schlägt fehl mit System note: the Grok turn stalled and was stopped (grok turn exceeded the 60-minute turn ceiling). Send a new message to retry. (oder der Zahl, die du eingestellt hast). |
Queue |
Background task timeout gilt für Claude, Claude API, DeepSeek, die SDK-Engine von Copilot und Claude Cloud. Bei Claude, Claude API und DeepSeek stoppt er die Hintergrund-Tasks. Bei der SDK-Engine von Copilot bricht das Relay sie ab. Bei Claude Cloud legt er nur fest, wie lange der Turn auf sie wartet. Für die anderen Provider gilt er nicht.