Faire évoluer Codex CLI ne consiste pas à acheter une énorme machine. Il s’agit de garder chaque agent ennuyeux, isolé et facile à arrêter quand il dévie.
Nous voyons souvent le même échec : une session Codex réussie devient trois sessions, puis six, et soudain un VPS se remplit de branches à moitié terminées, de panneaux tmux cachés et de logs que personne ne lit. La solution est une forme de mise à l’échelle, pas un acte héroïque.
Commencer par l’unité de mise à l’échelle
L’unité de mise à l’échelle doit être un runner d’agent : un répertoire de travail, une branche, une tâche, un flux de logs. Si deux agents partagent le même checkout, ils finiront par s’écraser ou lancer des tests sur un état mélangé.
# 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=90C’est simple parce que cela doit l’être. Avant d’ajouter de la capacité VPS, chaque runner doit répondre à quatre questions :
- où se trouve le checkout du repo ?
- quelle branche possède cette tâche ?
- où vont les logs ?
- qui a le droit de l’arrêter ?
Ajouter la concurrence lentement
L’erreur de mise à l’échelle la moins chère consiste à lancer trop d’agents avant de connaître le goulot. Le travail Codex CLI atteint généralement l’une de quatre limites : CPU pendant les tests, RAM pendant les builds, disque pendant l’installation des dépendances, ou capacité humaine de review après la fin des agents.
| Stage | Good default | Watch first |
|---|---|---|
| Petit repo, tests légers | 1-2 agents par VPS 2GB | RAM et swap |
| App web avec builds | 1 agent par VPS 2GB | temps de build |
| Gros monorepo | 1 agent par VPS 4GB+ | CPU et IO disque |
| Workflow riche en review | moins d’agents que de reviewers | backlog de PR |
Office Claws rend cela visible dans l’app desktop au lieu de vous demander de retenir quel terminal appartient à quelle tâche. Self-Hosted reste à $4.99/mois si vous apportez votre compte DigitalOcean ; Managed commence à $14.99/mois si vous voulez que nous gérions le côté VPS.
Séparer le travail par risque
Ne scalez pas en copiant le même prompt dans cinq agents. Scalez en donnant à chaque agent un profil de risque différent.
Un modèle qui tient :
- Safe lane — docs, tests, petits refactorings, nettoyage des dépendances.
- Medium lane — branches de fonctionnalité avec critères d’acceptation clairs.
- Risky lane — migrations, auth, billing, scripts de déploiement, tout ce qui demande une review plus lente.
Placez la voie risquée sur le runner le plus calme. Donnez-lui des timeouts plus longs, moins de voisins concurrents et un checkpoint humain avant qu’elle touche du code proche de la production.
Savoir quand ajouter un autre VPS
Un VPS plus grand est utile jusqu’à devenir un rayon d’explosion partagé. Nous préférons ajouter un petit runner quand l’isolation compte plus que la vitesse brute.
Ajoutez de la capacité quand :
- les tests attendent derrière du travail sans rapport
- une installation de dépendances cassée bloque tous les agents
- les logs sont trop bruyants pour déboguer vite
- la file de review est saine mais les agents attendent
N’ajoutez pas de capacité si les humains sont déjà en retard sur les reviews. Plus d’agents ne feront que créer plus de branches périmées.
Et ensuite
Si vous comparez des frameworks d’agents, commencez par notre comparaison OpenClaw vs Codex. Si vous savez déjà que le travail est centré sur le repo, le parcours Office Claws for OpenClaw users vous donne des runners Codex persistants sans transformer la mise à l’échelle en archéologie de terminal.
Notre recommandation est simple : faites évoluer Codex CLI un runner à la fois, gardez chaque branche isolée et cessez d’ajouter des agents dès que la review devient le goulot.