Reinicios y reanudación

Cada conversación tiene su propio agente, que se ejecuta en un proceso en segundo plano en la máquina del relay. La conversación en sí, con su historial, su queue y su borrador, vive en el relay. Esta página explica cómo encajan ambas cosas, para que sepas qué te cuesta un Kill session (Matar la sesión), un reinicio del relay o un reinicio de la máquina, y qué vuelve por sí solo.

La versión corta: no se pierde nada de lo que escribiste. El siguiente mensaje a una conversación vuelve a iniciar su agente si no está en ejecución, y el agente continúa la sesión propia del proveedor, no una en blanco.

El proceso del agente de una conversación #

OAR llama a este proceso el worker de sesión. No lo inicias tú. El relay lo inicia cuando una conversación lo necesita, normalmente con tu primer mensaje, y el worker se conecta de vuelta al relay para recibir mensajes e informar de la respuesta. En Linux y macOS con tmux instalado, los workers se ejecutan en sesiones de tmux desacopladas, y Inspect tmux console (Inspeccionar la consola de tmux) en el menú ⋯ muestra una. Sin tmux se ejecutan como procesos en segundo plano normales.

Nuevo en 0.9.11 Los workers se ejecutan con el Node.js propio del relay, por su ruta completa, en todas las plataformas, así que arrancan aunque el PATH del relay no tenga node, como en un relay iniciado por la tarea de inicio de Windows antes de que nadie haya iniciado sesión. COPILOT_WEB_RELAY_NODE fija otro (Variables de entorno). Cuando el PATH de un worker no tiene node, esa carpeta de Node.js se añade al final, para que las CLI y los comandos que inicia un worker también encuentren uno.

Si el worker no se puede iniciar, la conversación muestra una nota:

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.

El relay lo reintenta cada minuto durante 10 minutos. Después, la nota dice que dejó de intentarlo y muestra un botón Retry (Reintentar). Tu mensaje sigue en cola todo el tiempo, y se entrega en cuanto arranca un worker. En Windows, un arranque que falla o que nunca vuelve falla al instante y nombra el programa, y el log del relay nombra el comando y el PATH con el que se inició.

Detenerse solo #

Una conversación de Claude o DeepSeek, y una conversación de GitHub Copilot u OpenAI con el motor SDK, liberan su memoria cuando no pasa nada. Tras 10 minutos sin actividad, el programa propio del agente termina, y el siguiente mensaje lo vuelve a iniciar y continúa la misma sesión del proveedor. El proceso worker se queda y mantiene su conexión con el relay. La app no tiene ningún ajuste para esos 10 minutos.

El agente no se detiene mientras ocurre alguna de estas cosas:

• hay un turn en curso o en cola para él,
• una tarjeta de pregunta o de permiso espera tu respuesta,
• se está ejecutando una tarea en segundo plano, o aún está pendiente la continuación de una que acaba de terminar.

Las tareas en segundo plano por sí solas pueden mantenerlo abierto solo hasta el Background task timeout (Tiempo límite de las tareas en segundo plano) de Settings → General (Ajustes → General) (4 horas de forma predeterminada; 0 significa sin límite).

Nuevo en 0.9.17 Una conversación de DeepSeek también reinicia el programa de su agente cuando cambias su modelo o su reasoning effort, porque Claude Code solo los lee al arrancar. El reinicio ocurre antes del siguiente turn, cuando no se está ejecutando nada en el programa, y continúa la misma sesión. Mientras aún se ejecute trabajo en segundo plano en él, el turn se ejecuta en el programa tal como está: un modelo nuevo se cambia allí, un reasoning effort nuevo espera al reinicio.

Los demás proveedores no tienen esta parada por inactividad. Un worker de Claude Cloud, Cursor o Grok sigue en ejecución hasta que matas la sesión, archivas la conversación o la máquina se detiene. El motor de extensión de Copilot también mantiene en ejecución su Copilot CLI. Un worker de Cursor que lleva 30 minutos sin usarse cierra su handle de agente y vuelve a abrir el mismo agente de Cursor con el siguiente mensaje.

Kill session #

Kill session en el menú ⋯ de la conversación, o en el menú de su fila en la lista, detiene el worker y los procesos que inició. Úsalo cuando una conversación está atascada, cuando el agente no reacciona a Stop (Detener), o cuando quieres que el agente empiece de cero para que recoja herramientas o ajustes nuevos, por ejemplo después de activar las sesiones de agente.

Primero se abre una confirmación:

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

Después, un breve aviso dice Session killed. (Sesión matada.) Si no se encontró ningún proceso vivo, dice en su lugar Session state cleared; no live worker process was found. (Estado de la sesión borrado; no se encontró ningún proceso worker vivo.) Si un proceso sobrevive al intento, una alerta dice Failed to kill session (No se pudo matar la sesión) y no se borra nada.

Un turn que estaba en curso termina con una nota en la conversación: This session was killed from the relay UI before the turn completed. (Esta sesión se mató desde la interfaz del relay antes de que terminara el turn.) Vuelve a enviar el mensaje o escribe uno nuevo. La conversación, su historial y sus mensajes en cola se conservan. El siguiente mensaje inicia un worker nuevo, y se reanuda la sesión del proveedor.

Archivar una conversación también detiene su worker. Consulta La lista de conversaciones.

Cuando el agente no es accesible #

Cuando ningún worker ha dado señales durante 10 segundos, aparece un banner encima de la conversación y la línea de estado de la barra lateral dice CLI offline (CLI sin conexión):

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

El banner pertenece al relay, no a una conversación, y puede ser normal en un relay que ha estado inactivo. Los mensajes que envías se conservan. Envía uno: el relay inicia el worker de la conversación y el banner desaparece en cuanto se conecta. Si se queda, mira worker-<session>.log en la carpeta de logs del relay; consulta Archivos y carpetas para saber dónde está.

Un worker que perdió su conexión, por ejemplo durante un reinicio del relay, sigue intentando volver a conectarse, esperando hasta 8 segundos entre intentos. Nuevo en 0.9.13 También abandona una conexión que no se ha completado en 15 segundos, y no espera a que un relay que se está apagando cierre la conexión, así que un reinicio que se cuelga ya no lo deja sin un siguiente intento. Cada intento fallido escribe una línea worker ws disconnected con el motivo en su worker-<session>.log: los tres primeros y, después, como mucho uno por minuto. Nuevo en 0.9.11 Como red de seguridad, el relay sustituye a un worker que lleva 60 segundos sin conexión mientras un mensaje lo espera: detiene el proceso antiguo e inicia uno nuevo, que recoge el mensaje. Nunca lo hace mientras se ejecuta un turn o trabajo en segundo plano de esa sesión, y cuando lo hace anota una línea WORKER DETACHED en el log.

Reiniciar el relay #

Reinicia el relay para cargar una versión nueva, un archivo de configuración cambiado o una CLI de proveedor recién instalada. Elige 🌄 Restart web relay (Reiniciar el relay web) en el menú ⋯ de la conversación, o ejecuta oar restart en la máquina del relay. oar update y el botón Update (Actualizar) de Settings → General lo reinician por ti después de una instalación.

Lo que esperaría el reinicio Nuevo en 0.9.13 #

🌄 Restart web relay muestra primero lo que esperaría un reinicio y lo que dejaría en ejecución:

• las sesiones con un turn en curso, cada una con su título;
• cuántos mensajes retendría hasta entonces;
• las sesiones con tareas en segundo plano (comandos, monitores, subagents), cada una marcada como que sigue en ejecución o como may stop (puede detenerse). Una tarea que el relay conservó de un reinicio anterior, y cuyo worker aún no la ha confirmado, aparece como aún no confirmada.

Cuando hay un turn en curso, la ventana ofrece 🌄 Restart when idle (Reiniciar cuando esté inactivo), que pone el reinicio en cola, y Restart now (Reiniciar ahora), que no espera. Cuando no hay nada en curso, el botón es 🌄 Restart web relay y el relay se reinicia al instante.

El reinicio espera a los turns en curso #

El reinicio no interrumpe un turn. Restart when idle lo pone en cola, y todas las páginas de todos los dispositivos conectados muestran un 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.

Los nombres de las sesiones son enlaces que abren la conversación. Le sigue una línea Background tasks: (Tareas en segundo plano:) cuando hay sesiones con trabajo en segundo plano, que indica si cada una sigue en ejecución. El banner tiene dos botones:

• Restart now pregunta primero, nombra las sesiones que no espera y después reinicia. Sus workers siguen en ejecución e informan al relay reiniciado; la salida en vivo de sus turns se pausa mientras el relay no está, y un turn cuya respuesta no llega hay que volver a enviarlo. Con el servicio de Linux, los workers pueden detenerse con el relay, y la ventana lo dice.
• Cancel restart (Cancelar el reinicio) retira el reinicio. Los mensajes retenidos salen al instante.

Solo los turns en curso retienen el reinicio. Mientras está en cola, los mensajes que envías esperan en la queue y no se entregan a ningún agente, así que un relay ocupado no puede aplazar el reinicio una y otra vez. Se ejecutan después del reinicio. Un turn cuyo agente se ha quedado callado se abandona tras la ventana de inactividad del relay, 10 minutos de forma predeterminada (processingTimeoutMs), y a partir de entonces ya no lo retiene.

Cuando la espera es larga Nuevo en 0.9.13 #

Un reinicio en cola espera como máximo lo que indica Ask after a queued relay restart has waited (Preguntar cuando un reinicio del relay en cola lleve esperando) en Settings → General: 30 minutos de forma predeterminada; 5, 10, 15 o 30 minutos, 1, 2 o 4 horas, o No limit (Sin límite). Después, el banner se convierte en una pregunta:

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

Ofrece Restart now, Keep waiting (30 min) (Seguir esperando, 30 min) y Cancel restart. Keep waiting espera otro periodo completo, contado desde ese momento, y vuelve a preguntar. Los dispositivos con las notificaciones activadas también reciben una, titulada Relay restart waiting (Reinicio del relay en espera).

El relay nunca se reinicia por sí solo mientras hay turns en curso, haya pregunta o no, y sigue reiniciándose en cuanto termina el último. Con No limit, un reinicio en cola, y los mensajes que retiene, esperan hasta que terminan los turns en curso o hasta que tú decidas. Un ajuste cambiado se aplica a un reinicio que ya está en cola.

Cuando no hay nada en curso, el banner dice Relay restarting now… (Reiniciando el relay…) y el relay vuelve en unos instantes. Un dispositivo abierto puede mostrar una breve caída de la conexión y, hasta que el primer worker dé señales, el banner CLI is offline (la CLI está sin conexión).

oar restart se comporta igual cuando el relay se inició con oar start o en un terminal: pone el reinicio en cola, así que el banner y la pregunta tras la espera máxima también se le aplican. Espera hasta un minuto y después dice que el relay sigue ocupado y que se reiniciará solo cuando terminen sus turns. oar stop espera hasta 30 segundos de la misma manera. Cuando el relay se ejecuta como servicio de systemd (oar service install), oar restart y oar stop pasan por systemd y actúan al instante, sin esperar a los turns. Un turn que está en curso termina entonces, y se trata como se describe más abajo.

Nuevo en 0.9.11 Cualquier navegador con la sesión iniciada puede poner en cola o cancelar el reinicio; solo necesita el token de acceso. Si el relay se niega, la página muestra su motivo. Desde un terminal en el host, oar restart siempre funciona.

Nuevo en 0.9.13 Un agente al que pides que reinicie el relay pone el reinicio en cola de la misma manera, y se le dice qué espera el reinicio, qué mensajes retiene y qué tareas en segundo plano siguen en ejecución, para que pueda contártelo. A los agentes se les indica que nunca se salten la espera: reiniciar sin ella es Restart now, y esa decisión es tuya.

Lo que un reinicio conserva y lo que pierde #

Se conserva:

• Las conversaciones y su historial
• Los mensajes en cola, incluidos los que esperaban al reinicio
• Los borradores del área de redacción y los adjuntos
• Nuevo en 0.9.11 Las vistas previas, que se vuelven a comprobar al arrancar
• Nuevo en 0.9.11 Las tareas en segundo plano de los workers que siguen en ejecución
• Nuevo en 0.9.13 Las consolas de tareas: las filas terminadas durante el resto de su hora, y la salida de los comandos en ejecución
• Las suscripciones que los agentes configuraron para vigilar otras sesiones
• La aprobación que obtuvo un agente para iniciar sesiones
• Una pausa por límite de uso
• Las sesiones del proveedor de las conversaciones

Se pierde:

• Un Suspend host (Suspender el host) en cola (Windows), que el relay descarta y lo indica
• Las tareas en segundo plano de los workers que el reinicio detuvo (con el servicio de Linux, consulta más abajo)

Cuando el relay se inició con oar start o en un terminal, no detiene los workers al terminar. Estos notan que la conexión ha desaparecido y se vuelven a conectar al relay nuevo. El servicio de oar service install es distinto: systemd detiene todo lo que inició el servicio, workers incluidos, porque el servicio no pide otra cosa. El siguiente mensaje a cada conversación inicia entonces un worker nuevo, y la conversación continúa como se describe a continuación.

Un turn que estaba en curso cuando todo se cayó #

Un reinicio planificado espera a los turns, así que esto se refiere a Restart now, un fallo, un kill, un corte de corriente o un reinicio de la máquina.

El relay marca un turn como en curso hasta que su worker informa. Si el worker deja de informar, el relay espera su ventana de inactividad (10 minutos de forma predeterminada, processingTimeoutMs; 45 segundos como máximo cuando no hay ningún worker conectado) y después devuelve el mensaje a la queue. El mensaje se entrega de nuevo a un worker nuevo, que reanuda la sesión del proveedor, así que el agente tiene su conversación anterior. Los archivos que el agente ya cambió siguen cambiados.

• Un mensaje se devuelve a la queue como máximo maxRequeueRetries veces (5 de forma predeterminada). Después falla con Relay recovery limit reached … Send it again to retry. (Se alcanzó el límite de recuperación del relay … Vuelve a enviarlo para reintentarlo.)
• Un turn que el propio agente inició después de una tarea en segundo plano, una continuación, no se devuelve a la queue. Se descarta, porque ejecutarlo de nuevo le entregaría al agente su propia notificación como si fuera tu prompt.
• Copilot con el motor SDK conserva una respuesta terminada que el relay no pudo recoger mientras se reiniciaba, y la vuelve a ofrecer durante hasta cinco minutos, así que la respuesta no se pierde y el prompt no se ejecuta dos veces.

Un worker que siguió en ejecución durante el reinicio conserva su turn: informa al relay nuevo y el turn continúa.

Pedir a una sesión interrumpida que continúe Nuevo en 0.9.13 #

Unos pocos turns no pueden volver a ejecutarse, porque el agente ya había recogido el mensaje: un mensaje que enviaste mientras trabajaba, una continuación, o un turn que ya había empezado cuando su worker volvió sin él. Un turn así simplemente se detiene, y el agente nunca se entera de que lo cortaron.

Activa After a relay restart, tell interrupted sessions to carry on (Tras reiniciar el relay, pedir a las sesiones interrumpidas que continúen) en Settings → General (desactivado de forma predeterminada; es un ajuste del relay) y una sesión así recibe una nota del relay cuando este vuelve. Aparece como una fila compacta relay en la conversación, y el agente lee:

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.

• Tu mensaje nunca se vuelve a enviar, y una sesión recibe como máximo una nota por reinicio.
• No se envía nada a las sesiones inactivas, para los turns que vuelven a ejecutarse solos, a las conversaciones archivadas, ni mientras una pausa por límite de uso retiene la sesión (su propio mensaje de seguimiento continúa el turn).
• Un mensaje que pusiste en cola mientras tanto va primero; la nota espera detrás.
• La nota inicia el agente de la sesión como cualquier mensaje. Cuentan los turns cortados en los 30 minutos posteriores al arranque del relay.

Sin el ajuste, envía tú mismo un mensaje breve como «continúa».

Por proveedor #

El relay conserva la conversación y la queue para todos los proveedores. Lo que conserva el proveedor, y por tanto desde dónde continúa una conversación reanudada, varía. Las conversaciones de OpenAI Image no tienen worker: el relay llama él mismo a la API Images, así que nada de esta página se les aplica.