Faire tourner plusieurs agents Codex en parallèle sans se marcher dessus

Faire tourner plusieurs agents Codex en parallèle sans se marcher dessus — Un montage concret pour faire tourner plusieurs agents Codex CLI en parallèle — séparation de l'auth, isolation des workspaces, hygiène des rate limits, et les erreurs qui font que les agents s'écrasent mutuellement.
21 avr. 20267 min de lecture
Share with

Un Codex, c'est facile. Quatre, c'est un problème d'ops.

Lancer un seul agent Codex, c'est une commande codex. Il se connecte, prend votre dépôt, fait son travail. La première tentative « multi-agents » de la plupart des gens consiste à ouvrir quatre terminaux et à taper la même commande quatre fois. Ça marche, grosso modo, pendant dix minutes — jusqu'à ce que deux agents se battent pour les mêmes fichiers, ou que l'un épuise le plafond de messages de ChatGPT Plus et emporte les trois autres avec lui.

La vraie question n'est pas de savoir si l'on peut faire tourner plusieurs agents Codex en même temps. C'est comment faire pour qu'ils ne se marchent pas dessus. Nous faisons tourner quatre à six agents Codex en parallèle la plupart des jours, et les modes de défaillance sont les mêmes. Voici le montage qui y résiste.

Quatre agents Codex sur des hôtes VPS isolés, reliés par Tailscale

Ce qui entre réellement en collision quand on fait tourner des agents en parallèle

Avant de choisir un montage, il faut être précis sur ce qui casse. Nous avons vu trois catégories de collisions :

  • Collisions d'auth. La Codex CLI met en cache les identifiants de l'abonnement dans ~/.codex/. Deux processus qui se partagent ce répertoire se battent sur le rafraîchissement du token, se déconnectent l'un l'autre, ou déclenchent une boucle de réauthentification qui bloque le compte pendant plusieurs minutes
  • Collisions de système de fichiers. Deux agents qui éditent le même working tree s'écrasent mutuellement. Même un agent qui lance go test pendant qu'un autre est en train d'éditer produit des échecs fantômes dont le debug consomme une bonne part du contexte
  • Collisions de rate limit. ChatGPT Plus plafonne au nombre de messages sur une fenêtre glissante — par compte, pas par appareil. Quatre agents affamés sur un seul compte Plus touchent ce plafond à environ un quart de leur temps d'exécution individuel ; un agent bruyant affame les trois autres

La solution aux trois est la même : donnez à chaque agent sa propre machine, son propre répertoire personnel et — si vous les poussez fort — son propre compte.

Le montage qui tient à l'usage réel

Sur Office Claws, chaque agent que vous créez arrive sur un droplet DigitalOcean dédié, provisionné en environ deux minutes et demie. Ce droplet a son propre répertoire ~/.codex/, son propre checkout du dépôt et sa propre identité Tailscale. Vous n'avez pas à penser aux collisions ci-dessus — l'isolation est l'état par défaut.

SujetMulti-terminal sur un portableMulti-agents Office Claws
Cache d'auth~/.codex/ partagé — racesséparé par droplet
Working treepartagé — écrasementsun dépôt par agent
Rate limitun compte, tous les agentsun compte par agent (optionnel)
Récupérationtuer tous les terminauxredémarrer un droplet
Visibilité4 panneaux tmux4 bureaux dans le bureau pixel

Une journée typique à quatre agents ressemble à ceci :

researcher-agent  → reads issues, writes tickets
builder-agent     → takes a ticket, implements it
reviewer-agent    → reviews the builder's PRs
scribe-agent      → writes release notes, updates docs

Chacun vit sur son propre VPS. Chacun a sa propre session Codex. Chacun apparaît comme un personnage distinct dans le bureau pixel, pour qu'on voie d'un coup d'œil qui fait quoi.

Deux chemins côté abonnement

La seconde question, c'est le nombre de comptes ChatGPT qu'il faut. C'est moins évident que le côté infra, et la réponse dépend de l'intensité du travail des agents.

Un abonnement, plusieurs agents. Pour un usage léger à modéré — deux ou trois agents, quelques heures par jour chacun — un seul abonnement ChatGPT Plus (20 $/mois) couvre tout. Plus plafonne au nombre de messages sur une fenêtre glissante, pas par compte-par-appareil ; deux agents qui se relaient restent largement sous le plafond. C'est le point de départ.

Un abonnement par agent. Dès que vous avez quatre agents ou plus qui tournent plus de quelques heures, des alertes de rate limit apparaissent. À partir de là, il est plus économique d'ajouter un deuxième abonnement Plus que de monter à Pro, surtout si deux des agents font surtout du travail passif (surveillance, résumé) et deux font du code intensif. Plus à 20 $/mois × N comptes parallèles passe à l'échelle proprement jusqu'à environ six agents ; au-delà, Pro à 200 $ commence à avoir du sens.

Stratégie d'abonnement : un compte Plus pour un usage léger, un par agent pour un usage lourd, Pro au-delà de six agents

Trois motifs que nous utilisons au quotidien

Le montage n'est que la moitié du tableau. Les agents ont besoin d'un rôle, et les rôles doivent être assez étroits pour qu'ils ne se piétinent pas :

  1. En pipeline. Le researcher passe un ticket au builder, le builder passe une PR au reviewer, le reviewer passe un merge au scribe. Chaque agent attend celui qui le précède. Lent mais calme — pas de collision parce qu'un seul agent est actif sur un fichier à la fois
  2. Fan-out. Un agent planificateur produit N tickets indépendants, N builders les prennent en parallèle sur des dépôts différents. Rapide, mais il faut discipliner le périmètre — jamais deux builders sur le même module
  3. Watcher + worker. Un agent suit les logs / PRs / issues et vous ping ; d'autres prennent des tâches précises quand vous les approuvez. Zéro risque de conflit, très efficace pour les flux d'astreinte

Les motifs ne s'excluent pas. La plupart des jours nous faisons tourner une paire en pipeline plus un watcher isolé — cinq agents, zéro collision, parce que le pipeline sérialise l'accès aux fichiers partagés et que le watcher n'écrit jamais rien.

Ce qu'il faut éviter

Quelques idées qui sonnent bien et coûtent une journée :

  • Partager un seul clone git entre agents. Même avec une branche par agent, stash / hooks de commit / caches de build se bagarrent. Un clone par agent, par droplet
  • Faire tourner plus d'un processus Codex par droplet. Le droplet de base à 1 Go de RAM tient confortablement une CLI ; un second OOM-kill le premier au milieu d'un refactor
  • Faire du round-robin sur un seul compte Plus quand vous touchez activement les limites. Si vous voyez l'écran « vous avez utilisé vos messages » au moins une fois par jour sur un agent, le coût d'un deuxième Plus (20 $) est inférieur au coût du contexte perdu sur les agents coupés

Partir de zéro

Si vous voulez essayer sans vous engager sur le montage complet :

  1. Montez deux agents Office Claws. Self-Hosted avec notre app à 4,99 $/mois et des droplets à 4 $/mois vous met autour de 13 $ au total pour les deux premiers
  2. Affectez à l'un un rôle étroit de watcher (résumer les PRs ouvertes chaque matin) et à l'autre un rôle de builder (travailler sur un dépôt précis)
  3. Laissez-les tourner une semaine. Vous verrez les modes de collision en pratique et la forme du plafond d'un seul abonnement Plus
  4. N'ajoutez le troisième agent avec un compte ChatGPT séparé que si vous avez vu les rate limits mordre plus de deux fois dans la semaine

La règle sur laquelle nous revenons toujours : payez l'isolation là où elle fait gagner du temps, et mutualisez là où elle n'en fait pas gagner. Les droplets sont bon marché, les abonnements moins, et c'est entre les deux que vivent la plupart des montages multi-agents utiles.

Pour aller plus loin

Auteur

Office Claws Team

Nous construisons le futur de la gestion des agents IA chez Office Claws. Partage d'analyses sur l'infrastructure, la sécurité et l'expérience développeur.

Restez informé

Recevez les derniers articles sur les agents IA, l'infrastructure et les mises à jour produit directement dans votre boîte de réception.

Pas de spam. Désabonnement à tout moment.