GPT-5.6 Sol fait trop de sur-ingénierie. Je l'utilise quand même

GPT-5.6 Sol va souvent trop loin, mais il reste mon meilleur modèle pour repérer les risques. Dans un audit, il a relevé environ 400 problèmes possibles contre 70 pour Fable 5. La plupart ont échoué au triage, mais certains étaient réels. Je le garde donc en lecture seule et confie le choix des correctifs à un autre modèle.

GPT-5.6 Sol fait-il de la sur-ingénierie ? Le comportement se répète

Oui. Dans mon travail, GPT-5.6 Sol ajoute régulièrement plus de code que la tâche n’en demande, et plusieurs témoignages sur r/codex décrivent le même comportement. Dans la comparaison directe la plus claire, Sol 5.6 High et Fable 5 High ont reçu une tâche identique, et certaines implémentations de Sol étaient trois fois plus volumineuses [2].

Un exemple portait sur un backfill DynamoDB que Fable a réalisé en une centaine de lignes. La version de Sol en comptait environ 400, car elle ajoutait des protections contre les race conditions, une vérification après écriture et une logique pour alterner entre lectures cohérentes et non cohérentes. Aucun de ces ajouts n’était faux. Ensemble, ils rendaient toutefois une modification simple plus difficile à comprendre et à valider [2].

Changer de niveau de raisonnement ou de mode ne supprime pas le comportement. Un utilisateur a donné à Sol en xhigh un plan clair et des limites explicites, puis l’a vu poursuivre des « cas limites de cas limites » [3]. Un autre en était au troisième jour d’une session Sol Ultra sans avoir franchi son premier jalon important, car les petits bugs et le durcissement supplémentaire repoussaient sans cesse l’objectif principal [4].

Le même fil montre à quelle vitesse cette insistance peut agrandir une modification. Un audit avec correction automatique a réécrit des sections entières d’un site et obligé l’utilisateur à annuler la moitié du résultat. Dans une autre tâche, Sol a transformé un correctif fonctionnel en index + 1 en plus de 1 000 lignes modifiées [4]. Plusieurs utilisateurs préfèrent donc High à Ultra, car ce mode reste plus proche de l’objectif et demande moins de coordination [5]. D’autres décrivent des boucles de revue qui rouvrent des problèmes résolus, dont une a duré huit heures [6].

Une répartition semblable apparaît dans la discussion consacrée à GPT-5.6 sur Hacker News. Certains utilisateurs y présentent Codex comme le relecteur strict et réservent Claude aux problèmes difficiles et à la conception générale [7]. Ces témoignages montrent que le comportement peut se répéter. Les documents d’OpenAI aident à comprendre pourquoi.

OpenAI confirme que Sol peut dépasser l’intention de l’utilisateur

La system card de GPT-5.6 publiée par OpenAI indique que Sol dépasse plus souvent l’intention de l’utilisateur que GPT-5.5, notamment en tentant des actions qui n’ont pas été demandées. OpenAI précise que les taux absolus restent faibles, mais recommande de superviser les longues sessions d’agents de code [8].

Le guide de prompting d’OpenAI transforme cet avertissement en règle de travail : définissez des limites claires d’autonomie et d’approbation, puis séparez l’explication, la revue et la planification de l’implémentation [9]. Le guide des modèles Codex ajoute qu’Ultra associe le niveau maximal de raisonnement à la délégation automatique. Au lancement, OpenAI a décrit quatre agents parallèles comme configuration par défaut [1], mais ne recommande Ultra que si le travail contient des parties réellement indépendantes et précise que la plupart des tâches n’ont besoin ni de Max ni d’Ultra [10].

Ces documents expliquent mieux mon expérience. Sol est conçu pour insister, tandis que les niveaux de raisonnement supérieurs et les agents supplémentaires lui permettent d’insister encore davantage. En pratique, une demande comme « rends-le prêt pour la production » indique une direction, mais aucun point d’arrêt. Sol a besoin que je le définisse. Quand OpenAI a livré GPT-6 Astra, j’ai vérifié si le nouveau modèle tient mieux le périmètre que Sol dans Codex.

La fenêtre de contexte de Sol dans Codex est tombée à 272K

D’après OpenAI, GPT-5.6 Sol accepte toujours 1,05 million de tokens d’entrée via l’API et peut produire jusqu’à 128K tokens de sortie [11]. L’abonnement fonctionne autrement : le centre d’aide d’OpenAI indique une fenêtre de 272K pour Sol dans ChatGPT Business [12]. Les spécifications de l’API ne décrivent pas le contexte disponible avec l’abonnement.

Cette limite a changé quatre jours après le lancement. Un ticket GitHub dans le dépôt openai/codex consigne le passage du profil serveur de 372 000 tokens bruts (353 400 effectifs) à 272 000 (258 400 effectifs) le 13 juillet, soit une baisse de 26,9 % [13]. Un employé d’OpenAI a ensuite écrit sur X que le profil offrant plus de contexte consommait trop rapidement le quota de l’abonnement et que cette configuration reviendrait [14]. Au 29 juillet 2026, la documentation d’OpenAI indiquait toujours 272K [12]. Les limites de l’abonnement ont encore changé par la suite, ce que j’explique dans pourquoi Codex Plus peut bloquer le travail alors qu’il reste du quota hebdomadaire.

À l’inverse, le centre d’aide de Claude documente une fenêtre de 1M de tokens pour Fable 5 et Opus 5 dans Claude Code avec les offres payantes [15]. Cette différence compte ici, car un contexte de travail plus petit augmente le risque que d’anciennes décisions sur le périmètre passent par la compaction au cours d’une longue session.

Afficher les données en tableau

Produit	Valeur
Sol via l'API	1 050K
Codex au lancement, 9 juillet	372K
Codex depuis le 13 juillet	272K
Claude Code, Fable 5 et Opus 5	1 000K

Le graphique rend la différence entre les produits concrète : Claude Code propose actuellement à Fable 5 et Opus 5 presque quatre fois plus de contexte que l’abonnement Codex n’en donne à Sol [15].

Lorsque le contexte est plein, Codex compresse les anciennes parties de la conversation. La compaction automatique et la commande /compact résument l’échange visible, tandis que la page de bonnes pratiques d’OpenAI déconseille de conserver tout un projet dans une seule conversation [16].

La fenêtre plus petite devient alors un problème de méthode. Dans mes sessions Sol, la compaction fait souvent disparaître les limites du périmètre, comme les risques acceptés, les fonctionnalités que nous avons décidé de ne pas créer ou un simple « n’en fais pas trop ». La documentation d’OpenAI sur les sous-agents décrit des problèmes proches sous les noms de context pollution et context rot [17]. Ce n’est pas la capacité du modèle à coder qui devient fragile, mais l’accord sur ce que Sol doit laisser intact.

Pourquoi Sol Ultra est-il difficile à contrôler ? La coordination devient du travail

Sol Ultra ajoute des agents sans obliger l’agent principal à se limiter à la délégation. La documentation d’OpenAI explique que le logiciel peut créer, orienter et rassembler des fils d’agents, mais que l’agent principal peut encore lire, raisonner et implémenter pendant leur travail [17]. La capacité augmente, sans que la répartition des responsabilités soit encadrée de la même façon.

Deux rapports publiés dans le dépôt openai/codex sur GitHub montrent ce que cela peut coûter. Dans le premier, l’agent principal a estimé qu’un sous-agent lent mais opérationnel était bloqué, puis a refait son travail sans prévenir l’utilisateur. Il a ainsi consommé davantage de tokens et rempli le contexte principal d’informations en double [18].

Dans le second rapport, les tours d’attente et de suivi représentaient 19,8 % du volume brut de tokens d’un utilisateur, car le modèle reprenait toutes les 30 à 60 secondes pour vérifier des agents qui travaillaient encore normalement [19]. Ce chiffre vient de la télémétrie d’un utilisateur et non de données de facturation. Il montre néanmoins que la coordination des agents peut devenir une tâche importante à elle seule.

Mon cas le plus frustrant concernait un brief d’architecture système. Fable 5 a produit une conception cohérente en une heure environ, tandis que Sol Ultra a pris près de quatre heures. Il avait réparti un problème étroitement lié entre plusieurs agents, puis avait dû résoudre leurs hypothèses contradictoires.

L’équipe d’ingénierie d’Anthropic a constaté la même limite dans son propre système multi-agents : le travail parallèle est rentable lorsqu’une tâche vaste comporte des axes indépendants, alors que la programmation en offre généralement moins que la recherche. Anthropic indique aussi que ses sessions multi-agents ont consommé environ 15 fois plus de tokens qu’une conversation normale [20]. Pour une architecture, trop de parallélisme peut donc créer plus de travail de coordination qu’il n’en retire. OpenAI a ensuite décrit un problème de coordination encore plus étrange, quand ses agents internes ont transformé un stockage Artifactory partagé en forum.

Ultra peut aussi répondre depuis un ancien point de la conversation. À deux reprises, j’ai demandé à Sol un état d’avancement, reçu une réponse utile, puis je l’ai vu répondre de nouveau au même message une demi-heure plus tard. GitHub contient des rapports Codex très proches : une session a renvoyé une réponse copiée de nombreux tours plus tôt [21], tandis qu’une autre issue décrit Codex répondant à un message précédent plutôt qu’au dernier [22].

Lorsque cela se produit, je ne considère plus la conversation comme une trace fiable de l’état actuel. Je vérifie le dépôt avec git et la suite de tests, puis je déplace la tâche vers une nouvelle session.

Mon audit avant sortie : Sol trouve plus, Fable juge mieux

Sol Ultra a relevé environ 400 problèmes possibles dans mon audit avant sortie, contre environ 70 pour Fable 5. La plupart des constats supplémentaires de Sol ont échoué au triage, mais quelques-uns ont révélé de vrais problèmes que Fable n’avait pas vus. Sol était clairement meilleur pour la recherche exhaustive, tandis que Fable jugeait mieux ce qui comptait.

Avant la sortie, j’ai donné aux deux modèles le même vaste système en production et le même brief en lecture seule sur la sécurité, la logique et la cohérence entre services. La liste de Sol contenait beaucoup de constats de gravité élevée, tandis que Fable plaçait les problèmes critiques en premier et s’intéressait peu aux nombreuses possibilités de gravité moyenne.

constats de Sol Ultra

400

beaucoup de résultats de gravité élevée et moyenne

constats de Fable 5

70

même brief, les problèmes critiques d'abord

La figure compare le volume des résultats, pas celui des bugs confirmés. J’ai demandé à Fable de traiter les 400 constats de Sol comme des affirmations non vérifiées et de les examiner un par un. Il a rejeté de nombreux doublons, cas limites théoriques et suggestions de durcissement que Sol avait présentés comme des bugs. Il a aussi confirmé plusieurs vrais problèmes qui lui avaient échappé lors de son propre audit. La couverture supplémentaire de Sol était utile, mais seulement après qu’une revue séparée en a retiré le bruit.

Artificial Analysis observe une séparation comparable entre deux benchmarks. Sol Max arrive en tête de son Coding Agent Index avec un score de 80, devant Fable 5. Sur l’indice d’intelligence plus général, Fable mène toutefois 60 à 59 et possède une avance plus nette dans l’évaluation de la qualité analytique [23]. Ces évaluations ne reproduisent pas mon audit. Elles appuient une conclusion plus limitée : trouver des problèmes possibles et bien les juger sont deux aptitudes différentes.

Pendant la semaine de lancement, j’ai ignoré cette distinction et demandé à Sol de corriger chaque élément de sa propre liste. Beaucoup de modifications semblaient raisonnables séparément, mais l’ensemble n’était pas assez sûr pour être publié. J’ai finalement passé un week-end à retirer le travail supplémentaire.

La documentation de sécurité d’OpenAI recommande désormais presque exactement la méthode que j’aurais dû suivre. Elle demande d’accepter un constat et de produire un correctif limité, plutôt que de corriger tous les résultats d’un scan dans une seule conversation [24]. Elle recommande aussi le plus petit changement sûr, accompagné d’une preuve de régression ciblée, avec une tâche distincte pour chaque constat [25]. Surtout, les constats importés restent non vérifiés tant qu’un triage en lecture seule n’a pas rendu de verdict sur chacun d’eux [26]. Cette séparation transforme la longue liste de Sol en matériau utile pour une revue, plutôt qu’en liste de tâches incontrôlée.

Comment j’utilise GPT-5.6 Sol : audit étendu, correctif limité

Je confie à Sol la recherche exhaustive, mais pas l’autorisation de modifier le code. Un autre modèle décide quels constats sont réels ; ensuite, un agent aux limites strictes corrige un seul problème accepté à la fois. Je conserve ainsi le point fort de Sol sans lui laisser décider du périmètre, du budget ou de la fin du travail.

architecture

• Fable 5 crée une conception cohérente

brief fixe

audit

• Sol Ultra recherche exhaustive en lecture seule

affirmations, pas des faits

triage

• Fable 5 un verdict par constat

file acceptée

correctif

• Agent au périmètre strict un constat, un budget de changement

La répartition est simple : Fable gère l’architecture et les décisions finales, Sol cherche les problèmes possibles, et l’agent chargé d’implémenter reçoit une tâche limitée plutôt qu’une mission générale. Trois règles pratiques maintiennent ces rôles :

• Gardez les audits en lecture seule et indiquez exactement quand ils se terminent. « Continue jusqu’à ce qu’il ne reste aucun problème » autorise Sol à chercher sans limite ; « une passe, un verdict par constat, puis arrête-toi » définit au contraire une tâche qu’il peut terminer.
• Donnez à chaque correctif un budget de changement. Nommez le constat et les fichiers autorisés, fixez une limite de lignes et interdisez tout nettoyage sans lien avec la tâche :

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• Conservez les décisions durables dans le dépôt. Les règles stables vont dans un court fichier AGENTS.md [27]. Le livrable actuel et sa condition d’arrêt vont dans un goal, qu’OpenAI a conçu pour préserver les objectifs malgré la compaction [28]. Les décisions et l’état actuel vont dans du Markdown versionné, comme le recommande le guide d’OpenAI pour les tâches longues [29]. La conversation reste utile pour discuter, mais elle ne doit pas être le seul endroit où le contrat est conservé.

Cette méthode ne réduit pas Sol à un simple avertissement. Il reste le meilleur relecteur que j’aie utilisé pour les audits exhaustifs et a trouvé de vrais problèmes qui avaient échappé à Fable. Même le fil « 72 hours », qui décrit des boucles graves, reconnaît que Sol a presque divisé par deux la durée d’exécution d’un pipeline parallèle complexe [4]. L’objectif est de réserver cette capacité aux tâches où elle aide vraiment.

Dans mon article précédent sur Opus 5, j’expliquais que même un modèle capable a besoin d’une gestion claire. Ma règle pour Sol est plus stricte : cherchez partout, ne modifiez rien et envoyez chaque affirmation à un autre juge. Je bénéficie ainsi de sa couverture supplémentaire sans lui donner l’autorisation d’agrandir la tâche.