Tareas largas de Codex: Cómo mantener un agente trabajando mientras duermes

Las tareas que no caben en un portátil

La mayoría del trabajo con Codex es corto. Haces una pregunta, esperas veinte segundos, recibes un parche. Lo repites cien veces al día y un portátil lo gestiona sin problemas.

Las tareas que revientan el modelo del portátil tienen otra pinta. Una refactorización nocturna que reescribe cincuenta archivos y ejecuta la suite de tests tras cada pasada. Una revisión por lotes en la que el agente lee cada PR abierta, escribe un resumen y lo publica en Slack. Un barrido de documentación que recorre el código durante dos horas y produce una referencia nueva. No son turnos de chat — son trabajos, y su duración se mide en horas.

El portátil falla en todos del mismo modo. Cierras la tapa, cambias de WiFi o la batería muere en un tren, y el proceso de Codex CLI se va con ello. El contexto que el agente había construido se evapora. Vuelves por la mañana y te encuentras con un terminal muerto y nada que justifique las seis horas que querías dejarlo corriendo.

Qué significa «tarea larga» para Codex

Una tarea de Codex es larga cuando se cumple alguno de estos puntos:

• El tiempo total supera una sesión típica de portátil. Cualquier cosa por encima de ~2 horas tropieza con sueño, un trayecto o una reunión en la que cierras la tapa
• La tarea tiene que sobrevivir a cambios de red. Cafetería → casa → oficina implica que la IP de tu portátil cambia tres veces; cada transición puede tumbar la sesión de Codex
• Depende del estado que el agente ha construido antes. Si ha pasado una hora leyendo y resumiendo archivos, perder ese contexto te cuesta la hora, no sólo la última petición
• Quieres que el agente reaccione a eventos externos. Webhooks de GitHub, disparadores cron, un archivo que cae en S3 — nada de eso espera a que vuelvas a abrir el portátil

En cuanto una tarea cruza alguna de esas líneas, necesitas un host que siga en línea cuando tú no lo estás.

Cuatro patrones que sí aguantan horas

Cada flujo largo de Codex que corremos en Office Claws encaja en uno de cuatro perfiles. Ninguno funciona en un portátil; todos funcionan en un VPS.

El hilo común: el agente tiene que estar accesible, en marcha y sosteniendo contexto en un momento que no depende de cuándo estás tecleando.

El montaje con VPS que realmente funciona

En Office Claws, cada agente vive en su propio droplet de DigitalOcean, provisionado en unos dos minutos y medio a partir de una snapshot preconstruida. Codex CLI está instalado, con sesión iniciada en tu suscripción de ChatGPT Plus o Pro y accesible por Tailscale. El droplet cuesta 4 $/mes en el plan Self-Hosted (4,99 $/mes por la app, 2,99 $ para nuestros primeros 100 usuarios) o va incluido en los 14,99 $/mes del plan Managed.

El flujo que usamos para tareas largas es así:

# From your laptop, over Tailscale — connects to the droplet
ssh office-claws-agent
 
# Start the task in a persistent session so it survives the SSH drop
tmux new -s refactor
codex "rewrite backend/services/* to use the new context shape; \
       after each file, run go test ./...; if tests fail, revert that file"
 
# Detach: Ctrl+b, then d. Close the laptop. Go to bed.

Por la mañana tmux attach -t refactor y el log completo te está esperando. El agente trabajó toda la noche. Tu suscripción cubrió los tokens. El droplet te costó unos doce céntimos por las ocho horas.

Tres errores que desperdician el montaje

La mayoría de fallos que hemos visto se concentran en las mismas tres cosas:

1. Ejecutar Codex en una sesión SSH normal en lugar de tmux o screen. La conexión SSH cae y Codex cae con ella. Envuelve siempre una tarea larga en una sesión persistente — tmux, screen o un servicio systemd si quieres que corra totalmente desatendida
2. Dejar que se llene el disco del VPS. Las refactorizaciones largas generan logs y artefactos de test. Un disco lleno mata la tarea a la hora sexta. Añade un cron que trunque ~/.codex/logs semanalmente
3. Olvidar los rate limits. ChatGPT Plus tope por número de mensajes en una ventana deslizante. Una tarea que martillea la API sin pausa llega al tope hacia la tercera hora. Para cargas nocturnas realmente fuertes, pasa a Pro — los 200 $/mes casi nunca se agotan ni con flujos agresivos

Cuándo usar un trabajo programado

No toda tarea larga tiene que ser interactiva. Si el trabajo no tiene ambigüedad — «cada lunes a las 06:00 resume los commits de la semana y publícalos en Slack» — sáltate el baile de tmux y móntalo como entrada de cron en el droplet. Codex CLI corre sin problemas en modo headless con un prompt en stdin. El VPS se vuelve el planificador, recibes un correo en caso de fallo y no hay nada a lo que volver a engancharse.

Cubrimos el patrón completo para cargas programadas y por lotes en una guía aparte, pero la versión corta: si el prompt es el mismo cada vez y la salida es legible por máquinas, va a cron, no a una ventana de chat.

Cómo cambia esto tu forma de trabajar

En cuanto las tareas largas dejan de necesitar un portátil, la pregunta cambia. Dejas de preguntarte «¿tengo tiempo ahora para lanzar esto?» y empiezas a preguntarte «¿quiero el resultado por la mañana o al final de la semana?». El agente se convierte en un worker de fondo, no en una herramienta de primer plano. El portátil se convierte en una interfaz hacia algo que ya estaba corriendo antes de que lo abrieses.

Ése es todo el argumento para poner Codex en un VPS. La factura de tokens es la misma. El modelo es el mismo. Lo que cambia es que el reloj sigue contando cuando tú paras.

Lecturas relacionadas

• Suscripción Codex vs API: Qué factura sale realmente más barata — por qué una suscripción Plus de 20 $ en un VPS le gana a la API para la mayoría de cargas
• Cómo gestionar agentes de IA en un VPS sin montar un caos de ops — la parte operativa de mantener sanos a los agentes largos
• Self-Hosted vs Managed — elegir el plan de Office Claws que encaja con un flujo largo