Tareas en segundo plano

Un agente puede dejar trabajo corriendo después de responder: un servidor de desarrollo, una compilación larga o un subagent que trabaja por su cuenta. OAR lo llama tarea en segundo plano. El panel de tareas, encima del área de redacción, lista estas tareas, te deja detener cada una y abrir la salida de un comando, y el informe del agente sobre una tarea terminada llega como una respuesta propia.

Qué cuenta como tarea en segundo plano #

• Un comando de shell que el agente dejó corriendo, como un servidor de desarrollo o una compilación larga. Nuevo en 0.9.12 En Grok, todo comando que corre más de dos segundos.
• Un subagent que trabaja en segundo plano. Los subagents tienen su propia página; aquí son una fila más del panel.
• Un monitor y, en Claude, un flujo de trabajo Ultracode (consulta Flujos de trabajo de Ultracode).

Cuando el agente ha respondido y solo quedan tareas así, la conversación ya no está ejecutando un turn, pero tampoco está inactiva. Los otros agentes lo ven como el estado background_only (consulta Cómo lo ven otros agentes). Tú lo ves como el panel de tareas, que sigue visible mientras corra una tarea. La lista de conversaciones lo muestra con el color del título: una sesión con un turn o trabajo en segundo plano en marcha mantiene el título en verde brillante (consulta Qué muestra una fila).

El panel de tareas #

El panel está justo encima del cuadro de mensaje. Está plegado en una línea, como 2 background tasks running (2 tareas en segundo plano en ejecución), con un indicador giratorio mientras corren tareas, y · 1 finished cuando hay comandos terminados en la lista. Haz clic en la línea para abrir la lista. El panel se oculta cuando no hay nada que mostrar, y la lista se desplaza cuando tiene más filas de las que caben.

Cada fila muestra:

Una fila en ejecución no tiene una etiqueta de estado aparte: una tarea que está en el panel está corriendo. Un subagent sale del panel cuando termina; un comando de shell o un monitor puede quedarse una hora como fila terminada. Tras Stop, el botón dice Stopping… (Deteniendo…) hasta la siguiente actualización del panel, durante hasta 15 segundos.

En el motor SDK de Copilot, una shell no tiene botón Stop cuando la runtime de Copilot no puede listar sus tareas en segundo plano. Una shell así solo la puedes terminar con Kill session (Matar la sesión) (consulta Qué termina una tarea).

Las tarjetas de vista previa están en el mismo panel, encima de las tareas. Consulta Lo que ves. Una vista previa mantiene abierto el panel después de que haya terminado la tarea que arrancó su servidor.

La consola de tareas Nuevo en 0.9.12 #

Haz clic en la descripción de un comando de shell o de un monitor en el panel y se abre su consola: la salida del comando, para que veas qué está haciendo una compilación, un servidor de desarrollo o una ejecución de tests sin preguntar al agente. En un teléfono ocupa la pantalla. Nuevo en 0.9.13 En una pantalla más ancha termina encima de la fila de la tarea en el panel, para que el chip de tests, el reloj y Stop de la fila sigan a la vista y se actualicen a su lado. Escape, ×, un clic fuera de ella o el botón Atrás la cierran.

• Las últimas 2.000 líneas se muestran al abrirla, y la salida nueva aparece en vivo. Si te desplazas hacia arriba, te quedas donde estás, y Jump to end ↓ (Ir al final) te lleva de vuelta.
• Load earlier (Cargar anteriores), arriba, recorre hacia atrás todo el registro, hasta 2.000 líneas cada vez, hasta cargar unos 5 MB. A partir de ahí el botón dice older output not loaded (salida anterior no cargada). Nuevo en 0.9.13 La cabecera de la consola tiene el mismo botón siempre que hay salida anterior, para que esté a mano mientras sigues el final de un registro largo.
• Las barras de progreso que redibujan una línea solo muestran su último estado, y una línea repetida varias veces seguidas aparece una vez con ×N.
• Los colores se mantienen, así que un fallo en rojo sigue en rojo. Nuevo en 0.9.13 El texto invertido intercambia sus colores, así que las insignias RUN, PASS y FAIL de vitest aparecen rellenas. Los demás códigos de control se descartan, y una línea se corta a los 4.000 caracteres.
• Las credenciales se ocultan: los tokens y las claves con las formas habituales, las cabeceras Bearer y Basic, una contraseña en una dirección y un valor después de un nombre como API_TOKEN= o password: aparecen como [redacted]. Nuevo en 0.9.13 Lo mismo ocurre con la contraseña de curl -u name:password, los valores de --password, --token y --secret, mysql -p…, docker login -p, sshpass -p, redis-cli -a, una clave de acceso secreta de AWS, la ruta de un webhook de Slack, los valores ?key=, &sig= y &token= de una dirección, y una cabecera Authorization con cualquier esquema. Una referencia como $API_TOKEN o $(cat ~/.token) se deja tal cual. Las filas de tareas del panel se limpian de la misma forma: la descripción, el resumen y la línea de actividad de una tarea.

La cabecera nombra la tarea, su tipo (Shell o Monitor), el tiempo que lleva corriendo y si está running, completed, stopped o failed, exit code 1, o Nuevo en 0.9.13 waiting for its worker after the relay restart (consulta Tras un reinicio del relay). También lleva la indicación de silencio y el chip de tests, y su propio Stop mientras la tarea corre.

Los agentes de este relay o de otro pueden leer la misma salida con read_task_output. Lo que ofrece cada proveedor está en Por proveedor.

Tareas silenciosas #

Un comando de shell o un monitor en marcha que no ha escrito nada durante un minuto o más lo indica en su fila y en la cabecera de su consola: no output for 12 min. A partir de Settings → General → Mark a background task as quiet after (Ajustes → General → Marcar una tarea en segundo plano como silenciosa tras), la indicación se vuelve ámbar. Son 10 minutos de forma predeterminada, de 1 a 120 minutos, y se aplica a todos los navegadores del relay.

Silencioso no es atascado: algunos pasos no imprimen nada durante mucho tiempo. Abre la consola para ver las últimas líneas y luego espera, sube el ajuste o detén la tarea con Stop. El relay mira la salida cada 10 segundos, así que la indicación puede ir con ese retraso.

Comandos canalizados a tail Nuevo en 0.9.13 #

Un comando canalizado a tail, como npm test 2>&1 | tail -40, no escribe nada hasta que termina: tail retiene las últimas líneas hasta entonces. Su consola parecería atascada. Cuando la línea de comandos de la tarea muestra una canalización así, la consola marca dónde se detiene la salida, hasta que llega más salida o la tarea termina:

Output stops here: this command pipes into tail, so the rest arrives when it ends.
Logging to a file instead (> run.log 2>&1) and following that file shows it live.

La indicación no output for N min de la fila dice lo mismo al pasar el puntero. tail -f y head pasan las líneas según llegan y no se marcan. Para seguir una ejecución en vivo, pide al agente que escriba el registro en un archivo (> run.log 2>&1) y sigue ese archivo.

Claude, DeepSeek, Copilot y Grok informan para esto de la línea de comandos de una tarea de shell. El relay oculta las credenciales en ella, como en la salida, y conserva sus primeros 2.000 caracteres. Una sesión cuyo agente arrancó antes de la actualización a 0.9.13 no informa de ninguna.

Ejecuciones de tests #

Cuando la salida de un comando parece una ejecución de tests de vitest, Playwright, node:test, jest, pytest o turbo (también si se inició a través de pnpm), su fila y la cabecera de su consola muestran un chip con los recuentos: ✓ 412 ✘ 2 en rojo cuando fallaron tests, o ✓ 38 cuando no falló ninguno. Pasa el puntero sobre el chip para ver el ejecutor y los recuentos de tests superados, fallidos y omitidos. Los recuentos siguen la ejecución mientras avanza. Nuevo en 0.9.13 Una ejecución en curso se cuenta sobre todo su registro, por largo que sea, leyéndolo a medida que crece, así que el chip conserva todos los tests aunque la salida supere lo que muestra la consola. En cuanto el ejecutor imprime su resumen final, ese resumen manda.

En la consola, el chip y el botón first failure (primer fallo) que hay a su lado, que aparece cuando fallaron tests, saltan al primer test fallido de la salida cargada. Si está en salida anterior, la consola lo indica; Load earlier la trae.

Comandos terminados #

Un comando de shell o un monitor cuya salida lee el relay de un archivo se queda en el panel durante una hora después de terminar, como fila atenuada: ✓ si se completó, ✘ si falló, ■ si se detuvo, Nuevo en 0.9.13 ? si el relay no puede saber cómo terminó (Tras un reinicio del relay), con cuánto tiempo corrió y su chip de tests. Su consola se sigue abriendo, así que puedes leer por qué falló una ejecución cuando el agente ya ha pasado a otra cosa. × oculta la fila hasta que recargas la página. Se conservan como máximo 20 filas así por conversación. Nuevo en 0.9.13 Sobreviven a un reinicio del relay (consulta Tras un reinicio del relay).

Cuando termina una tarea #

Cuando una tarea termina, sale del panel, o un comando se queda como fila terminada. El agente se despierta, mira el resultado y responde. Esa respuesta es una respuesta de continuación: no es una respuesta a un mensaje tuyo, y su cabecera lleva una insignia background continuation (continuación en segundo plano). Puedes leerla como cualquier otra respuesta.

Para las notificaciones, una continuación es una respuesta como cualquier otra, así que un dispositivo que te avisa cuando termina un turn también lo hace aquí: Turn completed (Turn completado) en Settings → Notifications (Ajustes → Notificaciones). Un agente que vigila la sesión recibe en su lugar un evento task_finished o task_failed (consulta Cómo lo ven otros agentes).

Si entre el final de una tarea y su continuación se produce un reinicio del relay, la continuación se descarta, no se vuelve a ejecutar. Consulta Reinicios y reanudación.

Flujos de trabajo de Ultracode #

Los flujos de trabajo de Ultracode son una función de Claude. El panel muestra uno como una fila Workflow con un chevrón. Abre el chevrón para ver el árbol de progreso.

• Las fases son cabeceras, y los agentes del flujo de trabajo están debajo de ellas.
• Cada agente muestra un icono de estado (○ en cola, ◐ en ejecución, ✓ hecho, ✗ fallido o matado), su etiqueta y una línea con el modelo, los tokens, el número de llamadas a herramientas, el tiempo y, tras un reintento, attempt 2. Un agente en ejecución añade la herramienta que está usando.
• Las líneas de registro, las cinco últimas, están encima de las fases.
• Un árbol de más de 100 agentes termina con +N more agents (+N agentes más).

El árbol está abierto mientras el flujo de trabajo corre y se pliega cuando ha terminado. Lo que elijas con el chevrón se conserva mientras la fila esté en el panel. Mientras el flujo de trabajo corre, puede que al árbol le falten títulos de fase y líneas de registro; el árbol final los tiene.

Cuando el flujo de trabajo termina, la respuesta que lo resume conserva una tarjeta plegada en la transcripción:

🧩 Finished background task — review-shared-modules · 20 agents · 1.2M tok · 28m

Ábrela para ver el árbol final. Los campos que no se conocen se omiten, y un flujo de trabajo que no se completó indica cómo entre paréntesis, como en Finished background task (failed), o (unconfirmed) cuando el resultado nunca llegó. La tarjeta se guarda con la respuesta y sigue ahí tras recargar.

Tiempo límite de las tareas en segundo plano #

Settings → General → Background task timeout (Ajustes → General → Tiempo límite de las tareas en segundo plano) fija cuánto tiempo pueden mantener en marcha una sesión las tareas en segundo plano por sí solas después de su respuesta. Es un control deslizante de 0 a 10 horas en pasos de 5 minutos. El valor predeterminado es 4 horas. 0 significa sin límite: las tareas corren entonces hasta que terminan o las detienes.

Cuando se acaba el tiempo, el relay detiene las tareas, y el agente informa de ello en una respuesta de continuación, como con cualquier tarea que termina. En Claude y DeepSeek el reloj solo cuenta mientras nada más que las tareas mantiene la sesión en marcha, y vuelve a empezar de cero cada vez que corre un turn entremedias. En el motor SDK de Copilot cada tarea tiene su propio reloj, que empieza cuando empieza esa tarea. Cómo encaja entre los demás temporizadores se explica en Los turns y la queue.

Qué termina una tarea #

Tras un reinicio del relay Nuevo en 0.9.11 #

Un worker que sigue en marcha durante un reinicio del relay conserva sus tareas, y el relay se las vuelve a pedir en el siguiente latido del worker. Vuelven al panel con su hora de inicio original, así que la sesión sigue constando como en marcha: Suspend host (Suspender el host) las espera, y a una sesión que vigila no se le comunica all_idle. Una tarea que terminó mientras el relay no estaba sigue informando de su final.

Una sesión cuyo worker se arrancó antes de la actualización a 0.9.11 todavía no puede responder a esa pregunta. Muestra una fila, background work, details not reported since the relay restarted (Kill session in its ⋯ menu ends it), hasta que informa de un cambio. Durante los primeros 45 segundos tras arrancar el relay, una suspensión también espera a las sesiones que todavía no han informado.

Nuevo en 0.9.12 Las consolas de las tareas que vuelven se abren de nuevo, con todo el registro, y la indicación de silencio vuelve a aparecer en cuanto el relay ha mirado la salida.

Nuevo en 0.9.13 El relay guarda las filas de consola en su base de datos, así que las consolas también sobreviven al reinicio:

• Las filas terminadas vuelven con su ✓ o ✘ durante el resto de su hora.
• La consola de un comando en ejecución lee su salida en el acto, antes de que su worker haya informado. Hasta que el worker dice que el comando sigue corriendo, la consola indica que espera a su worker y no tiene Stop.
• Un comando cuyo worker no volvió (cayó con el relay, por ejemplo en un reinicio de la máquina) se marca como terminado al cabo de un minuto y medio aproximadamente, nunca como de nuevo en ejecución. El relay no puede saber cómo terminó, así que su fila muestra un ? neutro en lugar de ✓ o ✘, con el título ended, result unknown (terminado, resultado desconocido). Su salida sigue legible durante el resto de la hora.

Los comandos que corrieron antes de la actualización a 0.9.13 no tienen fila guardada; vuelven cuando su worker informa, como arriba.

Con el servicio de Linux, un reinicio detiene los workers, y con ellos sus tareas; consulta Qué conserva un reinicio.

Cómo lo ven otros agentes #

list_sessions y read_session dan a cada sesión un state: running_turn, background_only (el agente ha respondido, sigue corriendo trabajo en segundo plano) o idle. También listan sus tasks, los agentes en segundo plano y las tareas de shell, con cuándo empezó cada una, cuándo hizo algo por última vez, cómo terminó y el código de salida cuando se conoce. Por eso, una sesión con solo tareas en segundo plano no consta como inactiva. Nuevo en 0.9.12 En el motor SDK de Copilot, una tarea terminada informa de completed, failed o stopped, una shell de su código de salida, y un subagent de su resultado (o su error) como resumen; antes, esas tareas terminaban como unknown.

Un agente que vigila la sesión puede despertarse con los eventos task_finished y task_failed, cada uno con la descripción, el resultado y el resumen de la tarea. Una tarea que se detuvo, o que salió con un código distinto de cero, cuenta como fallida. También puede pedir task_started. Nuevo en 0.9.13 De forma predeterminada, un agente que vigila se entera de un subagent que terminó y de cada tarea que falló, pero no de un comando de shell o un monitor que terminó bien; para recibirlos indica task_finished.

Nuevo en 0.9.12 read_session también da a cada tarea su taskId, si tiene salida que leer y, para un comando, su tiempo en silencio y sus recuentos de tests. Nuevo en 0.9.13 También da la línea de comandos de una tarea de shell, cuando el proveedor la informa. La descripción, el resumen, la última llamada a herramienta y la línea de comandos de una tarea tienen las credenciales ocultas, como en la consola. read_task_output lee luego el final de esa salida, limpiado como el de la consola.

Por proveedor #

El árbol de Ultracode y la tarjeta Finished background task (Tarea en segundo plano terminada) solo existen en Claude. La tabla completa de capacidades está en Los proveedores de un vistazo.