Codex Sol peut diriger Luna Max, mais le calcul des quotas n’est pas démontré

Les utilisateurs de Codex Sol testent une nouvelle répartition du travail : conserver le modèle phare aux commandes, puis confier l’implémentation à Luna Max. Cette configuration promet un arbitrage direct entre qualité et consommation. Sol planifie et révise, tandis qu’un worker Luna personnalisé écrit le code sans monopoliser chaque tour du fil principal.

L’idée vient d’un post d’AYi AI Notes. Il propose de créer luna-worker.toml sous ~/.codex/agents/, de sélectionner gpt-5.6-luna et de régler l’effort de raisonnement sur max. Codex Sol agit alors comme orchestrateur, c’est-à-dire l’agent qui découpe les tâches, délègue le travail et évalue les modifications retournées.

Le mécanisme de configuration est réel et documenté. En revanche, les économies de quota promises et le doublement de la production ne sont pas vérifiés de manière indépendante. Cette distinction est importante, car OpenAI avertit que les flux de travail avec sous-agents peuvent consommer davantage de tokens que des exécutions comparables avec un seul agent. Le résultat dépend moins du nom du fichier que du travail effectivement délégué.

Le modèle Codex Sol sépare le jugement de l’implémentation

Le changement important n’est pas simplement l’accès à un autre modèle. Il réside dans la séparation entre jugement architectural et exécution.

OpenAI décrit les sous-agents Codex comme des agents spécialisés qui exécutent le travail qui leur est attribué dans des fils distincts. L’agent parent peut les lancer, attendre leurs résultats, leur envoyer des instructions de suivi et combiner leur travail dans une seule réponse.

Cette structure permet à Codex Sol de conserver les décisions à fort impact. Parmi elles figurent le découpage des tâches, la conception des interfaces, les choix de dépendances, les critères d’acceptation et la revue finale du code. Un worker Luna reçoit un contrat plus restreint et gère l’implémentation dans ce périmètre.

La documentation sur les sous-agents d’OpenAI confirme que les clients Codex locaux prennent en charge les fichiers d’agents personnels sous ~/.codex/agents/. Les définitions propres à un projet peuvent plutôt se trouver sous .codex/agents/ dans un dépôt.

Chaque fichier d’agent autonome doit inclure trois champs :

• name, qui identifie le rôle de l’agent

• description, qui aide Codex à déterminer quand ce rôle convient

• developer_instructions, qui définissent son comportement de travail

Le fichier peut aussi remplacer les paramètres habituels de la session. Ceux-ci comprennent model, model_reasoning_effort, les contrôles de sandbox, les outils et la configuration des compétences.

Une version représentative de la configuration rapportée ressemble à ceci :

Cet exemple reflète le format de configuration documenté. Il ne reproduit pas un fichier vérifié provenant de l’auteur du post initial, dont les instructions complètes n’étaient pas accessibles dans les sources disponibles.

Cette distinction compte, car la sélection du modèle seule ne crée pas un worker fiable. La description influe sur le routage, tandis que les instructions de développement définissent le périmètre, les responsabilités de test et les conditions d’arrêt. Un profil vague peut transformer un agent d’implémentation ciblé en une nouvelle conversation généraliste.

Le fichier ne transforme pas non plus automatiquement chaque demande de code en tâche Luna. Les versions actuelles de Codex délèguent après une demande explicite ou lorsque des instructions de projet ou des compétences applicables exigent une délégation. Les utilisateurs ont toujours besoin d’une règle de routage indiquant à Sol quel travail appartient au worker.

Cette règle peut être placée dans le prompt, dans un AGENTS.md de projet ou dans une autre couche d’instructions applicable. Une politique utile réserve l’architecture et la revue à Sol, puis oriente des unités d’implémentation bornées vers Luna.

Ce modèle remet en question l’habitude par défaut consistant à garder un seul modèle phare associé à chaque étape. Il traite la capacité des modèles comme un portefeuille plutôt que comme un réglage unique.

Pourquoi Luna Max est un choix de worker inhabituel

Luna Max associe un modèle orienté efficacité au niveau de raisonnement documenté le plus élevé, créant une expérience délibérée entre qualité et consommation.

OpenAI présente gpt-5.6-sol comme son modèle phare pour les tâches exigeantes. L’entreprise décrit gpt-5.6-terra comme un équilibre entre capacité et efficacité, tandis que gpt-5.6-luna cible les tâches claires, répétables et à fort volume.

Ces recommandations font de Luna un worker d’implémentation logique lorsque Sol a déjà levé les ambiguïtés. Une petite tâche, comme l’ajout d’un endpoint validé, la mise à jour d’un composant ou l’implémentation d’une migration spécifiée, offre un espace de solutions plus clair que la conception du système qui l’entoure.

Le raisonnement Max modifie ce profil. L’effort de raisonnement contrôle la quantité de travail interne qu’un modèle compatible peut consacrer à l’exploration et à la vérification d’une réponse. OpenAI indique que des réglages plus élevés peuvent améliorer les tâches complexes, mais qu’ils augmentent aussi le temps de réponse et l’utilisation de tokens.

Le guide GPT-5.6 de l’entreprise recommande Luna pour les charges de travail efficaces et à fort volume. Il recommande max pour les tâches exigeantes nécessitant davantage d’exploration et de vérification.

La combinaison de ces deux réglages n’est donc pas la configuration d’efficacité la plus évidente. Luna fournit le niveau de modèle inférieur, tandis que Max demande à ce modèle de réfléchir plus en profondeur. Le pari est que cette association conserve une qualité d’implémentation suffisante sans payer le jugement de niveau Sol à chaque tour du worker.

Cela peut fonctionner lorsque le découpage a déjà réduit l’incertitude. Prenons une migration de dépôt comprenant dix adaptateurs indépendants. Sol peut identifier l’interface commune, définir les invariants et spécifier les tests. Les workers Luna peuvent ensuite implémenter des adaptateurs individuels selon le même contrat.

L’économie s’affaiblit lorsque les workers doivent redécouvrir l’architecture. Si chaque agent Luna lit l’intégralité du dépôt, débat des exigences, révise son plan et réessaie des modifications étendues, le raisonnement Max peut effacer les économies attendues.

Cette configuration accroît également les exigences de qualité des prompts. Un humain utilisant un seul agent peut résoudre les ambiguïtés de manière interactive. Un orchestrateur doit transformer cette ambiguïté en ordre de travail borné avant de déléguer.

Les meilleurs ordres de travail identifient l’objectif exact, les fichiers pertinents, les contraintes, la commande de test, la sortie attendue et les conditions nécessitant une escalade. Ils indiquent aussi au worker ce qu’il ne doit pas modifier.

C’est là que Codex Sol trouve sa place dans le flux de travail. Sol ne doit pas simplement transmettre le prompt de l’utilisateur. Il doit transformer la demande en unités d’implémentation avec une responsabilité claire et des critères d’achèvement mesurables.

Pour les développeurs, cela ressemble à un responsable technique expérimenté qui attribue du travail à des contributeurs. Le responsable protège l’architecture et intègre les résultats. Les contributeurs opèrent de façon indépendante sur un périmètre défini.

L’analogie a ses limites, car les modèles ne conservent pas une compréhension organisationnelle comme des coéquipiers de longue date. Chaque agent a toujours besoin d’un contexte suffisant, et chaque paquet de contexte supplémentaire entraîne des coûts de consommation et de coordination.

Les équipes qui maintiennent déjà une base de connaissances d’ingénierie consultable disposent ici d’un avantage. Des conventions stables, des notes d’architecture et des conseils de test donnent à l’orchestrateur de meilleurs éléments pour des attributions ciblées.

Luna Max n’est donc pas un worker universel et bon marché. C’est un profil d’exécution spécialisé dont la valeur augmente à mesure que les frontières entre les tâches deviennent plus nettes.

Le véritable concurrent est le codage à modèle unique

L’enjeu central oppose le routage orchestré entre modèles à l’exécution de chaque étape de codage par un seul modèle très capable.

Une session Codex à modèle unique est facile à comprendre. Un agent explore le dépôt, pose des questions, rédige le plan, modifie les fichiers, exécute les tests, diagnostique les échecs et révise son propre travail.

Cette continuité a une valeur réelle. L’agent conserve les décisions dans un seul contexte et évite de devoir les résumer pour un autre fil. Les petites tâches bénéficient souvent de cette simplicité, car le coût de délégation dépasserait le travail d’implémentation.

Le coût apparaît à mesure que les tâches s’agrandissent. Les journaux d’exploration, sorties de tests, approches abandonnées et détails d’implémentation s’accumulent dans la même conversation qui contient les exigences et les décisions architecturales.

OpenAI qualifie ces effets de pollution du contexte et de dégradation du contexte. Les informations importantes deviennent plus difficiles à retrouver à mesure que des éléments moins pertinents remplissent le fil. L’entreprise indique que les sous-agents aident en éloignant le travail bruyant de la conversation principale et en retournant des résultats synthétisés.

Dans la configuration proposée, Codex Sol devient le gardien des décisions durables. Son fil devrait contenir l’objectif, les contraintes système, la carte des tâches, les choix d’intégration, les constats de revue et le statut final.

Les workers Luna absorbent le bruit local. Ils inspectent les fichiers pertinents, génèrent des patchs, exécutent des tests ciblés et retournent des comptes rendus concis. Leur investigation brute n’a pas besoin d’occuper le contexte principal de Sol.

Cela peut améliorer davantage que l’utilisation des quotas. Cela peut aussi réduire le risque qu’une longue trace d’implémentation relègue une exigence initiale hors de l’attention pratique. L’orchestrateur voit des synthèses plutôt que chaque commande ayant échoué.

Toutefois, la délégation crée une autre forme de surcharge. Sol doit préparer les prompts des workers, suivre leur progression, interpréter les résultats, inspecter les modifications et parfois renvoyer une tâche pour révision.

Les écritures parallèles ajoutent un autre problème. OpenAI recommande de commencer par des travaux de sous-agents fortement axés sur la lecture, car des modifications de code simultanées peuvent entrer en conflit et accroître les coûts de coordination. Deux agents modifiant le même module partagé peuvent produire des patchs individuellement raisonnables qui échouent ensemble.

Un flux de travail Codex Sol judicieux sépare donc le travail par responsabilité. Un worker peut mettre à jour un gestionnaire backend, un autre ajouter des tests isolés, et un troisième auditer la documentation. Les types partagés et la configuration centrale doivent rester sous la responsabilité d’un seul propriétaire.

Les worktrees Git ou des fichiers strictement séparés peuvent réduire les interférences, mais ils n’éliminent pas les conflits sémantiques. Deux modifications peuvent compiler séparément tout en reposant sur des hypothèses incompatibles concernant le même contrat.

L’orchestrateur doit également distinguer l’implémentation de la revue. Demander à Luna d’écrire du code puis d’accepter son propre résultat affaiblit la division du travail. Sol devrait examiner le diff par rapport à la tâche initiale, vérifier les tests et rechercher les modifications hors périmètre.

Ce rôle de revue est l’argument le plus fort pour conserver Sol au sommet. Le modèle phare consacre sa capacité aux points de levier plutôt qu’aux modifications répétitives.

Une séquence typique suivrait cinq étapes :

1. Sol étudie la demande et définit la frontière architecturale.

2. Sol transforme le plan en attributions indépendantes et testables.

3. Luna Max implémente les attributions sélectionnées dans des fils distincts.

4. Sol examine les diffs retournés, les preuves de test et les risques non résolus.

5. Sol intègre le travail accepté et exécute une validation plus large.

Cette séquence n’est pas automatiquement plus rapide. Elle donne les meilleurs résultats lorsque plusieurs attributions peuvent avancer indépendamment ou lorsque l’implémentation génère de grandes quantités de contexte jetable.

Pour un bug dans un seul fichier avec un correctif évident, l’agent parent peut probablement terminer avant qu’un worker ait reçu suffisamment de contexte. Pour une fonctionnalité étendue touchant des packages indépendants, l’orchestration a davantage de marge pour rentabiliser sa surcharge.

La bonne comparaison n’oppose donc pas Sol à Luna. Elle oppose un fil continu coûteux à une hiérarchie qui consacre différents types d’attention à différentes étapes.

L’affirmation d’un doublement de la production requiert encore des preuves

Aucun benchmark public ne prouve actuellement que cette configuration Codex Sol réduit de moitié l’utilisation des quotas ou double le travail achevé.

Le post social d’origine présente un résultat attrayant : économiser son allocation tout en produisant deux fois plus. Cette affirmation doit être considérée comme un retour d’expérience personnel sur un flux de travail, et non comme une garantie produit mesurée.

OpenAI indique explicitement que les workflows de sous-agents consomment davantage de tokens que des exécutions comparables avec un seul agent. Chaque enfant effectue son propre travail de modèle et d’outils, tandis que le parent dépense toujours des tokens pour créer les tâches et synthétiser les résultats.

Cet avertissement ne prouve pas que la configuration rapportée est inefficace. Il montre que l’efficacité ne peut pas être déduite du seul usage de Luna. La conception de la charge de travail détermine si l’exécution sur un niveau inférieur compense l’orchestration supplémentaire.

Au moins quatre mesures sont nécessaires pour évaluer cette affirmation.

Premièrement, les utilisateurs ont besoin de la consommation totale du parent et de chaque enfant. Examiner uniquement le fil Sol produirait un résultat trompeur, car l’usage des workers appartient au même workflow.

Deuxièmement, ils doivent mesurer la qualité des tâches terminées. Une première tentative moins coûteuse ne l’est plus si Sol doit réécrire la majeure partie du patch. Les reprises, les échecs de tests et les cycles de revue doivent entrer dans le calcul.

Troisièmement, ils doivent mesurer le temps écoulé. Des workers parallèles peuvent réduire la durée totale tout en consommant davantage de tokens. Ce compromis peut rester intéressant, mais il ne constitue pas une réduction de quota.

Quatrièmement, ils ont besoin d’une référence comparable. Le même ensemble de tâches devrait être exécuté avec Sol seul, Sol avec Luna Max, et peut-être Sol avec Luna à un niveau de raisonnement inférieur. Sinon, la difficulté des tâches peut expliquer la différence.

L’effort de raisonnement mérite une attention particulière. OpenAI indique qu’un effort plus élevé augmente l’usage de tokens et la latence. Max peut améliorer les résultats sur des tâches difficiles, mais l’appliquer à des modifications routinières peut gaspiller l’efficacité que Luna était censé apporter.

Une politique de routage fondée sur la difficulté des tâches serait plus crédible qu’un réglage permanent unique. Les changements mécaniques clairement définis pourraient utiliser un raisonnement plus faible, tandis que Max resterait disponible pour des tâches circonscrites comportant des cas limites complexes.

L’affirmation sociale se heurte également à des problèmes de vérification à l’exécution. Un fichier personnalisé peut spécifier un modèle, mais les développeurs devraient confirmer que le fil lancé a effectivement reçu le rôle, le modèle et le niveau de raisonnement demandés.

Cette préoccupation n’est pas théorique. Un rapport de bug de la communauté a décrit des enfants héritant des paramètres du parent durant un déploiement multi-agent en évolution. Des réponses ultérieures ont signalé des contournements de configuration, mais le comportement à l’exécution variait selon la version et la surface d’outil.

Un autre ticket Codex a documenté une divergence entre les fichiers d’agents personnalisés et les sessions alimentées par des outils. Le rapport indiquait que des agents de projet valides n’étaient pas exposés via l’interface de lancement disponible.

Ces rapports n’établissent pas que les agents personnalisés actuels sont défaillants. La documentation actuelle d’OpenAI indique que les valeurs des fichiers d’agents priment sur les paramètres hérités. Ces rapports montrent pourquoi les utilisateurs devraient inspecter les métadonnées réelles des enfants plutôt que de se fier à l’intention.

Un test fiable devrait enregistrer les éléments suivants pour chaque affectation :

• Rôle d’agent demandé

• Modèle résolu

• Effort de raisonnement résolu

• Fichiers modifiés

• Commandes de test et résultats

• Résultat de la revue par le parent

• Nombre de cycles de révision

• Usage total sur l’ensemble des fils

• Temps écoulé de bout en bout

La comparaison obtenue devrait s’appuyer sur un travail représentatif. Un benchmark ne contenant que du code passe-partout favorise le modèle worker, tandis qu’un benchmark composé uniquement d’ambiguïtés architecturales favorise Sol. Le développement réel mêle les deux.

Les équipes devraient également prévoir un mécanisme de confinement des échecs. Un worker doit s’arrêter lorsque sa tâche exige une décision architecturale qui ne lui a pas été fournie. Improviser discrètement cette décision engendre des coûts de revue et des incohérences cachées.

L’instruction développeur la plus sûre n’est pas « terminer à tout prix ». C’est « implémentez dans cette limite et signalez le problème lorsque cette limite est insuffisante ».

Cela modifie le sens de la productivité. Générer davantage de code ne signifie pas automatiquement produire davantage. Les changements acceptés, qui passent les tests et préservent l’intention de conception, constituent l’unité pertinente.

En l’absence de mesures contrôlées, « doubler la production » reste une hypothèse qui mérite d’être testée plutôt qu’un résultat que les lecteurs peuvent tenir pour acquis.

Ce que les utilisateurs de Codex Sol devraient surveiller ensuite

Trois signaux détermineront si les workers Luna pilotés par Sol deviennent un workflow durable ou restent une expérience d’optimisation.

Le premier signal est un routage de modèle vérifiable. Les clients Codex doivent faciliter l’inspection du rôle enfant résolu, du modèle, de l’effort de raisonnement et du mode d’autorisation.

La documentation d’OpenAI indique que les valeurs définies dans un fichier d’agent personnalisé priment. Elle explique également que les paramètres omis peuvent provenir d’une valeur explicite au lancement, d’une valeur par défaut [agents] ou de la session parente.

Cet ordre de résolution est flexible, mais cette flexibilité peut masquer des erreurs. Un développeur qui demande Luna Max devrait pouvoir confirmer Luna Max sans parcourir des journaux de session bruts ni rétroconcevoir un appel d’outil.

Si les prochaines versions de Codex rendent cette vérification cohérente dans l’application, la CLI, l’IDE et les sessions alimentées par des outils, le modèle piloté par Sol gagnera en crédibilité. Si le routage reste dépendant de comportements propres à chaque client, les économies annoncées resteront difficiles à reproduire.

Le deuxième signal est la mesure au niveau de la charge de travail. Les utilisateurs ont besoin de tableaux de bord attribuant la consommation, la latence, les nouvelles tentatives et la production acceptée dans un arbre d’agents.

Un fil parent peut sembler efficace parce que l’implémentation a été déplacée ailleurs. Sans reporting agrégé, il est impossible de savoir si la délégation a économisé du quota ou l’a simplement redistribué.

La métrique la plus utile combinerait l’usage total et les tâches acceptées. Les équipes pourraient alors comparer le travail avec Sol seul au travail Luna orchestré par Sol, sur le même dépôt et la même suite d’évaluation.

La qualité doit rester visible à côté de la consommation. Un profil worker qui réduit l’usage mais double le temps de revue n’offre pas d’avantage clair. Il en va de même pour un workflow parallèle qui termine plus vite tout en produisant des patchs contradictoires.

Le troisième signal est l’émergence de conventions de routage stables. Aujourd’hui, les utilisateurs peuvent définir des agents personnalisés et demander à Codex de déléguer. Le problème le plus difficile consiste à décider quand cette délégation doit avoir lieu.

La configuration rapportée propose une règle : Sol planifie et révise, tandis que Luna Max implémente. Cette règle est mémorable, mais les équipes de production auront besoin de limites plus précises.

Une politique mature pourrait orienter :

• L’architecture, le débogage ambigu et les décisions d’intégration vers Sol

• L’exploration de dépôt et l’analyse de documents vers Terra

• L’implémentation étroite, les migrations répétitives et les tests isolés vers Luna

• La revue sensible à la sécurité ou transversale de nouveau vers Sol

• Les tâches contradictoires ou insuffisamment spécifiées vers le parent avant toute modification

Ces limites devraient évoluer à partir de mesures plutôt que du branding des modèles. Un worker Luna performant sur une base de code peut peiner sur une autre, avec des tests rares ou des conventions non documentées.

Les développeurs devraient commencer par des tâches faciles à vérifier. Parmi les bons candidats figurent les ajouts de tests isolés, les adaptateurs fondés sur des schémas, les migrations mécaniques d’API et les composants dotés de critères d’acceptation explicites.

Ils devraient éviter de commencer par des refontes d’authentification, des migrations de données sans plan de restauration ou des changements couvrant plusieurs sous-systèmes partagés. Ces tâches placent trop de jugement implicite dans l’affectation du worker.

L’étape pratique suivante est un essai interne contrôlé. Sélectionnez un petit ensemble de tickets terminés, préservez leurs exigences d’origine et exécutez-les avec les deux workflows. Comparez la production acceptée, la consommation totale, le temps écoulé et l’effort de revue.

Gardez le profil luna-worker.toml limité pendant cet essai. Exigez des résumés de fichiers, des preuves de tests et une escalade explicite. Demandez à Codex Sol de revoir chaque diff selon les mêmes critères d’acceptation que ceux utilisés pour la référence.

Si le worker renvoie à plusieurs reprises des changements propres et bien délimités, élargissez progressivement son périmètre de tâches. Si Sol passe beaucoup de temps à réparer ou à redécouvrir des décisions, améliorez la décomposition avant de changer de modèle.

Le modèle Codex Sol et Luna Max ouvre une perspective crédible pour le codage assisté par IA : un même modèle n’a pas besoin d’assumer tous les rôles. Pourtant, l’orchestration n’est pas une couche d’efficacité gratuite. Elle échange un contexte continu contre du routage, de la vérification et de la coordination.

La question utile n’est pas de savoir si Luna peut écrire davantage de code. Elle consiste à déterminer si Sol peut définir le travail assez clairement pour que le code de Luna survive à la revue. Mesurez ce résultat sur des tâches réelles, puis laissez les preuves décider de la part de votre file de développement à déléguer.