Los turns y la queue
Un turn es una ronda de trabajo: envías un prompt, el agente trabaja en él y responde. Una conversación es una serie de turns, uno tras otro. Cuando envías un mensaje mientras un turn aún está en curso, OAR lo retiene en una queue hasta que el turn termina. Cuando un turn deja de avanzar, OAR lo nota, lo devuelve a la queue o lo termina con una nota, y no lo deja dando vueltas.
Corregir el rumbo de un turn en curso y el botón Stop (Detener) se explican en Mientras corre un turn. Los reinicios, en Reinicios y reanudación.
Los estados de un turn #
| Estado | Lo que ves |
|---|---|
| En cola | Tu mensaje está en la transcripción con un botón Cancel (Cancelar) debajo. |
| En curso | La burbuja de respuesta se llena mientras el agente trabaja, con su actividad de herramientas y un botón Stop. La conversación aparece como ocupada en la lista. |
| Esperando una pregunta | Una tarjeta de pregunta dice Waiting for your answer (Esperando tu respuesta). El turn continúa cuando respondes. |
| Terminado | La respuesta está completa. |
| Fallido | La respuesta es una breve nota del sistema que dice qué pasó. Consulta Cuando un turn falla. |
| Detenido | Pulsaste Stop. |
Un turn que espera una tarjeta de pregunta nunca se considera atascado. Consulta ask_user para la tarjeta en sí.
Enviar mientras corre un turn #
Lo que dice el botón de enviar durante un turn te indica qué pasará con el mensaje:
- Steer (Corregir el rumbo): el mensaje entra en el turn en curso. Está disponible en Claude, DeepSeek y el motor SDK de Copilot.
- Queue (Poner en cola): el mensaje espera detrás del turn y empieza como el siguiente. El botón dice Queue en todos los demás proveedores, y también en Claude, DeepSeek y el motor SDK mientras el turn espera una tarjeta de pregunta o una aprobación del plan, o mientras está compactando, y en el motor SDK mientras se ejecuta una llamada a herramienta. Allí el mensaje espera como mensaje en cola y entra en el turn en cuanto se responde la tarjeta, termina la compactación o acaba la llamada a herramienta.
Los mensajes en cola se ejecutan en el orden en que se enviaron, el más antiguo primero.
Si tu dispositivo está sin conexión cuando pulsas enviar, el navegador guarda el mensaje y muestra You are offline. Message queued — it will send when the connection returns. (Estás sin conexión. Mensaje en cola: se enviará cuando vuelva la conexión.) Esa es otra queue: está en tu dispositivo y se vacía sola cuando vuelve la conexión.
Cancelar un mensaje en cola #
Un mensaje en cola tiene un botón Cancel hasta que el agente lo recoge. Pulsarlo quita el mensaje de la queue y muestra Queued message cancelled. (Mensaje en cola cancelado.) Si mientras tanto el agente ha empezado con el mensaje, el relay dice Message is already being processed. Use Stop on the thinking bubble instead. (El mensaje ya se está procesando. Usa Detener en la burbuja de razonamiento.)
Vaciar la queue #
El menú ⋯ de una conversación tiene una línea Queue. Muestra los totales
de todo el relay, no de esta conversación:
pending=1, processing=1, parked=0
Los mensajes Pending (Pendientes) esperan su turn. Los Processing (En proceso) se están ejecutando. Los Parked (Aparcados) están retenidos, por ejemplo mientras el relay se reinicia.
🚮 Empty queue (Vaciar la cola), a su lado, los descarta todos, en todas las conversaciones, incluido el mensaje de un turn que está en curso en ese momento. Una confirmación pregunta primero:
Drop all queue rows in pending, processing, and parked states?
This is a local maintenance action and cannot be undone.
Después, un aviso dice Queue emptied: dropped 3 rows. (Queue vaciada: 3 filas descartadas.), o Queue is already empty. (La queue ya está vacía.) cuando no había nada que descartar. Nuevo en 0.9.11 Cualquier navegador con la sesión iniciada puede usarlo: solo necesita el token de acceso (consulta Endpoints que solo puede usar la máquina del relay). Si el relay lo rechaza, Failed to empty queue (No se pudo vaciar la queue) indica el motivo. La acción solo quita los mensajes de la queue. No le dice a un agente en ejecución que se detenga; para eso usa Stop. Para deshacerte de un solo mensaje, usa en su lugar Cancel en él.
Volver a poner en cola #
Un turn que salió mal no siempre se pierde. El relay lo devuelve a la queue y lo vuelve a intentar cuando:
- el turn estaba atascado (consulta más abajo),
- el proceso worker de la sesión murió mientras se ejecutaba,
- el worker informó de un fallo que merece otro intento.
Cada vuelta a la queue cuenta como un intento. El límite es de 5 intentos por
mensaje (max en el archivo de configuración, leído al arrancar),
así que el quinto fallo es definitivo. La espera antes del siguiente intento
depende de la causa:
| Causa | Espera |
|---|---|
| Un turn que estaba atascado | 30 segundos (2 segundos mientras el relay considera desconectada la conexión con su agente) |
| El proceso worker de la sesión murió | 2 segundos |
| El worker informó de un fallo | 1, 2, 4 y luego 8 minutos tras el primer, segundo, tercer y cuarto fallo |
| El worker informó de un fallo en los 15 segundos siguientes al inicio, antes de cualquier actividad o texto de respuesta | 10, 20, 40 y luego 80 segundos |
Al llegar al límite, el mensaje falla definitivamente, con una nota (consulta más abajo).
Dos tipos de turn no se repiten. Un mensaje que ya se incorporó a un turn en curso se respondería dos veces, así que en su lugar falla con una nota. La respuesta de continuación propia de una tarea en segundo plano no tiene ningún prompt que volver a enviar, así que se descarta.
Cuando un turn está atascado #
Un turn puede ser lento, o puede estar atascado. OAR no puede saberlo mirando la respuesta, así que vigila las señales de vida. Hay tres tipos de vigilancia: el relay vigila al worker, cada worker vigila a su agente, y dos límites acotan el trabajo en segundo plano y las tarjetas de pregunta.
| Temporizador | Predeterminado | Dónde lo cambias | Lo que ves cuando salta |
|---|---|---|---|
| Inactividad: ninguna señal de vida del worker de la sesión | 10 min (45 s mientras el relay considera desconectada la conexión con su agente) | processing en el archivo de configuración, en milisegundos; reinicia el relay después de editarlo |
El turn vuelve a la queue y empieza de nuevo tras 30 segundos. |
| Max turn duration (Duración máxima del turn): el tiempo total de un turn | 60 min, de 0 a 10 h en pasos de 5 minutos; 0 significa sin límite | Settings → General → Max turn duration (Ajustes → General → Duración máxima del turn) | Lo mismo: de vuelta a la queue. En Grok, el turn falla en su lugar con una nota. |
| Silencio de una runtime de Copilot (motor SDK), Cursor o Grok: nada en curso | 120 s | OAR_ en el entorno del relay; 0 desactiva la vigilancia |
El turn falla con una nota del sistema. |
| Lo mismo, mientras se ejecuta una solicitud al modelo | 300 s | OAR_; 0 significa sin límite |
El turn falla con una nota del sistema. |
| Lo mismo, mientras se ejecuta una llamada a herramienta | 30 min | OAR_; 0 significa sin límite |
El turn falla con una nota del sistema. |
| Background task timeout (Tiempo límite de las tareas en segundo plano): solo el trabajo en segundo plano mantiene una sesión en ejecución tras su respuesta | 4 h, de 0 a 10 h en pasos de 5 minutos; 0 significa sin límite | Settings → General → Background task timeout (Ajustes → General → Tiempo límite de las tareas en segundo plano) | El relay detiene las tareas. En Claude Cloud, en su lugar termina el turn. Consulta Por proveedor. |
| Espera de una tarjeta de pregunta | 8 h; 2 h en el motor de extensión de Copilot | No ajustable | Se le dice al agente que nadie respondió, y continúa según el modo de la conversación. |
Las tres variables OAR_ en Linux y macOS
Donde las sesiones se ejecutan bajo tmux, una variable fijada para el relay no se pasa a los procesos de los agentes, y entonces estas tres pueden no tener efecto. Consulta qué variables llegan a los agentes.
Cómo funcionan juntos:
- El relay vigila al worker. El worker informa cada 10 segundos del mensaje en el que trabaja. Mientras lo haga, el turn está vivo, por mucho que dure. Si los informes se detienen durante la ventana de inactividad, el relay devuelve el turn a la queue. Lo comprueba cada 15 segundos.
- Max turn duration es el tope absoluto. Atrapa a un worker que se cuelga pero sigue informando. Un turn supera el límite cuando el más tardío de dos momentos es más antiguo que el ajuste: el inicio del turn y la última tarjeta de pregunta que respondiste. Así, una entrevista que esperó horas tus respuestas no se corta justo después de la última respuesta. Hay una pega. Cuando la comprobación devuelve un turn a la queue, devuelve todos los turns en curso cuyo inicio es más antiguo que el límite, y para esos no mira tus respuestas. Por eso, un turn en el que respondiste una tarjeta hace poco puede volver a la queue junto con otro turn que alcanzó un límite en la misma comprobación (cada 15 segundos). Si un turn largo vuelve a la queue sin motivo aparente, sube este ajuste o fíjalo en 0.
- Cada worker vigila también a su agente. En el motor SDK de Copilot, Cursor y Grok, un turn sin ningún evento de la runtime durante más tiempo que su ventana falla. La ventana depende de lo que esté haciendo la runtime: un comando que no imprime nada puede estar callado mucho tiempo; un modelo que está escribiendo, no. Por eso las tres ventanas son distintas. Cuando solo se fija la ventana de inactividad, las otras dos se escalan con ella.
- Un turn que espera nunca está atascado. Un turn que espera una tarjeta de
pregunta detiene las dos protecciones del relay y la vigilancia de silencio
del worker. (El tope de Grok y el límite de 2 horas del motor de extensión no se pausan por ello.) Una compactación y una
llamada a
relay_también retienen la vigilancia de silencio. Max turn duration no sabe nada de una espera larga detool relay_, así que una espera cercana a su máximo, con los 60 minutos predeterminados, puede quedar cortada por él.tool - Las tareas en segundo plano van aparte. El tiempo límite de las tareas solo cuenta después de la respuesta, cuando solo las tareas en segundo plano mantienen la sesión activa. No limita un turn. Claude Cloud es la excepción; consulta más abajo.
Una vuelta a la queue no se muestra como un error. El mensaje vuelve a queued (en cola) y se ejecuta de nuevo. Solo cuando se agotan los intentos falla el turn.
Cuando un turn falla #
Un turn fallido termina con una respuesta del relay, en texto sin formato. Dice qué pasó, termina con un código de error y te dice qué hacer a continuación. Un turn que terminó la vigilancia de silencio dice, por ejemplo:
System note: the Copilot runtime sent nothing for 300s while a model request was running, so the relay ended the turn.
Cuando lo que se estaba ejecutando era la herramienta, la nota la nombra: while a tool was running (build) (mientras se ejecutaba una herramienta, build). Una runtime que ya no responde cuando el relay le pregunta dice the Copilot runtime stopped answering … (nothing for 120s, no reply when asked), so the relay ended the turn. (la runtime de Copilot dejó de responder …, sin nada durante 120 s ni respuesta al preguntarle, así que el relay terminó el turn.)
Un mensaje que agotó sus intentos falla con uno de estos:
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.
La mayoría de los fallos terminan con el consejo de volver a enviar el mensaje. Dos cosas ayudan:
- Vuelve a enviarlo. Pega o vuelve a escribir el mensaje, o pulsa Resend (Reenviar) donde la transcripción lo ofrezca. Resend aparece en un mensaje que corrigió el rumbo de un turn que luego falló o se detuvo. Su marcador dice Steered into the turn above, which failed — not answered. (Corrigió el rumbo del turn de arriba, que falló; sin respuesta.) o Stopped with the turn — not answered. (Detenido con el turn; sin respuesta.) Después de pulsarlo, el botón dice Resent (Reenviado) en todos los dispositivos.
- Usa el botón de la respuesta. Algunos fallos indican un arreglo que el relay puede hacer por ti, y la respuesta fallida lleva un botón para ello. Un problema con la cuenta de Claude muestra Claude settings (Ajustes de Claude). Nuevo en 0.9.17 Un turn de DeepSeek rechazado porque se agotó el saldo muestra Top up DeepSeek (Recargar DeepSeek) y DeepSeek settings (Ajustes de DeepSeek); uno rechazado por la clave de API muestra DeepSeek settings (consulta Errores de DeepSeek). Un turn de Grok que no pudo empezar muestra Install Grok CLI (Instalar Grok CLI) y Grok settings (Ajustes de Grok), o Sign in to Grok (Iniciar sesión en Grok) y Grok settings cuando no había iniciado sesión.
Una conversación cuyo worker de sesión se detuvo por un problema de arranque muestra un botón Retry (Reintentar) en la nota, que vuelve a iniciar el worker.
Una conversación que parece bloqueada se puede liberar con ☠️ Kill session (Matar la sesión) en el
menú ⋯, que detiene su worker. Después vuelve a enviar el mensaje.
Por proveedor #
La queue, Cancel, Empty queue, la ventana de inactividad y Max turn duration son iguales en todos los proveedores. Lo que cambia es la vigilancia del propio agente.
| Proveedor | Vigilancia de silencio | Steer o Queue |
|---|---|---|
| GitHub Copilot y OpenAI, motor SDK | Sí: 120 s, 300 s y 30 min. Una vez por ventana de inactividad, el worker pregunta a la runtime si sigue ahí, con 5 segundos para responder; una runtime que no responde termina el turn al instante. | Steer |
| GitHub Copilot, motor de extensión | Sin vigilancia de silencio. Un turn está limitado a 2 horas en total; cuando se agotan, el turn vuelve a la queue y cuenta como un intento fallido, con las esperas de arriba. Con los 60 minutos predeterminados, Max turn duration normalmente actúa antes. Una tarjeta de pregunta espera 2 horas. | Queue |
| Claude | Solo observa. Un turn en el que la CLI no ha dicho nada durante 10 minutos (30 con una herramienta abierta) se anota en el log del worker y se deja en ejecución, porque terminarlo mataría la CLI y sus tareas en segundo plano. | Steer |
| DeepSeek Nuevo en 0.9.17 | Como Claude: un chat de DeepSeek ejecuta Claude Code, con la misma vigilancia que solo observa. | Steer |
| Claude Cloud | Sin vigilancia de silencio sobre el agente. El worker vigila su conexión: un stream sin datos durante 120 s se vuelve a abrir, y un stream que sigue ausente durante 5 minutos devuelve el mensaje a la queue, donde el siguiente intento sigue el mismo turn en lugar de volver a enviarlo. Un turn en la nube que está callado mientras su conexión sigue viva continúa en ejecución. Cuando el agente termina su turn mientras aún se ejecuta trabajo en segundo plano, el turn sigue abierto durante Background task timeout (60 minutos si es 0). Después termina con una línea de actividad que te dice que envíes un mensaje para ver cómo fue el trabajo. | Queue |
| Cursor | Sí, con las mismas tres ventanas. No hay fase de inactividad mientras una ejecución está en marcha: cuenta como una solicitud al modelo salvo que haya una llamada a herramienta abierta. | Queue |
| Grok | Sí, con las mismas tres ventanas; primero se pregunta por una llamada a relay_ pendiente. Un OAR_ de 0 no la desactiva aquí. El turn también tiene el tope de Max turn duration, contado desde el inicio del turn sin reiniciarse por las preguntas respondidas, y una tarjeta que dejas sin responder también cuenta. Un turn de Grok que alcanza el tope falla con System note: the Grok turn stalled and was stopped (grok turn exceeded the 60-minute turn ceiling). Send a new message to retry. (Nota del sistema: el turn de Grok se atascó y se detuvo; el turn de Grok superó el tope de 60 minutos por turn. Envía un mensaje nuevo para reintentarlo.) (o el número que hayas fijado). |
Queue |
Background task timeout se aplica a Claude, Claude API, DeepSeek, el motor SDK de Copilot y Claude Cloud. En Claude, Claude API y DeepSeek detiene las tareas en segundo plano. En el motor SDK de Copilot, el relay las cancela. En Claude Cloud solo fija cuánto tiempo las espera el turn. No se aplica a los demás proveedores.