Escalar Codex CLI no consiste en comprar una máquina enorme. Consiste en mantener cada agente aburrido, aislado y fácil de detener cuando se desvía.
Solemos ver el mismo fallo: una sesión exitosa de Codex se convierte en tres, luego en seis, y de pronto un VPS queda lleno de ramas a medias, paneles de tmux escondidos y logs que nadie lee. La solución es una forma de escalar, no heroísmo.
Empieza con la unidad de escala
La unidad de escala debe ser un runner de agente: un directorio de trabajo, una rama, una tarea y un flujo de logs. Si dos agentes comparten un checkout, tarde o temprano se pisan o ejecutan tests contra un estado mezclado.
# keep each runner boring and observable
export CODEX_WORKDIR=/srv/agents/$AGENT_NAME
export CODEX_BRANCH=agent/$AGENT_NAME/$TASK_ID
export CODEX_LOG=/var/log/office-claws/$AGENT_NAME.log
export CODEX_TIMEOUT_MINUTES=90Parece simple porque debería serlo. Antes de añadir más capacidad de VPS, cada runner debe responder cuatro preguntas:
- ¿dónde está el checkout del repo?
- ¿qué rama posee esta tarea?
- ¿dónde van los logs?
- ¿quién puede detenerlo?
Añade concurrencia poco a poco
El error de escala más barato es ejecutar demasiados agentes antes de conocer el cuello de botella. El trabajo con Codex CLI suele topar con uno de cuatro límites: CPU durante tests, RAM durante builds, disco durante instalaciones de dependencias o capacidad humana de review cuando los agentes terminan.
| Stage | Good default | Watch first |
|---|---|---|
| Repo pequeño, tests ligeros | 1-2 agentes por VPS de 2GB | RAM y swap |
| App web con builds | 1 agente por VPS de 2GB | tiempo de build |
| Monorepo pesado | 1 agente por VPS de 4GB+ | CPU e IO de disco |
| Flujo con mucho review | menos agentes que reviewers | backlog de PRs |
Office Claws hace esto visible en la app de escritorio en vez de obligarte a recordar qué terminal pertenece a cada tarea. Self-Hosted se mantiene en $4.99/mes si traes tu cuenta de DigitalOcean; Managed empieza en $14.99/mes si quieres que llevemos la parte del VPS.
Divide el trabajo por riesgo
No escales copiando el mismo prompt en cinco agentes. Escala dando a cada agente un perfil de riesgo distinto.
Un patrón que aguanta:
- Safe lane — docs, tests, refactors pequeños, limpieza de dependencias.
- Medium lane — ramas de features con criterios de aceptación claros.
- Risky lane — migraciones, auth, billing, scripts de deploy, todo lo que pide review lento.
Pon el carril arriesgado en el runner más tranquilo. Dale timeouts más largos, menos vecinos concurrentes y un checkpoint humano antes de tocar código con forma de producción.
Saber cuándo añadir otro VPS
Un VPS más grande ayuda hasta que se convierte en un radio de explosión compartido. Preferimos añadir otro runner pequeño cuando el aislamiento importa más que la velocidad bruta.
Añade capacidad cuando:
- los tests esperan detrás de trabajo no relacionado
- una instalación de dependencias rota bloquea a todos los agentes
- los logs son demasiado ruidosos para depurar rápido
- la cola de review está sana pero los agentes esperan
No añadas capacidad si las personas ya van atrasadas con reviews. Más agentes solo crearán más ramas viejas.
Qué viene después
Si estás comparando frameworks de agentes, empieza con nuestra comparación OpenClaw vs Codex. Si ya sabes que el trabajo tiene forma de repo, la ruta Office Claws for OpenClaw users te da runners persistentes de Codex sin convertir la escala en arqueología de terminales.
Nuestra recomendación es simple: escala Codex CLI de un runner en un runner, mantén cada rama aislada y deja de añadir agentes en cuanto el review sea el cuello de botella.