relay_tool Neu in 0.9.4

Mit relay_tool arbeitet ein Agent mit anderen Sessions: Er listet und liest sie, schickt einer einen Prompt, startet eine neue, wartet auf die Antwort, beantwortet eine Frage, die der andere Agent gestellt hat, stoppt oder archiviert eine Session und kann sich wecken lassen, wenn in Sessions, die er beobachtet, etwas passiert.

Es erreicht zwei Arten von Relays:

• Dieses Relay, das, auf dem der Agent selbst läuft. Ein Agent kann Teile seiner Aufgabe an andere Sessions hier abgeben. Aus, bis du es einschaltest. Neu in 0.9.7
• Gekoppelte Relays, andere OAR-Relays, die du mit diesem gekoppelt hast, zum Beispiel das Relay auf deiner Workstation und das auf einem Server. In jeder Konversation gesperrt, bis du das Relay erwähnst.

Das Tool ist bei jedem Provider gleich, der es hat; unter Nach Provider steht, wer es hat und unter welchem Namen.

Der Name Neu in 0.9.18 #

Bis 0.9.17 hieß das Tool remote_relay. Jetzt erscheint es bei jedem Provider als relay_tool (der Agent von Claude sieht mcp__relay__relay_tool), mit denselben Aktionen und Feldern. Tool-Zeilen, die unter dem alten Namen geschrieben wurden, erscheinen weiterhin als dieses Tool.

• Sessions, die liefen, als du aktualisiert hast. Der Agent einer Session bekommt seine Tool-Liste, wenn ihr Worker startet, und Worker laufen über den Neustart des Relays hinweg weiter. Der Agent einer solchen Session hat das Tool noch als remote_relay, bis ihr Worker wieder startet, zum Beispiel nach Kill session (Session beenden). Seine Aufrufe funktionieren weiter: Sie erreichen das Relay unter beiden Namen auf dieselbe Weise. Wo das Relay als Linux-Dienst läuft, können die Worker mit dem Relay stoppen und kommen dann mit dem neuen Namen zurück.
• Der eigene MCP-Server von OAR, den Grok und die Extension-Engine von Copilot nutzen, führt einen Aufruf von remote_relay noch aus, listet es aber nicht mehr.
• Deine eigenen Anweisungen. Wenn deine Anweisungen, Berechtigungsregeln oder Hooks remote_relay oder mcp__relay__remote_relay nennen, ändere sie auf relay_tool oder mcp__relay__relay_tool: Außerhalb des MCP-Servers von OAR wird der alte Name abgelehnt.

Was du siehst #

• Freigabekarten. Eine Rückfrage-Karte fragt vor der ersten Session, die ein Agent in einer Konversation startet, bevor er zum ersten Mal Sessions beobachtet, und vor jeder schreibenden Aktion, solange die Konversation im Relay-Modus ask oder plan ist.
• Der Tool-Aufruf in der Antwort. Die Aktivität des Agents zeigt jeden Aufruf mit einem 🛰️, der Aktion, dem Relay und der Session.
• „via agent“. Eine Session, die ein Agent gestartet hat, trägt via agent · "title" (über Agent · „Titel“) in der Konversationsliste und unter ihrem Titel, mit der Konversation, in der der Agent läuft. Neu in 0.9.11 Sie steht in einer Session-Gruppe unter dieser Konversation, Neu in 0.9.16 oder in einer bestehenden Gruppe, die der Agent genannt hat.
• „↗ from …“ (von …). Ein Prompt, den ein Agent gesendet hat, trägt auf der empfangenden Seite eine Badge mit dem sendenden Relay, der Session und dem Modell.
• Beobachten. Eine Konversation, die andere beobachtet, zeigt watching N sessions (beobachtet N Sessions) in ihrem Header; der Chip listet ihre Abonnements auf, jedes mit einem Button Unsubscribe (Abbestellen). Eine beobachtete Session zeigt eine Badge watched (beobachtet).

Einschalten #

relay_tool wird Agents angeboten, wenn mindestens eines davon zutrifft:

Ob eine Session das Tool bekommt, erfährt sie, wenn ihr Agent-Prozess startet. Eine Konversation, die schon lief, hat es daher vielleicht erst, wenn ihr Agent neu gestartet ist.

Ein Relay benennen #

Jede Aktion außer list_relays arbeitet auf einem Relay, das in relay genannt wird:

• "this" oder der eigene Name dieses Relays ist das Relay, auf dem der Agent läuft. Es braucht keine Erwähnung.
• Ein gekoppeltes Relay wird über seinen Relay-Namen oder seinen Host benannt, so wie list_relays es zeigt.

Bei den vier Abonnement-Aktionen, Neu in 0.9.16 den drei Zeitplan-Aktionen und den drei Frage-Aktionen darf relay fehlen und bedeutet dann "this". Zeitpläne funktionieren nur auf diesem Relay.

Gesperrt und entsperrt #

Ein gekoppeltes Relay bleibt in einer Konversation gesperrt, bis eines davon passiert:

• Du erwähnst es in einer deiner Nachrichten: Tippe @ und wähle es, oder schreib seinen Namen oder Host-Namen. Ein Relay, dessen Name eine IP-Adresse oder localhost ist, zählt nur mit einem vorangestellten @.
• Ein Agent auf jenem Relay schreibt in die Konversation. Das Relay ist dann offen, damit der Agent hier antworten kann.

Einmal entsperrt, bleibt es für den Rest der Konversation offen. Ein gesperrtes Relay lehnt jede Aktion außer list_relays ab; der Agent soll dich bitten, das Relay zu erwähnen.

Berechtigungen und Freigaben #

Was ein gekoppeltes Relay erlaubt #

Jedes gekoppelte Relay hat unter Settings → Relays eine Stufe Agents may (Agents dürfen). Neue Kopplungen beginnen mit Full (Vollzugriff).

list_relays braucht keine Stufe. Dieses Relay selbst zählt immer als Full.

Auf der anderen Seite schaltet Accept prompts from other relays' agents (Prompts von Agents anderer Relays annehmen) (Settings → Relays auf dem gekoppelten Relay) alles ab, was die Agents eines anderen Relays dort ändern oder beobachten könnten: Sessions prompten, starten, beantworten, stoppen und archivieren und sie abonnieren. Sessions auflisten und lesen, Task-Ausgaben lesen, warten, relay_info und usage funktionieren weiter.

Wann du gefragt wirst #

Regeln für Sessions auf diesem Relay #

• Höchstens 4 bei der Arbeit. Von den Sessions, die der Agent einer Konversation gestartet hat, dürfen 4 gleichzeitig einen Turn eingereiht oder laufend haben. Eine fünfte wird abgelehnt, bis eine fertig ist.
• Nur eine Ebene. Eine Session, die ein Agent erstellt hat, kann selbst keine Sessions erstellen, Neu in 0.9.16 es sei denn, du hast Agents in this conversation may start sessions (Agents in dieser Konversation dürfen Sessions starten) für sie eingeschaltet. list_sessions und read_session zeigen dann "mayCreateSessions": true. Kein Agent kann diesen Schalter setzen.
• Nicht auf sich selbst. Ein Agent kann die Konversation, in der er läuft, nicht mit send prompten, nicht mit wait auf sie warten, sie nicht mit stop stoppen oder mit archive archivieren, seine eigene Frage nicht beantworten Neu in 0.9.16 und ihre Einstellungen nicht ändern.
• Deine Konten. Sessions, die ein Agent startet, nutzen die Provider-Konten dieses Relays und zählen gegen deren Verbrauch.
• Das Relay archiviert diese Sessions nie von selbst. Sie bleiben in deiner Liste, bis du sie archivierst oder löschst oder der Agent eine archiviert.

Über Relays hinweg #

• Ein Prompt, der schon zwei Relays überquert hat, wird nicht an ein drittes weitergegeben, es sei denn, du hast jenes Relay selbst entsperrt. Lesen und Warten sind dadurch nie begrenzt.
• Der Prompt, den der andere Agent bekommt, beginnt mit einer Zeile, die sagt, dass ein anderer Agent mit ihm spricht: [Remote prompt from an agent on relay "…" · session "…" · model · acting for the user].
• Turns, die so gestartet wurden, senden auf dem anderen Relay keine Benachrichtigung „Antwort bereit“. Rückfrage-Karten benachrichtigen weiterhin.
• Entfernte Adressen müssen https:// verwenden. Einfaches http:// wird nur für Loopback-Adressen und private Netzbereiche akzeptiert.

Aktionen #

Jeder Aufruf nennt eine action. Die Tabelle zeigt, was jede braucht; die Stufe ist die niedrigste Einstellung von Agents may, die sie auf einem gekoppelten Relay erlaubt.

Ein Ergebnis ist JSON. Ein Aufruf, der geklappt hat, hat "ok": true, das relay, auf dem er gearbeitet hat, und eine einzeilige summary; ein Aufruf, der fehlgeschlagen ist, hat "ok": false, einen code und einen Text in error (Fehler). Die Beispiele unten zeigen die wichtigsten Felder, mit erfundenen Namen und IDs.

Neu in 0.9.16 Ein Argument, das eine Aktion nicht annimmt, wird nie stillschweigend verworfen. create_session und update_session lehnen den Aufruf mit REMOTE_RELAY_INVALID_INPUT ab, nennen ihre eigenen Argumente und ändern nichts: create_session does not take: session. Its arguments: relay, text, provider, model, cwd, repo, branch, mode, effort, title, group, wait_seconds. Nothing was created. Jede andere Aktion läuft trotzdem und listet die Argumente, die sie nicht angenommen hat, in ignored in ihrem Ergebnis auf, bis zu 20. Ein leerer Wert (null, "", false oder eine leere Liste) zählt als kein Argument, weil manche Provider jedes Feld senden.

Relays und Sessions finden #

list_relays #

Listet die gekoppelten Relays mit name, url, online, version, permission und unlocked auf. Wenn Agent-Sessions eingeschaltet sind, kommt dieses Relay zuerst, markiert mit "self": true. Gibt auch die Wartegrenze dieses Relays zurück. Es ist die einzige Aktion, die ohne Erwähnung und ohne relay funktioniert.

{ "action": "list_relays" }

{
  "ok": true,
  "summary": "list_relays: 2 relays, 1 unlocked",
  "self": { "name": "desk" },
  "relays": [
    { "name": "desk", "self": true, "online": true, "version": "0.9.19", "permission": "full", "unlocked": true },
    { "name": "build-box", "url": "https://build-box.example.com", "online": true, "version": "0.9.19", "permission": "full", "unlocked": false }
  ],
  "limits": { "maxWaitSeconds": 600, "maxActiveSessions": 4 }
}

relay_info #

Was ein Relay bietet, damit der Agent einen Provider, ein Modell und einen Ordner für eine neue Session wählen kann: seinen Namen, seine Version und Plattform, ob es Prompts von Agents annimmt, jeden Provider mit seinem Standardmodell, seinen Modellen und Reasoning-Efforts, den Standard-Arbeitsordner und die zuletzt genutzten Arbeitsordner und die Relay-Modi.

{ "action": "relay_info", "relay": "build-box" }

Neu in 0.9.16 Es listet auch die Session-Gruppen des Relays in groups auf, also die, die ein create_session dort nennen darf: jede mit id, name (was die Seitenleiste zeigt; der Titel der Kopf-Session bei einer Gruppe, die niemand benannt hat) und memberCount, die Gruppe mit der jüngsten Aktivität zuerst. Aufgeführt sind nur Gruppen mit mindestens einer Session, die nicht gelöscht ist, höchstens 50; groupsTotal sagt, wie viele es gibt, wenn es mehr sind. IDs und Titel der Mitglieder stehen nicht darin. Wenn die Gruppen des Relays nicht gelesen werden können, zum Beispiel weil es ein älteres OAR ausführt, ist groups null, und groupsNote sagt, warum, und dass create_session dort kein group annehmen kann.

"groups": [
  { "id": "grp_…", "name": "Release 2.4", "memberCount": 3 },
  { "id": "grp_…", "name": "Review: server/", "memberCount": 2 }
]

usage Neu in 0.9.10 #

Was der Plan jedes Providers auf einem Relay noch übrig hat (siehe Check Usage), damit ein Agent nachsehen kann, bevor er Arbeit beginnt, die etwas kostet: je Provider einen Status und seine Anzeigen (verbraucht, Kontingent, verbleibend, Auslastung, Zeitpunkt des Zurücksetzens) und ob ein Nutzungslimit von Claude dort Turns pausiert hat. Provider, die nicht eingerichtet sind oder nicht erfasst werden, sagen das. Kontonamen, Adressen und Tokens sind nie enthalten.

{ "action": "usage", "relay": "this" }

list_sessions #

Listet Sessions mit id, title, provider, model, state, cwd, dem Zeitpunkt der letzten Aktivität und einer Nachrichtenzahl auf. state ist running_turn, background_only (der Agent hat geantwortet, Hintergrundarbeit läuft noch) oder idle; tasks listet die Hintergrund-Agents und Shell-Tasks auf.

Neu in 0.9.11 Eine Session in einer Session-Gruppe hat auch group: deren id, deren name und die role der Session darin, head oder member. Neu in 0.9.16 create_session kann die Session, die es erstellt, in eine bestehende Gruppe setzen, und update_session kann eine Session in eine Gruppe verschieben, auch in eine neue, oder aus ihr herausnehmen. Gruppen umbenennen, auflösen und neu ordnen bleibt dir überlassen.

{ "action": "list_sessions", "relay": "build-box", "scope": "active" }

read_session #

Liest die letzten Nachrichten einer Session, zusammen mit dem, was dort gerade passiert: ihren state, eine Antwort, die noch geschrieben wird (inFlight), und alle pendingQuestions, die auf eine Antwort warten (Neu in 0.9.16 jede mit kind: ask für einen Ask, ask_user für eine Karte, auf die die Session wartet). Neu in 0.9.11 Bei einer Session in einer Gruppe fügt group die anderen Mitglieder hinzu, bis zu 50, jedes mit id, title, role, state und archived, wenn es archiviert ist.

{ "action": "read_session", "relay": "build-box", "session": "3f9c…", "last": 5 }

Neu in 0.9.12 Jeder der tasks der Session hat auch seine taskId, output (ob es Ausgabe gibt, die man mit read_task_output lesen kann) und, bei einem Befehl, dessen Ausgabe in einer Datei steht, health: minutesSinceOutput, quiet und quietAfterMinutes (die Einstellung für stille Tasks des Relays), während er läuft, und die counts des Testlaufs, wenn es welche gibt.

read_task_output Neu in 0.9.12 #

Liest das Ende der Ausgabe eines Shell-Befehls oder Monitors im Hintergrund, dieselbe Ausgabe, die die Task-Konsole zeigt: während der Task läuft und noch eine Stunde, nachdem er geendet hat. Ein Agent kann prüfen, ob ein Build auf einem anderen Relay noch beschäftigt ist, still geworden ist oder fehlgeschlagene Tests hat, ohne den Agent zu fragen, der ihn gestartet hat.

Das Ergebnis hat task (Beschreibung, Typ, Start, status und exitCode), tail (die Zeilen, als reiner Text ohne Farben, eine wiederholte Zeile markiert mit [×N]), truncated, wenn davor noch mehr kommt, stall (Minuten seit der letzten Ausgabe und quiet gemessen an der Einstellung des Relays), während der Task läuft, und counts mit dem Test-Runner und seinen bestandenen, fehlgeschlagenen und übersprungenen Tests, wenn die Ausgabe ein Testlauf ist. Zugangsdaten werden wie in der Konsole unkenntlich gemacht. Eine note sagt, wenn nur das Ende der Ausgabe existiert, wenn die Ausgabe nicht mehr da ist oder wenn der Prozess des Agents danach gefragt wurde und der Aufruf in ein paar Sekunden wiederholt werden sollte.

{ "action": "read_task_output", "relay": "build-box", "session": "3f9c…", "task_id": "b7k2…", "lines": 50 }

{
  "ok": true,
  "summary": "read_task_output → build-box session 3f9c2a1e task b7k2m9q4: 50 lines, running, last output 14 min ago, 412 passed, 2 failed",
  "task": { "id": "b7k2…", "description": "npm test", "type": "local_bash", "status": "running", "exitCode": null },
  "stall": { "minutes": 14, "since": "2026-10-18T09:12:00.000Z", "quiet": true, "quietAfterMinutes": 10 },
  "counts": { "runner": "vitest", "passed": 412, "failed": 2, "skipped": 0, "final": false },
  "tail": ["…"],
  "truncated": true
}

Ein Task, der nicht läuft und nicht innerhalb der letzten Stunde geendet hat, antwortet mit REMOTE_RELAY_NOT_FOUND; ein Relay älter als 0.9.12 antwortet mit REMOTE_RELAY_UNSUPPORTED.

Prompten #

send #

Reiht einen Prompt in einer bestehenden Session ein und wartet auf die Antwort.

{ "action": "send", "relay": "build-box", "session": "3f9c…", "text": "Did last night's deploy go through? Answer in two lines." }

{
  "ok": true,
  "relay": "build-box",
  "status": "done",
  "session": "3f9c…",
  "message_id": "b41e…",
  "reply": { "text": "Yes. The deploy finished at 02:14 and the health check is green.", "model": "…" }
}

Die Abrechnung einer Claude-Session umstellen Neu in 0.9.18 #

send mit provider verschiebt eine Claude-Session zwischen dem Abo und dem API-Key für Claude API und sendet die Nachricht, in einem Aufruf: Eine abgelehnte Umstellung sendet nichts, und eine abgelehnte Nachricht stellt nichts um. Die andere Abrechnung muss auf dem Ziel-Relay eingerichtet sein. Die Freigabekarte, wo eine gefragt wird, sagt Switches billing to API key oder Switches billing to subscription.

• Eine Umstellung, die das Ziel-Relay ablehnt, kommt mit REMOTE_RELAY_PROVIDER_UNAVAILABLE zurück, wenn Claude API oder Claude dort nicht eingerichtet ist oder das Monatslimit erreicht ist, und mit REMOTE_RELAY_UNKNOWN_MODEL, wenn das Modell der Session nicht auf der Liste der anderen Seite steht. remoteCode trägt den eigenen Code des Relays, zum Beispiel CLAUDE_API_CAP_REACHED.
• Ein Relay vor 0.9.18 kann nicht umstellen: Der Aufruf wird mit REMOTE_RELAY_UNSUPPORTED abgelehnt, und nichts wird gesendet.
• Ohne provider behält die Session ihre Abrechnung. Ein send an eine Session, die über den Key läuft, während das Limit erreicht ist, wird abgelehnt, und nichts wird eingereiht: Sende mit provider: "claude", um sie auf das Abo zu verschieben, oder bitte den Benutzer, das Limit anzuheben.

create_session #

Startet eine neue Session und gibt ihr ihren ersten Prompt. Die neue Session weiß nichts von der Konversation, aus der sie gestartet wurde, daher muss der Prompt für sich allein stehen.

Nimmt text, wait_seconds, mode, model und effort wie send an, und dazu:

Was der Agent weglässt, folgt der Session, in der er arbeitet, soweit das Ziel-Relay es anbietet. Ein OpenAI-Image-Chat kann so nicht gestartet werden.

{
  "action": "create_session",
  "relay": "this",
  "title": "Review: server/",
  "cwd": "/home/dev/projects/shop",
  "text": "Review the code under server/ for missing input checks. List findings with file and line. Change nothing."
}

Eine Claude-Cloud-Session nimmt statt eines Ordners ein Repository:

{
  "action": "create_session",
  "relay": "this",
  "provider": "claude-cloud",
  "repo": "example-org/sample-repo",
  "branch": "feature/banner",
  "text": "On branch feature/banner, change the sample banner text to \"Hello\" and push. Report what changed.",
  "wait_seconds": 60
}

Das Ergebnis ist dasselbe wie bei send, dazu das, womit die Session gestartet wurde: provider, model, mode, effort, title und repo / branch bei einer Cloud-Session. Neu in 0.9.16 Es hat auch group, die Session-Gruppe, in die die neue Session gekommen ist, so wie list_sessions sie zeigt (id, name, role), oder null.

In eine Gruppe setzen Neu in 0.9.16 #

Ohne group kommt eine Session, die auf diesem Relay gestartet wird, in die Gruppe der Session, die sie gestartet hat, oder gründet eine Gruppe mit dieser Session als Kopf. Eine Session, die auf einem gekoppelten Relay gestartet wird, kommt in keine Gruppe.

Mit group kommt die neue Session stattdessen in diese bestehende Gruppe, auf diesem Relay oder auf einem gekoppelten. Der Agent nennt die Gruppe über ihre id oder über ihren Namen, so wie relay_info ihn auflistet, in beliebiger Groß- und Kleinschreibung. Ein leeres group zählt als keine Gruppe.

{
  "action": "create_session",
  "relay": "build-box",
  "group": "Release 2.4",
  "text": "Run the release checklist in docs/RELEASE.md up to the tag. Report each step."
}

Das Relay schlägt die Gruppe auf dem Ziel nach, bevor es eine Freigabekarte zeigt, wie beim Modell, und die Karte nennt sie (Group: Release 2.4 (grp_…)). Nichts wird erstellt, wenn:

• das Ziel keine Gruppe mit dieser ID oder diesem Namen hat. Der Aufruf wird mit REMOTE_RELAY_UNKNOWN_GROUP abgelehnt, und error und groups listen die Gruppen dort auf (bis zu 20, groupsTotal, wenn es mehr sind): Relay "build-box" has no session group "Relase". Groups there: Release 2.4 (grp_…), … No session was created.
• der Name auf mehr als eine Gruppe passt. Derselbe Code, mit den Gruppen dieses Namens: … Pass the id.
• die Gruppe zwischen dem Nachschlagen und dem Start aufgelöst wurde. Derselbe Code.
• die Gruppen des Ziels nicht gelesen werden können. Ein Relay, das zu alt für group ist, antwortet mit REMOTE_RELAY_UNSUPPORTED (The target relay doesn't support groups on create_session yet: …); eines, das nicht antwortet oder das Token ablehnt, antwortet mit seinem üblichen Code.

Wenn die Session erstellt wurde, aber nicht in der gewünschten Gruppe gelandet ist, hat das Ergebnis groupWarning, seine summary endet mit (no group: …), und die note bittet den Agent, es dir zu sagen. Du kannst die Session dann von Hand verschieben.

create_session nimmt nur eine bestehende Gruppe an. Um die Session in eine neue Gruppe zu setzen, ruft der Agent danach update_session mit diesem Namen auf. Gruppen umbenennen, auflösen und neu ordnen bleibt dir überlassen.

update_session Neu in 0.9.16 #

Ändert die Einstellungen einer anderen Session für ihre nächsten Turns, ohne sie zu prompten, und antwortet mit den Einstellungen, die sie jetzt hat, und dem, was sich geändert hat. Es funktioniert auf diesem Relay und auf einem gekoppelten.

Mindestens eine Einstellung ist nötig. Jedes andere Argument wird abgelehnt, und nichts wird geändert. mayCreateSessions gehört nicht zu den Einstellungen: Whether a session may start sessions is the owner's setting alone.

{ "action": "update_session", "relay": "this", "session": "3f9c…", "model": "claude-sonnet-5-5", "effort": "low", "group": "Release 2.4" }

{
  "ok": true,
  "summary": "update_session → desk session 3f9c2a1e: model, effort, group",
  "session": "3f9c…",
  "settings": {
    "model": "claude-sonnet-5-5", "effort": "low", "mode": "agent", "auto_compact_window": "auto",
    "title": "Review: server/", "group": { "id": "grp_…", "name": "Release 2.4", "role": "member" },
    "thinking_enabled": true, "thinking_display": "summarized", "cwd": "/home/dev/projects/shop"
  },
  "changed": ["model", "effort", "group"]
}

Ein Wechsel in einen neuen Ordner sagt auch, ob die CLI neu gestartet wurde (relaunched), und eine neue Gruppe kommt als groupCreated zurück. Ein Aufruf, der nichts ändern würde, antwortet mit changed: [] und fragt niemanden. note trägt, was der Agent wissen sollte, zum Beispiel ein Fenster, das auf das nächstliegende gesetzt wurde, oder dass das Fenster und das Thinking nur für Claude-Sessions gelten (Neu in 0.9.18 Sessions mit Claude API eingeschlossen) und bei einem anderen Provider nichts ändern. Neu in 0.9.17 Eine DeepSeek-Session bekommt diese Notiz auch, aber dort wirkt das Fenster sehr wohl, und 0 bedeutet 400.000 Tokens; thinking_enabled wirkt nicht, da eine DeepSeek-Session immer denkt.

Wer was ändern darf. Ein Agent ändert frei nur eine Session, die seine eigene Konversation gestartet hat: auf diesem Relay oder auf einem gekoppelten Relay, wenn jenes Relay diese Konversation als Starter vermerkt hat. Jede andere Session, deine, die eines anderen Agents oder die, die den Agent gestartet hat, braucht zuerst dein Allow. Eine Rückfrage-Karte fragt einmal pro Konversation und Relay, nennt die Session und listet die Änderung auf (Model: … · Effort: … · Group: …); Allow deckt die späteren Änderungen dieser Konversation an solchen Sessions dort ab. Deny lehnt den Aufruf mit REMOTE_RELAY_PERMISSION ab; eine Konversation ohne laufenden Turn, in dem gefragt werden kann, bekommt REMOTE_RELAY_NO_ACTIVE_TURN. Das andere Relay hält sich selbst an dieselbe Regel. Ein Agent ändert nie die Konversation, in der er läuft. In den Modi ask und plan gilt zusätzlich die übliche Karte für eine schreibende Aktion.

Bevor sich etwas ändert, prüft das Relay den ganzen Aufruf auf dem Ziel: das Modell und den Effort, die Gruppe, den Ordner und ob du gefragt werden musst. Ein unbekanntes Modell, eine unbekannte Gruppen-ID, ein Gruppenname, der auf zwei Gruppen passt, ein Ordner, den das Relay nicht verwenden darf, oder ein neuer Ordner für eine beschäftigte Session lehnt den Aufruf vor jeder Karte ab, und nichts wird geändert.

Gruppen.

• Ein Name, den das Relay nicht hat, legt eine neue Gruppe mit diesem Namen an. Eine Gruppen-ID muss existieren (REMOTE_RELAY_UNKNOWN_GROUP).
• Eine Gruppe, die du angelegt hast, wird auf diesem Weg nie entfernt. Wenn ein Agent ihre letzte Session herausnimmt, bleibt die Gruppe und erscheint in deiner Seitenleiste als group · empty (Gruppe · leer): Benenne sie über ihr Menü um oder löse sie auf, oder lass einen Agent sie wieder nennen. Nichts entfernt sie von selbst.
• Eine Gruppe, die ein Agent angelegt hat, über einen Namen oder durch das Starten von Sessions, verschwindet, sobald sie leer ist.

Der Ordner. Ein neues cwd startet die CLI der Session in diesem Ordner neu. Es wird mit REMOTE_RELAY_BUSY abgelehnt, solange dort ein Turn eingereiht ist oder läuft oder ein Hintergrund-Task läuft: The session cannot move to another folder now: …. Der Ordner muss einer sein, den das Relay verwenden darf. Eine Session, die noch nicht gestartet ist, behält den Ordner für ihren ersten Start. Startet die CLI nicht neu, wird der Ordner trotzdem für ihren nächsten Start gespeichert, und die Antwort sagt das. Nicht für Claude Cloud, das auf einem Klon seines Repositorys arbeitet.

Der Modus, der so gesetzt wird, gilt bis zum nächsten send, das einen anderen Modus nennt oder von einem Aufrufer in einem anderen Modus kommt: Ein send ohne mode gibt den eigenen Modus des Aufrufers weiter.

Schlägt ein Schritt fehl, nachdem andere geschrieben wurden, listet die Antwort in changed trotzdem auf, was geschrieben wurde. Eine offene Seite zeigt jede Änderung sofort. Ein Relay, das ein älteres OAR ausführt, antwortet mit REMOTE_RELAY_UNSUPPORTED.

Welche Modelle angenommen werden Neu in 0.9.13 #

Ein model in send oder create_session wird gegen die Liste geprüft, die New Chat (Neuer Chat) für den Provider auf dem Ziel-Relay anbietet, dieselbe Liste, die relay_info zeigt, und zwar vor jeder Freigabekarte. Ein Modell, das nicht darauf steht, wird mit REMOTE_RELAY_UNKNOWN_MODEL abgelehnt, und nichts wird erstellt oder gesendet:

Unknown model 'gpt-5-4' for Copilot on relay "build-box"; did you mean 'gpt-5.4'? Valid ids: … Nothing was sent.

Das Ergebnis trägt auch suggestions, die ähnlichen Treffer, und models, die gültigen IDs. Vor 0.9.13 erstellte eine solche ID eine Session mit einem anderen Modell, die spätere send-Aufrufe mit dieser ID nicht erreichen konnten.

Neu in 0.9.19 Copilot-Modell-IDs schreiben sich mit Punkten: claude-opus-5.5, nicht Claudes claude-opus-5-5. Copilot lehnt die ID eines anderen Providers ab, bevor etwas angelegt wird: mit COPILOT_MODEL_UNAVAILABLE und dem ähnlichsten Treffer oder, bei create_session, mit dem Code des einen anderen Providers, der die ID führt, etwa CLAUDE_PROVIDER_REQUIRED. Eine Copilot-Session wechselt nie wegen ihres Modellnamens zu einem anderen Provider.

Wo das Modell, das läuft, von dem gewünschten abweicht, sagt die modelNote des Ergebnisses das. Wenn das Ziel-Relay noch keine Liste für den Provider hat (seine Modellerkennung ist nicht gelaufen oder fehlgeschlagen), geht das Modell ungeprüft weiter, und modelNote sagt auch das. Ein Relay lehnt ein unbekanntes Copilot-Modell auch ab, wenn der Agent eines anderen Relays eine Session darauf startet.

wait #

Wartet weiter auf eine Antwort, die send oder create_session nicht rechtzeitig bekommen hat.

{ "action": "wait", "relay": "build-box", "session": "3f9c…", "message_id": "b41e…", "wait_seconds": 300 }

Warten und was zurückkommt #

send, create_session und wait warten so lange auf die Antwort, wie der Agent in wait_seconds verlangt, bis zu Longest wait per tool call (Längste Wartezeit pro Tool-Aufruf) auf dem Relay, auf dem der Agent läuft (Settings → Relays → Agent sessions): standardmäßig 10 Minuten, einstellbar von 2 bis 60 Minuten. Hat ein Aufruf mehr verlangt, als das Relay erlaubt, sagt das Ergebnis das in einer note. Wenn die Zeit abgelaufen ist, bekommt der Agent, was bis dahin da ist, und kann wait erneut aufrufen.

Ein Turn, der wartet, zählt trotzdem zur Max turn duration (Maximale Turn-Dauer) unter Settings → General (Einstellungen → Allgemein).

Der status des Ergebnisses sagt, wo die andere Session steht:

Jedes solche Ergebnis trägt session und message_id sowie openUrl, einen Link, der die Session öffnet, wenn das Relay einen hat.

Eine andere Session steuern #

answer_question #

Beantwortet eine Rückfrage-Karte, die in einer anderen Session wartet. Agents sollen dich zuerst fragen, es sei denn, du hast ihnen gesagt, sie sollen selbst entscheiden.

Eines von choices und answer ist Pflicht. Ein Agent kann seine eigene Frage nicht beantworten, und er kann keine Freigabekarte eines Relays beantworten: Die gehören dir. Neu in 0.9.16 Auch einen Ask kann er nicht beantworten: answer_question lehnt ihn mit REMOTE_RELAY_FORBIDDEN ab, bevor es irgendwen aufruft.

{ "action": "answer_question", "relay": "build-box", "question_id": "q_7d2…", "choices": ["Merge"] }

stop #

Stoppt den Turn, der in einer Session läuft, so wie Stop (Stoppen) es in der Oberfläche tut. Das Ergebnis sagt, ob ein Stopp angefordert wurde oder nichts lief.

{ "action": "stop", "relay": "this", "session": "3f9c…" }

archive #

Archiviert eine Session.

{ "action": "archive", "relay": "this", "session": "3f9c…" }

Sessions beobachten #

Neu in 0.9.10 Statt immer wieder nachzufragen, kann ein Agent Sessions abonnieren und sich wecken lassen, wenn dort etwas passiert. Das funktioniert auf diesem Relay (mit eingeschalteten Agent-Sessions) und auf einem gekoppelten Relay.

Ein Abonnement benachrichtigt nur. Es genehmigt nichts und beantwortet nichts; was ein Ereignis verlangt, wird wie bisher entschieden, von dir oder vom Agent im Rahmen dessen, was er ohnehin darf.

subscribe #

Eine Konversation kann 20 Abonnements gleichzeitig haben. Die eigene Konversation des Agents wird nie beobachtet.

{ "action": "subscribe", "sessions": ["3f9c…", "a12b…"], "events": ["question_asked", "error", "all_idle"] }

{
  "ok": true,
  "summary": "subscribe → desk: 2 sessions (sub_ab12cd34ef)",
  "subscription": {
    "id": "sub_ab12cd34ef",
    "sessions": [ { "id": "3f9c…", "title": "Review: server/" }, { "id": "a12b…", "title": "Review: web/" } ],
    "events": ["question_asked", "error", "all_idle"],
    "once": false,
    "stalledMinutes": 15
  }
}

Seltener geweckt werden Neu in 0.9.16 #

Jedes Wecken ist ein voller Turn des beobachtenden Agents. Drei Optionen von subscribe sorgen für weniger davon. question_asked, question_answered und error hält keine von ihnen je zurück; jedes andere Ereignis, auch task_failed, stalled und all_idle, schon.

{
  "action": "subscribe",
  "sessions": ["all"],
  "exclude": ["77aa…"],
  "digest_minutes": 30,
  "quiet_hours": { "from": "23:00", "to": "06:00", "tz": "Europe/Berlin" }
}

• digest_minutes. Die Ereignisse des Abonnements werden gesammelt und kommen als eine Nachricht alle N Minuten: frühestens N Minuten, nachdem das Abonnement angelegt wurde, jede weitere N Minuten nach der letzten. Die Nachricht sagt Digest of 4 events (subscription sub_… every 30 min; questions and errors come at once):. Eine Zusammenfassung mit einem einzigen Ereignis liest sich wie dieses Ereignis.
• quiet_hours. Ein tägliches Zeitfenster in Ortszeit einer IANA-Zeitzone. from und to sind Uhrzeiten (HH:MM, 00:00 bis 23:59) und müssen sich unterscheiden; das Fenster darf über Mitternacht reichen. Was darin passiert, wartet und kommt als eine Nachricht, wenn das Fenster endet, mit der Zeile Held during quiet hours (23:00–06:00 Europe/Berlin): 3 events, delivered now that the window has ended; questions and errors came at once. Innerhalb des Fensters gibt es keinen Heartbeat. Ein Ereignis, das eine Zusammenfassung innerhalb des Fensters zustellen würde, rückt an sein Ende.
• exclude. Ein Abonnement auf all Sessions ignoriert diese Sessions, auch für all_idle, stalled und den Heartbeat. Mit einer Liste von Sessions wird es abgelehnt: exclude goes with sessions ["all"] only; a list of sessions names what it watches.

Zeitumstellungen. Das Fenster folgt der Uhr der Zeitzone. In der Nacht, in der die Uhren zurückgestellt werden und to zweimal vorkommt, endet das Fenster beim ersten Mal und wird in der wiederholten Stunde nicht erneut betreten. In der Nacht, in der sie vorgestellt werden und to überspringen, endet es im Moment des Sprungs. Eine bekannte Grenze: Ein from innerhalb der wiederholten Stunde startet das Fenster beim ersten Durchlauf, und beim zweiten Durchlauf zählen die Minuten vor from als außerhalb.

Ein falscher Wert wird mit der Angabe abgelehnt, was falsch ist, zum Beispiel quiet_hours from and to must be times of day as "HH:MM" (00:00 to 23:59), quiet_hours from and to must differ oder quiet_hours tz "Berlin" is not an IANA time zone (for example "Europe/Berlin", "America/New_York", "UTC"). Ein quiet_hours, bei dem jedes Feld leer ist, zählt als keines.

• Mit once. Das Ereignis, das ein einmaliges Abonnement beendet, hält sich trotzdem an dessen Zusammenfassung und Ruhezeiten: Das Abonnement endet sofort, das Ereignis kommt, wenn sie es zulassen.
• Mehrere Abonnements. Ein Ereignis, das mehrere Abonnements des beobachtenden Agents aufgenommen haben, geht, sobald das erste von ihnen es freigibt; ein Abonnement ohne Optionen gibt es sofort frei.
• Das Stundenlimit von 20 Weckvorgängen gilt zusätzlich zu den Optionen (Wie Ereignisse ankommen).
• Zurückgehaltene Ereignisse und ihre Fälligkeit überstehen einen Neustart des Relays.
• Die Freigabekarte nennt die Optionen (digest every 30 min, quiet 23:00–06:00 Europe/Berlin, except 1 it leaves out).

Kein Echo der eigenen Prompts des beobachtenden Agents. Wenn der beobachtende Agent eine Session selbst mit send oder create_session promptet und die fertige Antwort aus diesem Aufruf oder einem späteren wait zurückbekommt, weckt ihn das turn_end dieses Turns kein zweites Mal; solange er noch wartet, wird das turn_end zurückgehalten. Die Fehler und Fragen des Turns kommen weiterhin. Ein Prompt, auf den er nicht gewartet hat (wait_seconds: 0 und kein wait), weckt ihn wie bisher mit turn_end, und ebenso ein turn_end, das ein once-Abonnement beendet.

Ereignisse #

Die Standard-Ereignisse Neu in 0.9.13 #

Ein Abonnement, das keine events nennt, bekommt question_asked, error, turn_end, subagent_finished, task_failed, stalled und all_idle. Ein Subagent im Hintergrund, der fertig ist, weckt den beobachtenden Agent, ebenso jeder Task, der fehlgeschlagen ist oder mit einem anderen Code als null geendet hat, aber ein Shell-Befehl oder Monitor, der gut ausgegangen ist, nicht. Eine geschäftige Session beendet etwa jede Minute einen, und jeder würde den beobachtenden Agent einen Turn auf seinem ganzen Kontext kosten. Um jedes Task-Ende zu bekommen, nenne die Ereignisse mit task_finished anstelle von subagent_finished und task_started für die Starts.

Abonnements, die vor 0.9.13 ohne events angelegt wurden, wechseln von selbst auf diesen Standard; die, die ihre Ereignisse genannt haben, behalten sie. Ein gekoppeltes Relay mit einem älteren OAR wendet seinen eigenen Standard an und lehnt subagent_finished beim Namen ab.

Wie Ereignisse ankommen #

OAR schreibt eine kurze Nachricht in die beobachtende Konversation. Sie erscheint als kompakte Ereigniszeile, nie als eine deiner Nachrichten, und beginnt mit einer Zeile, die sagt, was sie ist:

[relay event · automated message from OAR, not from the user; it approves nothing]
[relay event] session "Review: server/" (3f9c…): turn_end (done) "Found 4 places without input checks: …"
[relay event] all_idle: no turn or task is running in the 2 watched sessions (subscription sub_ab12cd34ef)

• Ist der beobachtende Agent untätig, startet die Nachricht einen neuen Turn. Ist er mitten in einem Turn, siehe die Tabelle unten.
• Ereignisse innerhalb von 30 Sekunden kommen als eine Nachricht.
• Nach 20 Weckvorgängen in einer Stunde kommt der Rest als Zusammenfassung alle 10 Minuten. question_asked und error kommen weiterhin sofort (Neu in 0.9.16 und question_answered). Treffen diese Zusammenfassung und das digest_minutes eines Abonnements zusammen, nennt eine Digest of-Zeile beide.
• Neu in 0.9.16 Das digest_minutes und die quiet_hours eines Abonnements halten seine anderen Ereignisse länger zurück.

Auf einem gekoppelten Relay #

Das Relay muss in der Konversation entsperrt sein und mindestens Lesen erlauben, und das andere Relay muss Agents anderer Relays annehmen. Eine Kopplung in eine Richtung genügt. Dieses Relay holt die Ereignisse alle paar Sekunden ab, und ihre Zeilen beginnen mit dem Namen des anderen Relays:

[relay event] build-box · session "Nightly deploy" (77aa…): turn_end (done) "Deployed. The health check is green."

Bricht die Verbindung ab, behält das andere Relay, was passiert, bis zu 500 Ereignisse pro Abonnement für 7 Tage, und stellt es als eine Zeile mit der Markierung replayed (erneut zugestellt) zu, sobald es wieder antwortet, zwischen einer Zeile link_lost und einer Zeile link_restored. Ein Relay, das ein älteres OAR ausführt, antwortet, dass es ein Update braucht.

Neu in 0.9.16 Die Zusammenfassung und die Ruhezeiten eines Abonnements auf ein gekoppeltes Relay werden hier angewandt, wo der beobachtende Agent ist; exclude wird auch an das andere Relay weitergegeben, für all_idle, stalled und den Heartbeat. Erneut zugestellte Ereignisse halten sich an die Zusammenfassung und die Ruhezeiten wie jedes andere; die Zeile link_restored sagt dann, wie viele von ihnen zurückgehalten werden und später kommen. Ein gekoppeltes Relay mit einem älteren OAR kennt exclude nicht: Dieses Relay verwirft die Ereignisse dieser Sessions trotzdem, aber jenes Relay zählt sie für all_idle, für Stillstände und in der Liste des Heartbeats mit.

unsubscribe #

Beendet ein Abonnement, oder mit "all" jedes Abonnement, das die Konversation auf dem genannten Relay hat.

{ "action": "unsubscribe", "subscription_id": "sub_ab12cd34ef" }

list_subscriptions #

Zeigt die Abonnements der Konversation: die aktiven und die, die in der letzten Stunde geendet haben, mit dem Grund. Mit watcher zeigt es die Abonnements einer anderen Konversation; so sieht ein Agent nach, bevor er sie übernimmt.

{ "action": "list_subscriptions" }

Jedes Abonnement zeigt seine Sessions, Ereignisse, once, match, stalledMinutes und heartbeatMinutes, Neu in 0.9.16 sowie digestMinutes, quietHours und exclude, wenn es sie hat. Ein aktives Abonnement sagt auch, wie viele seiner Ereignisse seine Zusammenfassung oder seine Ruhezeiten gerade zurückhalten (heldCount), und wann das erste davon fällig ist (nextDeliveryAt, null, wenn keines zurückgehalten wird). Ein beendetes sagt das nur, solange sein letztes Ereignis noch zurückgehalten wird, wie nach einem once, das innerhalb der Ruhezeiten ausgelöst hat.

{
  "id": "sub_ab12cd34ef",
  "scope": "all",
  "sessions": "all",
  "digestMinutes": 30,
  "quietHours": { "from": "23:00", "to": "06:00", "tz": "Europe/Berlin" },
  "exclude": ["77aa…"],
  "heldCount": 3,
  "nextDeliveryAt": "2026-10-24T04:00:00.000Z"
}

transfer_subscriptions #

Verschiebt jedes Abonnement einer anderen Konversation in diese, zum Beispiel wenn eine neue Session einen alten beobachtenden Agent ersetzt. Fragt dich immer auf einer Freigabekarte.

{ "action": "transfer_subscriptions", "from": "c0de…" }

Wie lange ein Abonnement lebt #

Abonnements überstehen einen Neustart des Relays. Eines endet, wenn:

• der Agent unsubscribe aufruft oder du in der Liste des beobachtenden Agents Unsubscribe drückst;
• der beobachtende Agent oder die beobachtete Session archiviert wird;
• es ausgelöst hat und mit once angelegt wurde;
• bei einem gekoppelten Relay die Kopplung entfernt wird.

Zeitpläne Neu in 0.9.16 #

Ein Agent kann dieses Relay einen Prompt später einreihen lassen, in seine eigene Konversation oder eine andere Session hier. Anders als ein Timer der eigenen CLI des Agents übersteht ein Zeitplan Neustarts und Updates des Relays. Geplante Prompts erklärt es aus deiner Sicht.

Zeitpläne brauchen Agents may start and use sessions on this relay, auch für die eigene Konversation des Agents. Sie werden von dem Relay verwaltet, auf dem der Agent läuft: Ein Aufruf, der ein gekoppeltes Relay nennt, wird mit REMOTE_RELAY_UNSUPPORTED abgelehnt.

schedule #

Mindestens at oder every_minutes ist nötig.

{ "action": "schedule", "title": "Nightly review", "at": "2026-11-02T02:00:00Z", "every_minutes": 1440, "text": "Review yesterday's merged changes under server/ and list anything risky." }

{
  "ok": true,
  "summary": "schedule → desk: every 1440 min, next 2026-11-02T02:00:00.000Z (sch_3f9c2a1e7b04)",
  "schedule_id": "sch_3f9c2a1e7b04",
  "schedule": { "id": "sch_3f9c2a1e7b04", "title": "Nightly review", "everyMinutes": 1440, "once": false, "nextFireAt": "2026-11-02T02:00:00.000Z" }
}

Wenn er fällig ist, reiht das Relay den Text als Nachricht ein, die mit [relay schedule <id> "<title>" · … automated message from OAR, not from the user; it approves nothing] beginnt. Der Turn läuft im eigenen Relay-Modus der Ziel-Session. Eine Nachricht, die ankommt, während ein Turn läuft, wird eingereiht oder bei Providern, die nachsteuern, hineingesteuert, aber nie mit dem Nachsteuer-Hinweis, der als Benutzer spricht.

• Verpasste Zeiten. Eine Zeit, die verstrichen ist, während das Relay aus war, löst einmal aus, wenn es wieder da ist, nicht einmal pro verpasstem Intervall; ein wiederholter Zeitplan hält sich dann an sein Raster (das erste Mal plus ganze Intervalle).
• Kein Aufstauen. Eine Wiederholung wird übersprungen, solange die Nachricht des vorigen Auslösens noch in der Queue wartet (skippedCount in der Liste).
• Hops. Die Nachricht trägt die Herkunft des Turns, der den Zeitplan gesetzt hat, seine Hops eingeschlossen, sodass ein Zeitplan keinen Prompt mit weniger Hops weitergibt, als ein direkter Prompt aus diesem Turn hätte (Über Relays hinweg).

Eine andere Session. Mit session promptet der Zeitplan diese Session. Er wird wie ein send behandelt: In den Modi ask und plan genehmigst du ihn auf einer Karte, und er zählt zu den 30 Prompts an andere Agents, bevor du gefragt wirst, einmal beim Setzen und einmal bei jedem Auslösen. Ist diese Zählung aufgebraucht, wird ein Auslösen zurückgehalten: list_schedules zeigt heldForApproval und heldSince. Es geht los, sobald du in der Konversation schreibst, die ihn gesetzt hat, oder Allow auf der Karte wählst, die ihr Agent für seinen nächsten Prompt an einen anderen Agent zeigt; das Relay sieht jede Minute erneut nach. Ein Zeitplan für die eigene Konversation des Agents wird weder gezählt noch zurückgehalten.

list_schedules #

Listet die Zeitpläne auf, die in die Konversation auslösen oder die sie gesetzt hat: die aktiven und die, die in der letzten Stunde geendet haben, mit endReason (unscheduled, fired, archived oder deleted).

Jeder Zeitplan hat id, session (ID und Titel), setBy, wenn eine andere Konversation ihn gesetzt hat, title, den Anfang seines text, at, everyMinutes, once, nextFireAt, lastFiredAt, firedCount, skippedCount, wenn er welche übersprungen hat, und heldForApproval mit heldSince, solange er zurückgehalten wird.

unschedule #

Beendet einen Zeitplan der Konversation: einen, der in sie auslöst oder den sie gesetzt hat.

Wann ein Zeitplan endet #

Ein Zeitplan endet nach dem Auslösen, wenn once gilt, bei unschedule oder Cancel (Abbrechen) in der Liste ⏰ im Header, und wenn die Session, in die er auslöst, oder die Konversation, die ihn gesetzt hat, archiviert oder gelöscht wird. Eine Kompaktierung verschiebt stattdessen beide Arten in die neue Konversation. Eine Konversation hat höchstens 20 aktive Zeitpläne, die in sie auslösen, und darf höchstens 20 für andere Sessions setzen; darüber hinaus REMOTE_RELAY_SCHEDULE_LIMIT.

Fragen, die nicht blockieren Neu in 0.9.16 #

Ein Agent kann dir eine Frage stellen und weiterarbeiten: Die Frage erscheint als Karte in seiner Session und in deiner Inbox, und der Agent erfährt die Antwort später. Fragen und die Inbox erklärt es aus deiner Sicht.

ask #

{ "action": "ask", "question": "Ship the migration tonight or wait for the review?", "options": ["Tonight", "Wait"], "recommendation": "Wait", "detail": "The review covers the index change; the rest is tested." }

{ "ok": true, "question_id": "ask_7d2…", "status": "pending", "summary": "ask → desk: question ask_7d2… pending" }

ask kehrt sofort mit question_id und status: "pending" zurück. Der Agent soll mit dem weitermachen, was nicht von der Antwort abhängt, und nicht dasselbe noch einmal fragen, solange die Frage offen ist.

Die Antwort. Wenn du die Frage beantwortest oder verwirfst, bekommt der Agent das Relay-Ereignis question_answered, mit question_id, deiner answer, der choice, die du gewählt hast, dismissed, wenn du sie verworfen hast, und via, dem Relay, auf dem du geantwortet hast: dem, auf dem der Ask verwaltet wird, oder einem gekoppelten Relay, dessen Inbox du benutzt hast. Dafür ist kein Abonnement nötig. Das Ereignis ist dringend: Keine Zusammenfassung und keine Ruhezeiten halten es zurück. Es ist automatisch und genehmigt sonst nichts, und es zählt nicht als Nachricht von dir für den Schleifenschutz: Einen Ask zu beantworten setzt die Zählung der Prompts, die Agents einander senden dürfen, nicht zurück.

Wer antwortet. Nur du, in der Session oder in einer Inbox (der dieses Relays oder der eines Relays, das mit ihm gekoppelt ist). answer_question lehnt einen Ask ab.

Freigaben.

• Ein Ask zur eigenen Konversation des Agents, list_questions und withdraw brauchen keine Einstellung und keine Erwähnung.
• Mit session fragt der Agent im Auftrag einer anderen Session: auf diesem Relay mit Agents may start and use sessions on this relay, auf einem gekoppelten Relay mit Agents may mindestens auf Read and prompt und entsperrtem Relay. Ein solcher Ask ist eine schreibende Aktion: In den Modi ask und plan genehmigst du ihn auf einer Karte, und er hält sich an die Hop-Grenze (Über Relays hinweg). Der Schleifenschutz zählt ihn nicht. Die Karte erscheint in dieser Session, und sowohl sie als auch die fragende Konversation bekommen die Antwort.
• Ein Ask zu einer Session auf einem gekoppelten Relay wird auf jenem Relay verwaltet; dieses Relay sieht alle 5 Sekunden nach seiner Antwort, solange er offen ist (alle 30 Sekunden, solange jenes Relay nicht antwortet). Ein Relay, das ein älteres OAR ausführt, antwortet mit REMOTE_RELAY_UNSUPPORTED.

Höchstens 20 Asks dürfen pro fragender Konversation offen sein, und 20 pro Session, die sie betreffen; darüber hinaus REMOTE_RELAY_QUESTION_LIMIT. Asks verfallen nicht.

list_questions #

Listet die Asks der Konversation auf: die offenen und die, die am letzten Tag beantwortet, verworfen oder zurückgezogen wurden, mit ihrem Status und ihrer Antwort. Mit session die Asks zu einer anderen Session. Auf einem gekoppelten Relay listet es die Asks auf, die diese Konversation dort gestellt hat; read_session dort listet jede offene Frage einer Session auf.

withdraw #

Zieht einen Ask zurück, der noch offen ist. Nur die Konversation, die gefragt hat, darf ihn zurückziehen.

Ein Ask endet auch, wenn seine Session archiviert oder gelöscht wird (niemand wird benachrichtigt), und wenn die Kopplung mit dem Relay, auf dem er verwaltet wird, entfernt wird. Eine Kompaktierung verschiebt seine Asks in die neue Konversation.

Grenzen #

Fehler #

Ein abgelehnter Aufruf kommt mit einem code zurück, auf den der Agent reagieren kann.